Upload
daniel-gerlach
View
1.042
Download
3
Embed Size (px)
Citation preview
Zu mir
• 25 Jahre
• Halle(Saale)
• Presales, Kundenprojekte, Schulungen
• Lieblingsthema: Ladezeiten
Gliederung1. Warum 0,5 Sekunden?
2. Was ist der Critical Rendering Path?
3. Wie optimiert man den Rendering Path?
4. Der Selbstversuch
5. Fazit
Für den Nutzer ist wichtig wann er mit einer Seite agieren
kann -> Pagespeed = Wie schnell lädt der
sichtbare Bereich (above the fold)
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
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!
Standardoptimierungen• Bilder komprimieren
• Antwortzeit des Servers reduzieren
• CSS und JS minimieren/optimieren
• Gzip/Deflate Komprimierung aktivieren
• Browser-Caching aktivieren
<!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
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 />
• 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!“
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%
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