Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Critical Rendering Path SEO Campixx 2015

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 50 Anzeige

Weitere Verwandte Inhalte

Ähnlich wie Critical Rendering Path SEO Campixx 2015 (20)

Anzeige

Aktuellste (20)

Critical Rendering Path SEO Campixx 2015

  1. 1. Critical Rendering Path Das 0,5s Pagespeed Projekt
  2. 2. Zu mir • 25 Jahre • Halle(Saale) • Presales, Kundenprojekte, Schulungen • Lieblingsthema: Ladezeiten
  3. 3. Gliederung 1. Warum 0,5 Sekunden? 2. Was ist der Critical Rendering Path? 3. Wie optimiert man den Rendering Path? 4. Der Selbstversuch 5. Fazit
  4. 4. Wie genau definieren wir Pagespeed?
  5. 5. Für den Nutzer ist wichtig wann er mit einer Seite agieren kann -> 
 Pagespeed = Wie schnell lädt der sichtbare Bereich 
 (above the fold)
  6. 6. 1. Warum 0,5 Sekunden?
  7. 7. Allgemeine Daten zum Pagespeed • 57% brechen den Besuch einer Website ab, wenn diese nicht in 3s geladen ist • 65% der 18-24 jährigen erwarten eine Ladezeit von 2s und weniger
  8. 8. Was bedeutet das wirtschaftlich? • Amazons Rechnung:
 1s längere Ladezeit = $1,6Mrd. weniger Verkäufe/Jahr • Googles Rechnung:
 0,4s längere Ladezeit = 8Mil. weniger Searches/Tag
  9. 9. Delay User Reaction 0-100ms Instant 100-300ms Leicht spürbare Verzögerung 300-1000ms Fokus, spürbare Verzögerung 1s+ Gedankliches Abschweifen 10s+ Das wird wohl nix…
  10. 10. Was bedeutet das für uns? • 1 Sekunde Zeit um die volle Aufmerksamkeit des Nutzers beizubehalten • Im besten Fall werden Teile der Seite bereits innerhalb von 100ms ausgeliefert • Die Conversion bei langsamen Webseiten geht deutlich in den Keller
  11. 11. Ok, das begrenzt das Ganze auf 1s, warum also
 0,5s-Projekt?
  12. 12. Wie viel Zeit kostet uns das mobile Surfen? LTE HSPA+ HSPA EDGE GPRS AT&T Netwerk Latenz in ms 40-50 50-200 150-400 600-750 600-750
  13. 13. Was bleibt übrig? ca. 50% gehen durch Netzwerklatenz verloren
 RTT, DNS, TCP, TLS, HTTP
 Uns bleiben 500ms zum Laden der eigentlichen Seite!
  14. 14. 2. Was ist der Critical Rendering Path?
  15. 15. Standardoptimierungen • Bilder komprimieren • Antwortzeit des Servers reduzieren • CSS und JS minimieren/optimieren • Gzip/Deflate Komprimierung aktivieren • Browser-Caching aktivieren
  16. 16. Wie baut sich eine Seite auf?
  17. 17. <!doctype html> <meta charset=utf-8> <title>Hallo Welt!</title> <link href=styles.css rel=stylesheet /> <p> Nochmal <span> HALLO WELT!</span></p> index.html p { font-weight: bold; } span { display: none; } styles.css
  18. 18. • Critical Rendering Path ist der Weg, den der Browser gehen muss, bevor er den sichtbaren Bereich ausgeben kann
  19. 19. • Das CSS-File muss abgefragt werden, 
 bevor etwas angezeigt werden kann • erst nach Laden der Vollständigen CSS-Datei 
 kann an das Rendern übergeben werden Nochmal
  20. 20. • CSS & JS werden abgefragt sobald sie im HTML auftauchen • Vor der vollständigen Abfrage der externen Files kann keine Darstellung geschehen • CSS & JS können sich auch noch untereinander blockieren • alles auf Kosten des Nutzers
  21. 21. 3. Wie optimiert man den Rendering Path?
  22. 22. Maßnahmen • CSS & JS in jeweils eine Datei zusammenfassen • CSS & JS an das Ende des <body> versetzen • Für den sichtbaren Bereich benötigtes CSS & JS inline im header integrieren
  23. 23. <!doctype html> <meta charset=utf-8> <title>Hallo Welt!</title> <style type=‚text/css‘> p { font-weight: bold; } span { display: none; } </style> <p> Nochmal <span> HALLO WELT!</span></p> <p>Mehr Tolle Sachen</p> <link href=styles.css rel=stylesheet />
  24. 24. Network HTML DOM Rendern Layout Paint Nochmal CSS CSSOM Rendern Layout Paint Mehr Tolle Sachen
  25. 25. • der sichtbare Bereich wird angezeigt bevor das externe CSS-File überhaupt abgefragt wird • keine zusätzlichen http-request bevor der sichtbare Bereich dargestellt werden kann • User können mit der Seite interagieren, lange bevor diese überhaupt fertig geladen ist
  26. 26. –Zuhörer „Du kannst da ja toll drüber reden und erzählen, aber wenn es leicht zu erreichen wäre, würde das ja Jeder machen!“
  27. 27. 4. Selbstversuch
  28. 28. • gzip aktivieren
  29. 29. • Browser Caching aktivieren
  30. 30. –Erik Euphorie „88/100? Das hört sich doch gut an, da sind wir bestimmt schon unter einer Sekunde.“
  31. 31. webpagetest.org Chrome Browser
  32. 32. 1,4s ist noch weit von unserem Ziel entfernt • Wie viel müssen wir im Critical Rendering Path einsparen? • 1,41s - 0,5s = 0,91s • 1 - 0,5s / 1,41s = 64,5%
  33. 33. Wie bekomme ich heraus was das Critical CSS ist?
  34. 34. http://jonassebastianohlsson.com/criticalpathcssgenerator/
  35. 35. Und wie schnell ist die Seite nun!?
  36. 36. webpagetest.org Chrome Browser
  37. 37. Die Zahlen • 1,41s - 0,3s = 1,1s schneller! • 1 - 0,306 / 1,41s = 78,3% Zeitersparnis!! Trotz 257 Request!
  38. 38. 5. Fazit • Der Critical Rendering Path ist kein Hexenwerk und sollte besonders im E-Commerce Bereich genutzt werden • In unserem Beispiel haben wir eine Zeitersparnis von 78,3% erreicht
  39. 39. Webp • Kann sowohl JPG, PNG, als auch GIF abbilden • Spart 30% bis 65% der Dateigröße ohne Qualitätsverlust • Beide Dateitypen werden auf dem Server 
 abgelegt und je nach Browser ausgegeben
  40. 40. Vielen Dank für Eure Aufmerksamkeit • https://www.facebook.com/daniel.gerlach.35 • https://www.seo-hochschule.de

×