Website-Performance: Websites sichtbar schneller machen
Upcoming SlideShare
Loading in...5
×
 

Website-Performance: Websites sichtbar schneller machen

on

  • 4,419 views

Wie beschleunigt man die Ladezeiten einer Web-Site? Die Performance...

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

Statistics

Views

Total Views
4,419
Views on SlideShare
4,402
Embed Views
17

Actions

Likes
0
Downloads
14
Comments
1

3 Embeds 17

http://www.slideshare.net 13
http://lanyrd.com 3
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Ich hab auf meinem Blog mal zusammengefasst, welche Vorteile mir die Performance Optimierung gebracht hat: http://www.kammerath.net/website-schneller-machen.html
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Website-Performance: Websites sichtbar schneller machen Website-Performance: Websites sichtbar schneller machen Presentation Transcript

  • Website-Performance: Websites sichtbar schneller machen <thomas.witt@infopark.de>
  • Was kann ich tun, damit (m)eine Web-Site „schnell“ wird?
  • Wann ist eine Web-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
  • Google hat uns gezeigt … … 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.
  • 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?
  • Regel #1 Wenige HTTP- Anfragen
  • Speaking of Google … Wie „groß“ ist die Homepage von Google?
  • 19 KByte 2 Requests ~200 ms
  • Es geht auch anders…
  • Warum ist das so?
  • HTTP-Verbindungen 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://tinyurl.com/yedmux
  • Wie reduziere ich die Anzahl der HTTP Requests?
  • Asset Server mit DNS-Verteilung Der 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!
  • CSS-Sprites 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 http://tinyurl.com/2fyqhp
  • HTTP/1.1 Keepalives Wiederverwenden einer HTTP-Verbindung • Overhead für Neuaufbau der TCP/IP-Verbindung entfällt Konfiguration via Web-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
  • Regel #2 Caching
  • Caching Assets 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-Since 1. Antwort GET /images/logo.png HTTP/1.1 • Der Server sendet das Host: www.kundensite.de Änderungsdatum HTTP/1.1 200 OK 2. Anfrage Last-Modified: Thu, 21 Feb 2008 12:18:57 GMT • Der Client fragt, ob das [... Daten ...] Objekt seitdem geändert wurde GET /images/logo.png HTTP/1.1 Host: www.kundensite.de If-Modified-Since: Thu, 21 Feb 2008 12:18:57 GMT Ergebnis • Keine erneute Datenübertragung HTTP/1.1 304 Not Modified • Ein HTTP-Request
  • Expires 1. Antwort • Der Server sendet das Ablaufdatum 2. Ergebnis GET /images/hugeimage.jpg HTTP/1.1 Host: www.kundensite.de • Der Browser fragt nie mehr nach dem Objekt, solange es im Cache ist HTTP/1.1 200 OK Expires: Wed, 25 Jun 2008 09:00:00 GMT [... Daten ...] Tip • Ggf. Anhängen von IDs an das Objekt - image.png?123531
  • Regel #2: Zusammenfassung Cachen, wo es geht • Beschleunigt Folgeseiten • Nur für wiederkehrende Benutzer Datenübertragung reduzieren via • If-Modified-Since • Expires Anmerkung: • ETags vermeiden!
  • Regel #3 Compression
  • Compression Reduzierung 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-Komprimierung Apache: 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-Komprimierung Bilder 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: Zusammenfassung Compression 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/JS CSS-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!