Website-Performance: Websites sichtbar schneller machen

Preview:

DESCRIPTION

Wie beschleunigt man die Ladezeiten einer Web-Site? Die Performanceeiner web-Site hängt nicht nur von den Back-End-Systemen und -Servernab, sondern vielmehr von der Strukturierung und dem Aufbau derWeb-Seite. Dieser Talk, gehalten auf dem iico.de internet congress 2008am 2008-06-04 beschreibt, wie man die Web-Site-Performance massivverbessert.

Citation preview

Website-Performance:Websites sichtbar schneller machen

<thomas.witt@infopark.de>

Was kann ich tun, damit (m)eine Web-Site „schnell“ wird?

Wann ist eineWeb-Site schnell?

18% 82%

Site Leerer Cache Voller Cache

Amazon.com 82% 86%

eBay.com 98% 92%

MSN.com 97% 95%

Myspace.com 96% 86%

Wikipedia.org 80% 88%

Yahoo.com 95% 88%

Youtube.com 97% 95%

Prozentualer Anteil der Ladezeit, der zur Darstellung im Front-End benötigt wird

… die „Responsiveness“ist der kritische Faktor in Sachen User Experience.

Insbesondere für wiederkehrende Nutzer.

Für Erhöhung der Responsiveness reicht aber Back-End-Tuning nicht aus.

Google hat uns gezeigt …

Performance≠

Back-End-Tuning

Messen

http://tinyurl.com/y4aupu

Live HTTP headers

http://tinyurl.com/49hcv

Was kann ich tun, damit (m)eine Web-Site „schnell“ wird?

Wenige HTTP-Anfragen

Regel #1

Speaking of Google …

Wie „groß“ ist die Homepage von

Google?

19 KByte2 Requests

~200 ms

Es geht auch anders…

Warum ist das so?

Kein HTTP Pipelining• IE: 2 Verbindungen/Host• Serielle Verarbeitung

Upload-Geschwindigkeit• 5:1 - 20:1-Ratio bei DSL• HTTP-Request: 500 Bytes,

Problem für Objekte <10k

HTTP-Verbindungen

http://tinyurl.com/yedmux

Wie reduziere ich die Anzahl der HTTP Requests?

Asset Server mit DNS-VerteilungDer Browser beherrscht nur 2 Verbindungen pro Host

Also: Mehr Hosts!• image1.domain.de• image2.domain.de• image3.domain.de

- alles der gleiche Server

Optimale Anzahl: 4• CSS, JavaScript, Bilder• Overhead für DNS-Query

- DNS Browser Cache!

Kombinieren von Bildern• Viele Bestandteile in

einem großen Bild• Auswahl via CSS• Ggf. nachladen via JS

Vorteile• Geringere Größe als

Einzelbilder• Nur EIN HTTP-Request

Nachteile• Nur moderne Browser

CSS-Sprites

http://tinyurl.com/2fyqhp

HTTP/1.1 Keepalives

Wiederverwenden einer HTTP-Verbindung• Overhead für Neuaufbau

der TCP/IP-Verbindung entfällt

Konfiguration viaWeb-Server

Voraussetzung für Pipelining

Jeweils nur ein CSS und JS-Objekt

Nur ein JavaScript, nur ein CSS-Objekt pro Seite• Bei CSS einfach• Bei JS etwas schwerer

- Reihenfolge wichtig!

Automatisierte Lösungen• Out-of-the-Box bei Rails 2

CSS/JS immer extern referenzieren!

Regel #1: Zusammenfassung

So wenig HTTP-Anfragen wie möglich• Maßgeblicher Faktor für

Front-End Performance

Reduzieren via• CSS Sprites• HTTP Keepalives• Asset-Server• Nur ein CSS/JS-File

Caching

Regel #2

CachingAssets clientseitig cachen• Bilder, CSS, JavaScript• Beschleunigt Folgeseiten

Via HTTP-Header

If-Modified-Since• Reduzierung des

Datenvolumens

Expires• Zusätzliche Reduzierung

der HTTP-Requests

If-Modified-Since1. Antwort• Der Server sendet das

Änderungsdatum

2. Anfrage• Der Client fragt, ob das

Objekt seitdem geändert wurde

Ergebnis• Keine erneute

Datenübertragung• Ein HTTP-Request

GET /images/logo.png HTTP/1.1Host: www.kundensite.de

HTTP/1.1 200 OKLast-Modified: Thu, 21 Feb 2008 12:18:57 GMT

[... Daten ...]

GET /images/logo.png HTTP/1.1Host: www.kundensite.deIf-Modified-Since: Thu, 21 Feb 2008 12:18:57 GMT

HTTP/1.1 304 Not Modified

Expires1. Antwort• Der Server sendet das

Ablaufdatum

2. Ergebnis• Der Browser fragt nie

mehr nach dem Objekt, solange es im Cache ist

Tip• Ggf. Anhängen von IDs

an das Objekt- image.png?123531

GET /images/hugeimage.jpg HTTP/1.1Host: www.kundensite.de

HTTP/1.1 200 OKExpires: Wed, 25 Jun 2008 09:00:00 GMT

[... Daten ...]

Regel #2: ZusammenfassungCachen, wo es geht• Beschleunigt Folgeseiten• Nur für wiederkehrende

Benutzer

Datenübertragung reduzieren via• If-Modified-Since• Expires

Anmerkung:• ETags vermeiden!

Regel #3

Compression

CompressionReduzierung der Größe der zu übertragenden Daten

Vorab• Bilder optimieren• JS/CSS minimieren

On-The-Fly• Anfrage vom Browser

nach komprimierten Daten

• Der Webserver verschickt komprimiert

On-The-Fly-KomprimierungApache: mod_deflate• Standard-Modul• Gzip verwenden!

Vorteile• Massive Datenreduktion

- Bei JS/CSS bis zu 80%

Nachteile• CPU-Verbrauch

auf dem Server• Probleme mit alten IEs

Unkomprimiert Komprimiert

Vorab-KomprimierungBilder vorab optimieren• Nur JPEG und PNG!

CSS verkleinern• Files zusammenfügen• Unnötiges entfernen:

- 0px=0, Kommentare- z. B. CSSTidy

JavaScript verkleinern• JavaScript Minifier

- z. B. JSMin, Dojo• Bis zu 25% Reduktion

http://tinyurl.com/2tajlb · http://tinyurl.com/jum6g

Cookies klein halten!Compression wirkt nicht für HTTP-Header• Betrifft insbesondere

Cookies• Besonders schlimm bei

DSL-Leitungen

Keine automatisierte Lösung• auf große Datenmengen

im Cookie verzichten• ggf. via JS nach Laden

aller Elemente setzen

Regel #3: ZusammenfassungCompression verkürzt Ladezeiten• Wirkt schon bei erstem

Besuch

Nachteil• Wirkt nicht für HTTP-

Header- Cookies!

Einfach zu realisieren• mod_deflate im Apache

Regel #4

CSS oben,JS unten

Reihenfolge CSS/JSCSS-Files an den Anfang• Progressive Rendering:

- Visuelles Feedback anstatt weiße Seite

• <link> anstatt @import!

JS ans Ende• Scripts verhindern

Rendering aller Elemente unterhalb des Scripts

• Scripts blockieren alle offenen Downloads!

JavaScript ans Ende

Regel #4: CSS oben, JS unten

CSS-Stylesheets• Genau eines• Am Anfang der Seite

JavaScript-Files• Nur eines• Am Ende der Seite

Zusammenfassung

#1: Wenige HTTP-Requests• Sprites, Asset Server

#2: Caching• Expires, Modified-Since

#3: Compression• Gzip, CSS/JS minify

#4: CSS oben, JS unten• Reihenfolge ist wichtig!

Empfohlenes Buch

http://tinyurl.com/6d4unc

Vielen Dank für Ihre Aufmerksamkeit!

Recommended