Website-Performance: Websites sichtbar schneller machen

3,609 views
3,506 views

Published on

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.

Published in: Technology
1 Comment
0 Likes
Statistics
Notes
  • Ich hab auf meinem Blog mal zusammengefasst, welche Vorteile mir die Performance Optimierung gebracht hat: http://www.kammerath.net/website-schneller-machen.html
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
3,609
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Website-Performance: Websites sichtbar schneller machen

  1. 1. Website-Performance: Websites sichtbar schneller machen <thomas.witt@infopark.de>
  2. 2. Was kann ich tun, damit (m)eine Web-Site „schnell“ wird?
  3. 3. Wann ist eine Web-Site schnell?
  4. 4. 18% 82%
  5. 5. 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
  6. 6. 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.
  7. 7. Performance ≠ Back-End-Tuning
  8. 8. Messen
  9. 9. http://tinyurl.com/y4aupu
  10. 10. Live HTTP headers http://tinyurl.com/49hcv
  11. 11. Was kann ich tun, damit (m)eine Web-Site „schnell“ wird?
  12. 12. Regel #1 Wenige HTTP- Anfragen
  13. 13. Speaking of Google … Wie „groß“ ist die Homepage von Google?
  14. 14. 19 KByte 2 Requests ~200 ms
  15. 15. Es geht auch anders…
  16. 16. Warum ist das so?
  17. 17. 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
  18. 18. Wie reduziere ich die Anzahl der HTTP Requests?
  19. 19. 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!
  20. 20. 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
  21. 21. 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
  22. 22. 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!
  23. 23. 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
  24. 24. Regel #2 Caching
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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!
  29. 29. Regel #3 Compression
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. Regel #4 CSS oben, JS unten
  36. 36. 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!
  37. 37. JavaScript ans Ende
  38. 38. Regel #4: CSS oben, JS unten CSS-Stylesheets • Genau eines • Am Anfang der Seite JavaScript-Files • Nur eines • Am Ende der Seite
  39. 39. 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!
  40. 40. Empfohlenes Buch http://tinyurl.com/6d4unc
  41. 41. Vielen Dank für Ihre Aufmerksamkeit!

×