Post on 18-Dec-2014
description
transcript
Sitespeed: LösungenWoooooooow bin ich schneeeeeelllAm Beispiel der 121watt.de
Timon Hartung
CTO bei der 121WATT
Dipl. Wirtschaftsinformatiker
vorher Head of Online Marketing bei amiando.com (XING Tochter)
kann JAVA, PHP, MySQL, … programmieren
macht SEO, SEA, Facebook
habe 18Kg seit der letzten SMX abgenommen
Die 121watt.de war langsam: 5 sek!
Standard Wordpress– Mit Plugins– Angepasstem Template
Average Sitespeed:nach GWMT 5sek!
Quelle: GWMT
Problem: Alter langsamer Server, den wir nicht einfach wechseln konnten.
Quelle: http://photoblog.twincityphotos.com/wp-content/uploads/2010/01/cornerjunk.jpg
4 sek! Quelle:tools.pingdom.com
Sloooow!
Dann habe ich angefangen zu optimieren
Frontend
Backend
Caching
Bis die Seite endlich schneller war!
900ms Quelle:tools.pingdom.com
Schneller!
Jetzt sind wir hier!
Quelle:tools.pingdom.com
900ms Ladezeit, Yes!
Aber wie habe ichdas gemacht?
Dieses Bild ist in jeder Präsentation!
Veränderungen ohne Server Wechsel
GZIP Komprimierung aktiviert reduziert den ausgehenden Traffic um 70% bis 90%– Einfach in der .htaccess zu aktivieren – Tipp: die DEFLATE Komprimierung Alternative ist noch
einmal ca. 40% schneller als GZIP wegen der fehlenden md5 Checksum
Frontend
Mit Screamingfrog und XENU nach 404 Fehlern auf den Seiten gesucht.
Alle Frames und Weiterleitungen entfernt– Wenn Weiterleitung dann in der .htaccess
DOM Verschachtelung reduziert um Renderzeit zu sparen. Nicht auf großen DOMs mit JS arbeiten.
HTTP requests reduziert:– CSS Sprites– CSS und JS Minify
Frontend: Bilder
Die meist aufgerufenen Bilder noch einmal optimiert mit smushit von Yahoo (bis zu 50% besser nach Photoshop Optimierung)
CSS Image Sprites erstellt Tools: http://spritepad.wearekiss.com/ oder http://spriteme.org/
Mit HTML skalierte Bilder entfernt und die richtige Größe hochgeladen (kostet CPU Zeit zum berechnen)
Quelle: Sprite von google.com
Frontend: CSS und JS
Minify Javascript und CSS– Unnütze Leerzeichen und Zeilenumbrüche werden entfernt– Wenn es mehrere Dateien gibt werde diese in eine große
zusammengefasst um die HTTP requests zu reduzieren.
CSS oben in den <head>– Sehr flache CSS Verschachtelung am besten nur eine Id
oder Klasse als Selektor verwenden <div class=“unique“>
Javascript unten vor dem </body> laden Alle inline JS und CSS Dateien extern auslagern
Frontend: CDNs und Subdomains
80-90% der Zeit wartet der User auf den Download der statischen Komponenten der Website
Aktuelle Browser öffnen ca. 6 Verbindungen gleichzeitig pro Host. (bei durchschnittlich 50 – 100 Komponenten)
Quelle: http://www.pharmacyowners.com/Portals/37772/images/It-can-be-a-LONG-wait-at-the-pharmacy-resized-600.jpg
Komponenten Ladezeit ohne CDNs
Frontend: CDNs und Subdomains
Daher HTTP requests parallelisieren
Subdomains gelten als Host so können pro Subdomain 6 Verbindungen aufgemacht werden. – Mit mehreren Subdomains lassen sich HTTP request
parallelisieren– Allerdings erhöht sich die DNS abfrage zeit daher nicht
mehr als 4 Sub Domains einsetzen.
Vorteil CDN: hohe Geschwindigkeit bei der Auslieferung
Komponenten Ladezeit mit CDNs
Backend
Quellcode optimieren unnötige Berechnungen vermeiden.– Caching des kompilierten Quellcodes (z.B. APC)
Datenbank abfragen optimieren und reduzieren– Datenbank Queries cachen
Flush Buffer Early:– <?php flush()?>– Zeigt schon HTML an auch wenn das Backend noch
arbeitet.– Sinnvoll für stark Backend lastige Seiten
Caching
Caching ist ein Zwischenspeicher der aufwändige Neuberechnungen zwischenspeichert.
Client side Caching im Browser Server side Caching durch den Server
Die zwei Caching Arten
Server side Caching liefert eine auf dem Server gecachte Version beim ersten Klick an Browser
Client side Caching liefert ab dem zweiten Klick eine im Browser gecachte Version an den User aus
Caching: Client side
Das Client side Caching erhöht die Ladezeit erst ab dem zweiten Klick für den User. Weil nicht alle Komponenten neu geladen werden müssen.
Caching: Client side
Cache Control Header– Macht nur einen HTTP Request wenn das Datum
abgelaufen ist (Vorsicht mit CSS und JS Dateien) – Sinnvoll bei Bildern und statischen Komponenten
E Tags– Macht immer einen request um dann zu entscheiden oder
die Datei gesendet werden soll oder ein 304 zurück kommt und die Version aus dem Cache genommen werden soll
Caching: Server side
Server side Caching liefert eine bereits berechnete Version der Abfrage aus und ist daher schon beim ersten Klick schneller
Caching: Server side
Die Seite wird einmal komplett erzeugt und im Server Cache abgespeichert. Die nächste Auslieferung erfolgt direkt ohne Backend abfrage, was die Ladezeit stark verkürzt.
Das reduziert die Last auf dem Backend erheblich schränkt aber die Dynamik ein.
Ajax lädt einfach die dynamischen Elemente nach
Spannende Tools:– APC PHP Caching, MemCache (Datenbanken), Varnish
Exkurs die schnelle First Click Landing Page
Serverside Caching an, dauerhaft erstellt, keine Backend abfrage.
Wenig HTML und geringe tiefe des DOM Um noch einmal HTTP requests zu sparen
– Unkompliziertes CSS und JS ist inline im HTML – Kleine Bilder als CSS Sprite
Early Buffer Flush Diskussion: verwenden von base64 images im HTML
Code Keine Cookies Analytics Pixel anstatt von JS
Entwicklung der 121WATT in den GWMT
Optimierungszeitraum CDNs
Quelle: GWMT
Takeaways
GZIP aktivieren HTTP requests reduzieren CSS sprites verwenden CSS & JS Minify Keine komplizierten CSS Selektoren HTML DOM klein halten Caching an
CDNs
Quelle: http://www.kildalkeyvillage.com/images/tn_rossi-takeaway-ext.jpg
Vielen Dank!
Fragen!?
Get in touch: Twitter: http://twitter.com/#!/timondeluxe XING: https://www.xing.com/profile/Timon_Hartung G+: https://plus.google.com/100734808651715229257/ or google my name