Sitespeed - Speed Matters

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.blog.twincityphotos.com/wp-content/uploads/2010/01/cornerjunk.jpg

Sloooow! 4 sek! Quelle:tools.pingdom.com

Dann habe ich angefangen zu optimieren Frontend Backend Caching Bis die Seite endlich schneller war!

Schneller! 900ms Quelle:tools.pingdom.com

Jetzt sind wir hier! Quelle:tools.pingdom.com

900ms Ladezeit, Yes! Aber wie habe ich das 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.

Die zwei Caching Arten Client side Caching im Browser Server side Caching durch den ServerClient side Caching liefert ab dem Server side Caching liefert eine aufzweiten Klick eine im Browser dem Server gecachte Version beimgecachte Version an den User aus ersten Klick an Browser

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  CDNsQuelle: 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

http://www.121watt.de	355
http://blog.121watt.de	193
http://www.newsblur.com	1

Sitespeed - Speed Matters

by 121WATT Online Marketing, SEO und Google Analytics Seminare on Apr 02, 2012

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 549

Statistics

Sitespeed - Speed Matters Presentation Transcript