Sitespeed - Speed Matters

Sitespeed: Lösungen
Woooooooow bin ich schneeeeeelll
Am 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

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 Server

Client side Caching liefert ab dem Server side Caching liefert eine auf
zweiten Klick eine im Browser dem Server gecachte Version beim
gecachte 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

 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

Sitespeed - Speed Matters

Recomendados

Recomendados

Más contenido relacionado

Más de 121WATT GmbH

Más de 121WATT GmbH (20)

Último

Último (8)

Sitespeed - Speed Matters