Mein Vortrag der SEOkomm 2015 in Salzburg, u.a. rund um Webfonts, asynchrone Scripte, Prefetching und Prerendering, AMP, HTTP2 und mehr!

1. Bastian Grimm, Peak Ace AG | @basgr
Mehr (Page-) Speed
geht nicht…
Ein Blick in die Zukunft der Ladezeiten-Optimierung

2. Ich bin ein extrem ungeduldiger Mensch…
Ladezeit ist ein User Experience Thema!

3. Anderer Budgettopf!
Warum ist das wichtig?

4. 5 Fakten in max. 2 Minuten…!
Keine Basics, aber ein kurzer Recap:

5. Google nutzt Ladezeit als Ranking Signal…
… und das bereits seit 2010!
Mehr lesen: http://pa.ag/1t4xVs6

6. Die Top-4 sind deutlich schneller als der Wettbewerb!
Seiten mit “gutem SEO” kümmern sich offenbar auch um Sitespeed?
Searchmetrics Ranking Factors 2014 (US): http://pa.ag/10cZuU2

7. Die Erwartungshaltung eurer User ist klar:
Langsame Ladezeiten bedeuten sofort einen Trafficverlust!
“A report from Nielsen has revealed
that 47% of people expect a website
to load within 2 seconds, and 40%
will leave a website if it does not
load fully within 3 seconds.”
Mehr lesen: http://pa.ag/1Rk8dIf

8. Quelle: http://pa.ag/1w8IYwq
Bereits 100ms machen einen (großen) Unterschied!
Amazon = 1%+ mehr Umsatz pro 100ms
1 Sekunde Verzögerung = -11% Pageviews & -7% Conversions

9. Google misst die Return-to-SERP-Rate…
In Kombination (CTR, ToS) ist diese ebenso ein (indirekter) Rankingfaktor!

10. …und forciert das Thema Site
Speed immer wieder:
Quelle: http://pa.ag/1cWFCtY

11. Die Themen des letzten Jahres sind weiterhin wichtig:
Zu den Folien auf Slideshare: http://pa.ag/seokomm-speed
• Optimierung des Critical Rendering Path (Google
interessiert zu aller erst der direkt sichtbare Bereich!)
• CSS & JavaScript Dateien verkleinern (minify)
• Bilder optimieren: Sprites verwenden und Overhead
bei JPG & PNGs reduzieren (Metadaten, etc.)
• Effektives Caching & serverseitige Komprimierung
• Schlankes Mark-Up (keine Kommentare, inline von
CSS / JS nur wo es wirklich sinnvoll ist)
• CDN bzw. Asset-Server (sowie Cookie-less Domains)
zum Parallelisieren von Downloads verwenden
• etc.

12. … dennoch drei kurze Anmerkungen dazu:
Wir sprechen heute nicht über Tools…

13. Google PageSpeed Insights als Startpunkt
Freies, web-basiertes Tool von Google, um eine Seite anhand diverser Regeln
und Best-Practices zu messen
Jetzt ausprobieren: https://developers.google.com/speed/pagespeed/insights/

14. Was wirklich zählt? Zeit statt Note!
Vollständiger Artikel: http://pa.ag/1KjZuQQ

15. webpagetest.org – mit allen Funktionen:
Alles auf einen Blick: TTFB, Keep-Alive, Compression & Caching, Image
Usage, CDN & Wasserfall-Diagramme

16. Wenn schon Google Daten, dann aus der Search Console
Habt diese Daten immer im Blick, sowas sollte nicht passieren!
Seiten / Tag
Zeit / Download

17. Kostenloses Dashboard von sitespeed.io
Daten im zeitlichen Verlauf, Wettbewerbsvergleich, uvm.
Jetzt ausprobieren: http://pa.ag/1PuN012

18. Genug davon, auf geht‘s!

19. Anzahl von Requests, Blocking vs. non-Blocking, Asynchron, etc.
#1 HTTP Anfragen optimieren

20. Wenn man 23 CSS & JS Dateien lädt, ist das Scheisse!
Deichmann AT verschwendet ~3 Sek. auf Blocking-Ressources…

21. Konsolidieren bzw. Kombinieren (JS, CSS) und Sprites wo möglich!
Weniger ist mehr!

22. Für alles andere: Asynchrone Requests wann immer mgl.
HTML5 async, JS Workarounds und / oder Loader verwenden:
Mehr: http://pa.ag/18o8War

23. Schön, abwechslungsreich, bunt und… langsam!
#2 Custom Webfonts

24. 57% aller Webseiten nutzen nicht-Standard-Schriften
Das Ergebnis: 114 KB Datenvolumen bei avg. zus. 2,9 HTTP Requests!
Quelle: http://pa.ag/1BRUnbe

25. Klassisches Szenario: Einbinden als (externes) CSS File
Sehr einfach einzusetzen, großer Nachteil: CSS ist Render-Blocking!

26. Custom Font mittels Fontloader laden
webfont.js ist Googles Lösungsvorschlag (Asnyc JS lädt dann CSS):

27. Leider mit wenig Erfolg und einem anderen Problem:
FOUT (Flash of unstyled Text) = nerviges Flackern!
Fighting the FOUT: http://pa.ag/1BRWMmu

28. Credits: http://pa.ag/1GakitY & http://pa.ag/1NDXCVi

29. Gezieltes „vorab laden“ von DNS, Ressourcen & ganzen Seiten
#3 Pre-Fetching & -Rendering

30. The Pre*-Party at-a-glance:
Stolen from Ilya Grigorik: http://pa.ag/1MV4KAk

31. NetDoktor.de Request Breakdown (Waterfall-View)
Der DNS-Lookup auf den Asset-Server (static.netdoktor.de) dauert 333ms

32. DNS Pre-Fetching im <head>: 81ms = 75% Ersparnis
Super nützlich für Ressourcen anderer Hosts, die später genutzt werden!

33. Chrome lädt eure Top-10 Hosts bei jedem Start!
Einfach mal mit chrome://dns eure Top Destinations anschauen:

34. Noch einen Schritt weiter: Pre-Connect bei HTTPS
Nicht nur den DNS auflösen; auch den TLS-Handshake durchführen:

35. Gezieltes Vorladen von einzelnen Ressourcen
Prefetch (für Folgeseiten ):
• Wird nur im Browser-Leerlauf (mit geringer Prio) ausgeführt
• Einsatz: Bilder, JS & CSS herunterladen & cachen.
• Bei langsamen Verbindungen werden große Dateien u.U. ignoriert.
Subresource (für die aktuelle Seite):
• Funktioniert derzeit nur im Chrome
• Möglichst zu Beginn im Mark-Up nutzen
• Analog zu Prefetch, aber hohe Prio, daher nur verwenden, wenn das File wirklich nötig ist!

36. Das nächste Bild in einer Bildergalerie / großes Bild in einem Zoom
HTML Fragmente (bspw. Boxen / Layer) für kritische Ziele (Signup / -in)
Was könnte ich prefetchen?

37. Pre-Rendering: Vorladen ganzer Websites!
Wenn ich weiß, wohin mein Besucher navigieren wird:
Prerender:
• Aktuell nur im Chrome & IE/Edge möglich
• Lädt die Folgeseite inkl. aller Ressourcen und legt diese in den Cache
• Nur für GET-Requests und extrem ressourcenintensiv – use with care!
Prefetch & Prerender:
• Kombinierte Verwendung für bessere Browser Kompatibilität
• FF führt Prefetch aus, Chrome & IE nutzen die Prerender Anweisung

38. Den Warenkorb (od. Checkout), wenn ein Artikel hineingelegt wird.
Die Folgeseite eines mehrseitigen Artikels.
Was könnte ich prerendern?

39. Eine JavaScript API für Sichtbarkeitszustände des Browsers
#4 Page Visibility API

40. visibilitychange-Events für Sichtbarkeitszustände
Schaut der User meine Website an oder ist diese nur im Hintergrund offen?
“The API lets you know when a webpage is
visible or in focus. […] there is a reasonable
chance that any given webpage is in the
background and thus not visible to the user.
When the user minimizes the webpage or moves
to another tab, the API sends an event
regarding the visibility of the page.”
Mehr lesen: http://pa.ag/1Nysd6K

41. Die Pre*-Party kann euch euer Analytics ruinieren!
Akkurateres Tracking

42. JS erst ausführen, wenn die Seite wirklich sichtbar ist (non-Prerender).
Eventbasiertes Laden von Elementen

43. Browser Support für die Page Visibility API
Vollständiger Support in allen wichtigen Browsern!
Quelle: http://caniuse.com/#feat=pagevisibility

44. Top Qualität, effiziente(re) Komprimierung, kleinere Dateien, etc.
#5 Neue Bildformate

45. 62% des Webtraffics sind Bildmaterial!
… und 51% aller URLs laden mehr als 40 Bilder (pro Aufruf)
Quelle: http://pa.ag/1SGDOEo

46. WebP: Googles Alternative zu JPEG, PNG & GIF
Lossy & lossless Komprimierung, Transparenz, Metadaten & Farbprofile,
Animationen & deutlich kleiner (30% vs. JPEG, 80% vs. PNG)!
Alles zu WebP: : http://pa.ag/1EpFWeN

47. Wir sind noch nicht „ganz“ da…
Derzeit nativ leider nur für Chrome, Opera und auf Android Browsern!
Quelle: http://caniuse.com/#feat=webp

48. WebP trotzdem nutzen: On-the-fly Replacement
PNG & JPEG Bilder per Rewrite (z.B. via .htaccess) austauschen:

49. WebP trotzdem nutzen: On-the-fly Replacement
PNG & JPEG Bilder per Rewrite (z.B. via .htaccess) austauschen:
VS.

50. Bei neuen Templates: HTML5 & <picture> verwenden!
Browser, die <picture> nicht unterstützen, ignorieren selbiges & auch <source>
Browser, die WebP nicht unterstützen, verwenden das Fallback <img>
Weitere Infos: http://responsiveimages.org/

51. Das letzte Wort ist noch nicht gesprochen: FLIF, BPG, etc.
(Links: Dateigröße im Vergleich zum Original-PNG)
Mehr lesen: http://pa.ag/1S5OQmX

52. Insbesondere zwei Themen sind aktuell „hot“…!
Was gibt‘s Neues? #perfmatters

53. Google‘s „Accelerated Mobile Pages“ für schnellere, mobile Webseiten
#6 Das AMP Projekt

54. AMP: Kastriertes HTML für maximale Performance!
Google ist Geschwindigkeit deutlich wichtiger als (HTML-) Features
Mehr: https://www.ampproject.org/
• Modifiziertes HTML Mark-Up mit diversen Änderungen
• Herkömmliche HTML Tags, wie <script> sind verboten,
andere wie bspw. <img> werden durch spezielle AMP
Tags, z.B. <amp-img> ersetzt
• AMP Funktionalität durch standardisierten Dokument-
aufbau und eine AMP JS Library für maximal
effizientes Pre-Rendering bzw. Caching

55. Ein Standarddokument mit AMP HTML Mark-Up:
Vordefinierter Aufbau sowie diverse Restriktionen:
How to write AMP Mark-Up: http://pa.ag/1MN9I1X
• start with the doctype <!doctype html>.
• contain a top-level <html> tag (<html amp> is OK as well).
• contain <head> and <body> tags
• contain a <link rel="canonical" href="$SOME_URL" />
tag inside head that points to the regular HTML version
or to itself if no such HTML version exists
• contain a <meta charset="utf-8"> tag as the first child
• contain a “meta viewport” & “initial-scale=1”
• contain a <script async
src="https://cdn.ampproject.org/v0.js"></script> tag as
the last element in their head.
• contain a <style> attribute setting various defaults

56. Wie sieht das in den Suchergebnissen aus?
Testlink öffnen, Schlagzeilen suchen, swipen (keine Schlagzeilen = keine AMPs)
Testlink (nur auf Mobilgeräten): http://g.co/ampdemo

57. Restriktionen?! Gefühlt wie damals mit HTML 2.0!
Restriktionen: http://pa.ag/1ObU4fH

58. It doesn‘t feel open, it feels very closed!
Sehr lesenswerter Artikel von Joost de Valk:
There are, for instance, specific tags for YouTube and Twitter. To
get your tag in AMP you’ll have to apply […]. The same is true for
most advertising formats: only 5 ad platforms are supported, 2 of
which are owned by Google.
Currently there is no info to be found on […] the process of
applying for new tags or ad formats, or other things […] It doesn’t
feel “open”, it feels very closed.
Mehr lesen: https://yoast.com/weekly-seo-recap-41/

59. Mehr lesen: http://pa.ag/1WW4uaN & http://pa.ag/1H4NacR

60. Und das Allerschlimmste?
Meine Prognose: Im Laufe von 2016 wird Google Folgendes ankündigen:
We are using AMP in mobile search rankings:
You may have heard that here at Google we're
obsessed with speed. As part of that effort,
today we're including a new signal in our search
ranking algorithms: The usage of accelerated
mobile pages (AMP) for even faster results in
mobile search results!

61. Das neue Protokoll des WWWs
#7 Das HTTP/2 Protokoll

62. Browser Support: HTTP/2 ist angekommen!
1 = IE nur mit Win 10; 2 = nur mit HTTPS
Quelle: http://caniuse.com/#feat=http2

63. Server Support: HTTP/2 mit 80%+ Marktabdeckung
Apache 2, nginx, IIS, Netty, Jetty, Squid & 50 andere sind verfügbar!
Quellen: http://pa.ag/1Pwa8fy & http://pa.ag/1Pwa8fy

64. Demo-Time: 200 „kleine“ Bilder im Protokollvergleich:
Bspw. priorisierte Bundles von Requests bringen massive Verbesserungen!
Ausprobieren: http://www.http2demo.io/ & https://http2.akamai.com/demo

65. Was bringt‘s für eure Website? Einfach ausprobieren:
Alle Assets werden heruntergeladen & im Direktvergleich ausgeliefert.
Ausprobieren: http://http2.loadimpact.com/entry/

66. Googlebot mit HTTP/2 Support zum Jahreswechsel!
Noch(!) kein Vorteil bei der Auslieferung an Googles Crawler, aber:
Quelle: http://pa.ag/1HTJCF4

67. Bastian Grimm
bg@peakace.de
twitter.com/peakaceag
facebook.com/peakaceag
peakace.de
http://pa.ag/seokomm2015
Folien zum Herunterladen: