Sitespeed: LösungenWoooooooow bin ich schneeeeeelllAm Beispiel der 121watt.de
Timon Hartung                   CTO bei der 121WATT                   Dipl. Wirtschaftsinformatiker                   v...
Die 121watt.de war langsam: 5 sek!   Standard Wordpress    – Mit Plugins    – Angepasstem Template   Average Sitespeed: ...
Problem: Alter langsamer Server,                                      den wir nicht einfach wechseln konnten.blog.twincity...
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...
Veränderungen ohne Server Wechsel   GZIP Komprimierung aktiviert reduziert den    ausgehenden Traffic um 70% bis 90%    –...
Frontend   Mit Screamingfrog und XENU nach 404 Fehlern auf den    Seiten gesucht.   Alle Frames und Weiterleitungen entf...
Frontend: Bilder   Die meist aufgerufenen Bilder noch    einmal optimiert mit smushit von    Yahoo (bis zu 50% besser nac...
Frontend: CSS und JS   Minify Javascript und CSS    – Unnütze Leerzeichen und Zeilenumbrüche werden entfernt    – Wenn es...
Frontend: CDNs und Subdomains       80-90% der Zeit wartet der User auf den Download der statischen       Komponenten der ...
Komponenten Ladezeit ohne CDNs
Frontend: CDNs und Subdomains   Daher HTTP requests parallelisieren   Subdomains gelten als Host so können pro Subdomain...
Komponenten Ladezeit mit CDNs
Backend   Quellcode optimieren unnötige Berechnungen    vermeiden.    – Caching des kompilierten Quellcodes (z.B. APC)  ...
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 liefer...
Caching: Client side   Das Client side Caching erhöht die Ladezeit erst   ab dem zweiten Klick für den User. Weil nicht   ...
Caching: Client side   Cache Control Header    – Macht nur einen HTTP Request wenn das Datum      abgelaufen ist (Vorsich...
Caching: Server side   Server side Caching liefert eine bereits berechnete   Version der Abfrage aus und ist daher schon b...
Caching: Server side   Die Seite wird einmal komplett erzeugt und im Server    Cache abgespeichert. Die nächste Ausliefer...
Exkurs die schnelle First Click Landing Page   Serverside Caching an, dauerhaft erstellt, keine Backend    abfrage.   We...
Entwicklung der 121WATT in den GWMT                 Optimierungszeitraum     CDNs                                        Q...
Takeaways        GZIP aktivieren        HTTP requests reduzieren        CSS sprites verwenden        CSS & JS Minify  ...
Vielen Dank!   Fragen!? Get in touch: Twitter: http://twitter.com/#!/timondeluxe XING: https://www.xing.com/profile/Ti...
Nächste SlideShare
Wird geladen in …5
×

Sitespeed - Speed Matters

2.129 Aufrufe

Veröffentlicht am

Präsentation auf der SMX München 2012 von Timon Hartung von der http://www.121watt.de zum Thema: Sitespeed: Lösungen
Woooooooow bin ich schneeeeeelll
Am Beispiel der 121watt.de

Veröffentlicht in: Bildung
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.129
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
701
Aktionen
Geteilt
0
Downloads
17
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Sitespeed - Speed Matters

  1. 1. Sitespeed: LösungenWoooooooow bin ich schneeeeeelllAm Beispiel der 121watt.de
  2. 2. 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
  3. 3. Die 121watt.de war langsam: 5 sek! Standard Wordpress – Mit Plugins – Angepasstem Template Average Sitespeed: nach GWMT 5sek! Quelle: GWMT
  4. 4. Problem: Alter langsamer Server, den wir nicht einfach wechseln konnten.blog.twincityphotos.com/wp-content/uploads/2010/01/cornerjunk.jpg
  5. 5. Sloooow! 4 sek! Quelle:tools.pingdom.com
  6. 6. Dann habe ich angefangen zu optimieren Frontend Backend Caching Bis die Seite endlich schneller war!
  7. 7. Schneller! 900ms Quelle:tools.pingdom.com
  8. 8. Jetzt sind wir hier! Quelle:tools.pingdom.com
  9. 9. 900ms Ladezeit, Yes! Aber wie habe ich das gemacht?Dieses Bild ist in jeder Präsentation!
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. Komponenten Ladezeit ohne CDNs
  16. 16. 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
  17. 17. Komponenten Ladezeit mit CDNs
  18. 18. 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
  19. 19. Caching Caching ist ein Zwischenspeicher der aufwändige Neuberechnungen zwischenspeichert.
  20. 20. 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
  21. 21. 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.
  22. 22. 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
  23. 23. Caching: Server side Server side Caching liefert eine bereits berechnete Version der Abfrage aus und ist daher schon beim ersten Klick schneller
  24. 24. 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
  25. 25. 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
  26. 26. Entwicklung der 121WATT in den GWMT Optimierungszeitraum CDNs Quelle: GWMT
  27. 27. 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
  28. 28. 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

×