Sitespeed - Speed Matters
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
Uploaded on

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

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

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,940
On Slideshare
1,275
From Embeds
665
Number of Embeds
3

Actions

Shares
Downloads
15
Comments
0
Likes
2

Embeds 665

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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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