Critical Rendering Path
Das 0,5s Pagespeed Projekt
Zu mir
• 25 Jahre
• Halle(Saale)
• Presales, Kundenprojekte, Schulungen
• Lieblingsthema: Ladezeiten
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
Wie genau definieren wir
Pagespeed?
Für den Nutzer ist
wichtig wann er mit
einer Seite agieren
kann -> 

Pagespeed = Wie
schnell lädt der
sichtbare Bereich 

(above the fold)
1. Warum 0,5 Sekunden?
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
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
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…
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
Ok, das begrenzt das Ganze auf 1s,
warum also

0,5s-Projekt?
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
Was bleibt übrig?
ca. 50% gehen durch Netzwerklatenz verloren

RTT, DNS, TCP, TLS, HTTP

Uns bleiben 500ms zum Laden der eigentlichen Seite!
2. Was ist der Critical Rendering
Path?
Standardoptimierungen
• Bilder komprimieren
• Antwortzeit des Servers reduzieren
• CSS und JS minimieren/optimieren
• Gzip/Deflate Komprimierung aktivieren
• Browser-Caching aktivieren
Wie baut sich eine Seite auf?
<!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
• Critical Rendering Path ist der Weg, den der Browser gehen muss,
bevor er den sichtbaren Bereich ausgeben kann
• 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
• 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
3. Wie optimiert man den
Rendering Path?
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
<!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 />
Network HTML DOM
Rendern
Layout
Paint
Nochmal
CSS CSSOM
Rendern
Layout
Paint
Mehr
Tolle
Sachen
• 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
–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!“
4. Selbstversuch
• gzip aktivieren
• Browser Caching aktivieren
–Erik Euphorie
„88/100? Das hört sich doch gut an, da sind wir bestimmt schon
unter einer Sekunde.“
webpagetest.org
Chrome Browser
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%
Wie bekomme ich heraus was
das Critical CSS ist?
http://jonassebastianohlsson.com/criticalpathcssgenerator/
Und wie schnell ist die Seite
nun!?
webpagetest.org
Chrome Browser
Die Zahlen
• 1,41s - 0,3s = 1,1s schneller!
• 1 - 0,306 / 1,41s = 78,3% Zeitersparnis!!
Trotz 257 Request!
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
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
Vielen Dank für Eure Aufmerksamkeit
• https://www.facebook.com/daniel.gerlach.35
• https://www.seo-hochschule.de

Critical Rendering Path SEO Campixx 2015

  • 1.
    Critical Rendering Path Das0,5s Pagespeed Projekt
  • 2.
    Zu mir • 25Jahre • Halle(Saale) • Presales, Kundenprojekte, Schulungen • Lieblingsthema: Ladezeiten
  • 3.
    Gliederung 1. Warum 0,5Sekunden? 2. Was ist der Critical Rendering Path? 3. Wie optimiert man den Rendering Path? 4. Der Selbstversuch 5. Fazit
  • 4.
    Wie genau definierenwir Pagespeed?
  • 5.
    Für den Nutzerist wichtig wann er mit einer Seite agieren kann -> 
 Pagespeed = Wie schnell lädt der sichtbare Bereich 
 (above the fold)
  • 6.
    1. Warum 0,5Sekunden?
  • 7.
    Allgemeine Daten zumPagespeed • 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.
    Was bedeutet daswirtschaftlich? • Amazons Rechnung:
 1s längere Ladezeit = $1,6Mrd. weniger Verkäufe/Jahr • Googles Rechnung:
 0,4s längere Ladezeit = 8Mil. weniger Searches/Tag
  • 9.
    Delay User Reaction 0-100msInstant 100-300ms Leicht spürbare Verzögerung 300-1000ms Fokus, spürbare Verzögerung 1s+ Gedankliches Abschweifen 10s+ Das wird wohl nix…
  • 10.
    Was bedeutet dasfü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.
    Ok, das begrenztdas Ganze auf 1s, warum also
 0,5s-Projekt?
  • 13.
    Wie viel Zeitkostet 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
  • 14.
    Was bleibt übrig? ca.50% gehen durch Netzwerklatenz verloren
 RTT, DNS, TCP, TLS, HTTP
 Uns bleiben 500ms zum Laden der eigentlichen Seite!
  • 15.
    2. Was istder Critical Rendering Path?
  • 16.
    Standardoptimierungen • Bilder komprimieren •Antwortzeit des Servers reduzieren • CSS und JS minimieren/optimieren • Gzip/Deflate Komprimierung aktivieren • Browser-Caching aktivieren
  • 17.
    Wie baut sicheine Seite auf?
  • 18.
    <!doctype html> <meta charset=utf-8> <title>HalloWelt!</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
  • 19.
    • Critical RenderingPath ist der Weg, den der Browser gehen muss, bevor er den sichtbaren Bereich ausgeben kann
  • 20.
    • Das CSS-Filemuss abgefragt werden, 
 bevor etwas angezeigt werden kann • erst nach Laden der Vollständigen CSS-Datei 
 kann an das Rendern übergeben werden Nochmal
  • 21.
    • 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
  • 22.
    3. Wie optimiertman den Rendering Path?
  • 24.
    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
  • 25.
    <!doctype html> <meta charset=utf-8> <title>HalloWelt!</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 />
  • 26.
    Network HTML DOM Rendern Layout Paint Nochmal CSSCSSOM Rendern Layout Paint Mehr Tolle Sachen
  • 27.
    • der sichtbareBereich 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
  • 28.
    –Zuhörer „Du kannst daja toll drüber reden und erzählen, aber wenn es leicht zu erreichen wäre, würde das ja Jeder machen!“
  • 29.
  • 34.
  • 35.
  • 36.
    –Erik Euphorie „88/100? Dashört sich doch gut an, da sind wir bestimmt schon unter einer Sekunde.“
  • 37.
  • 38.
    1,4s ist nochweit 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%
  • 39.
    Wie bekomme ichheraus was das Critical CSS ist?
  • 40.
  • 44.
    Und wie schnellist die Seite nun!?
  • 45.
  • 46.
    Die Zahlen • 1,41s- 0,3s = 1,1s schneller! • 1 - 0,306 / 1,41s = 78,3% Zeitersparnis!! Trotz 257 Request!
  • 47.
    5. Fazit • DerCritical 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
  • 49.
    Webp • Kann sowohlJPG, 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
  • 50.
    Vielen Dank fürEure Aufmerksamkeit • https://www.facebook.com/daniel.gerlach.35 • https://www.seo-hochschule.de