front end performance optimierung

Front End PerformanceMehr Geschwindigkeit für Webseiten

| © dmc digital media center GmbH 2012 |Front End Performance – Mehr Geschwindigkeit für Webseiten

Überblick

Worum geht es?

Messen HTTP HTML & CSS Tools

12.07.2012 | Folie 2


Relevanz

Warum ist Front End Performance wichtig?

12.07.2012 | Folie 3


Relevanz

Auswirkung auf Website Nutzung

12.07.2012 | Folie 4

+0,4 Sekunden

Suchanfragen: - 1 %

+ 2 Sekunden

Umsatz: - 4,3 %

+ 0,1 Sekunden

Verkäufe: - 1 %

Quellen: http://www.slideshare.net/guestbf04d7/fronteers-20091105-1http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/

http://www.slideshare.net/guestbf04d7/fronteers-20091105-1

http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/


Relevanz

12.07.2012 | Folie 5

Seit 2010 behandelt Google die Ladezeit einer Website als Rankingfaktor


Messen

Was ist die Ladezeit einer Website?

12.07.2012 | Folie 6


Messen

Time to first Byte

12.07.2012 | Folie 7


Messen

Time to first Byte

Zeit vom Beginn unserer Abfrage, bis der Browser das erste Byte der Antwort empfängt

Kann für jeden einzelnen Request berechnet werden, uns interessiert aber vor allem die initiale Anfrage der Seite

Bei Redirects interessiert uns die Zeit vom Absenden unserer Anfrage bis zum ersten Byte der endgültigen Antwort

dns Lookup + Socket Connect + Warten

Wird hauptsächlich durch die Back End Performance bestimmt

12.07.2012 | Folie 8


Messen

Start Render / DOMContentLoaded

12.07.2012 | Folie 9


Messen

Start Render / DOMContentLoaded

Zeitpunkt, zu dem der Browser mit dem Rendering der Webseite beginnt

Üblicherweise, sobald das CSS vollständig geladen ist

Wird durch Unterschiede bei den Browsern beeinflusst

12.07.2012 | Folie 10


Messen

Document Complete

12.07.2012 | Folie 11


Messen

Document Complete

Das Dokument wurde vollständig im Browser aufgebaut und alle Komponenten sind vorhanden

Die JavaScript Engine sendet das „onLoad“-Event

12.07.2012 | Folie 12


HTTP

12.07.2012 | Folie 13

HTTP – Anzahl und Aussehen der Requests


HTTP

Zahl der Requests vermindern

Jeder Request erzeugt neuen Overhead durch das Senden der Anfrage, den „Verbindungsaufbau“ und das Empfangen

Icons als CSS-Sprites zusammenfassen− Div. Online-Tools, z.B.:

http://spritegen.website-performance.org/

Mehrere CSS- und JavaScript-Dateien jeweils zu einer Datei zusammenfassen

12.07.2012 | Folie 14

http://spritegen.website-performance.org/


HTTP

Komprimierung

Vor der Übertragung sollte der Server die Daten komprimieren.

CSS und JavaScript sollte noch auf Textbasis optimiert werden, Tools:

− Minify (allg.)

− Scriptmerger (TYPO3)

Alle Daten (außer jpg/png-Grafiken) sollten zusätzlich per Gzip komprimiert werden

PayOff: Serverseitig minimal größere Rechenzeit

12.07.2012 | Folie 15


HTTP

Cookies

Beispiel: 415 Zeichen im Cookie

12.07.2012 | Folie 16


HTTP

Cookies

~70 Requests an denselben Host

12.07.2012 | Folie 17


HTTP

Cookies

= 70 x 415 Bytes = ~ 29 kB unnötiger Upload Traffic bei jedem Seitenaufruf

Deshalb: Cookiegröße minimieren am besten nur eine Session-ID ausliefern und alles andere

serverseitig abhandeln

Statische Dateien von eine Cookie freien (Sub-)Domain ausliefern− Payoff: Mehr dns-Abfragen

12.07.2012 | Folie 18


HTTP

Cookie freie (Sub-)Domain mit TYPO3

1. Neuen ServerAlias eingerichtet

12.07.2012 | Folie 19


HTTP


2. Per tx_ja_replacer in TYPO3 Links auf statische Dateien ausgetauscht

12.07.2012 | Folie 20


HTTP


Keine Cookies mehr bei statischen Dateien:

12.07.2012 | Folie 21


HTTP

Ein CDN benutzen

Über ein Content Delivery Network wird die Last bei der Abfrage von statischen Dateien auf mehrere Server verteilt.

Nutzer erhalten die Daten von den jeweils geographisch nächsten und bestverfügbaren Knoten

Pay-Off: dns-Lookups erzeugen zusätzlichen Overhead

12.07.2012 | Folie 22


HTTP

Clientseitiges Caching ermöglichen

Spezielle HTTP-Header steuern, wie der Browser (und Proxy-Server) die Server-Antworten speichert

Zahl der Anfragen wird verringert

Eine Anfrage, die nicht neu beantwortet werden muss, ist die am schnellsten verarbeitete Anfrage

12.07.2012 | Folie 23


HTTP

Zwei Arten von Caching

Starkes Caching: − Der Browser versucht gar nicht erst, eine im Cache vorhandene Datei neu anzufordern

− Ideal für statische Dateien

Schwaches Caching:− Der Browser erwartet nur dann eine vollständige Antwort, wenn es eine neue Version der Datei gibt

− Kann auch für dynamische Dateien genutzt werden

12.07.2012 | Folie 24


HTTP

Starkes Caching

12.07.2012 | Folie 25

GET

200 OKExpires: Fri, 13 Jul 2012 11:21:23 GMT


HTTP

Starkes Caching - Expires-Header

Header:

Expires: Tue, 26 Mar 2013 10:00:00 GMT

Serverkonfiguration:

<filesMatch "\.(jpg|png|gif|css|js)$">ExpiresDefault "acces plus 1 years"

</filesMatch>

Der Server ruft erst nach dem angegebenen Datum eine neue Version ab

12.07.2012 | Folie 26


HTTP

Starkes Caching - Cache-Control-Header

Header:

Cache-Control: max-age=31536000, public


<filesMatch "\.(jpg|png|gif|css|js)$">Header set Cache-Control "max-age=31536000, public"

</filesMatch>

Angabe public bedeutet, dass auch Proxys die Datei speichern können

Entweder Expires oder Cache-Control nutzen, nicht beides zusammen

12.07.2012 | Folie 27


HTTP

Schwaches Caching

12.07.2012 | Folie 28

GET

200 OKE-Tag: 123

GETE-Tag: 123

304 Not Modified


HTTP

Schwaches Caching - ETag

Header:

ETag: „12bh-8f7g-1dsd"


FileETag MTime Size

Achtung: Ohne diese Konfiguration nutzt Apache die aktuelle inode-Nummer zur Berechnung des ETags. Dadurch erhalten Dateien unterschiedliche ETags, je nachdem, welcher Knoten die Anfrage beantwortet.

12.07.2012 | Folie 29


HTTP

Schwaches Caching – Last-Modified

Header:

Last-Modified: Mon, 21 Feb 2011 10:00:00 GMT

Serverkonfiguration: Nur notwendig, wenn der Header explizit gesetzt werden soll

<filesMatch "\.(jpg|png|gif|css|js)$">Header set Last-Modified "Mon, 01 Jan 1970 10:00:00 GMT"

</filesMatch>

12.07.2012 | Folie 30


HTTP

Priorität

Bei statischen Dateien, sollte starkes Caching dem schwachen Caching vorgezogen werden

Um Anfragen durch den Browser für gecachte Seite komplett zu vermeiden, sollten sowohl das ETag als auch Last-Modfied sicherheitshalber deaktiviert werden, wenn starkes Caching angewandt wird:

Header unset Last-ModifiedHeader unset Etag

12.07.2012 | Folie 31


HTTP

SPDY [SPeedY]

Experimentelles Sitzungsprotokoll, das von Google entwickelt wird

Eigenschaften:− Multiplexed Streams

Mehrere Streams über eine einzelne TCP-Verbindung

− Request-Priorisierung

− HTTP-Header-Kompression

− Server-Push: Der Server kann ungefragt Daten an den Client ausliefern, die dieser wahrscheinlich benötig.

− Server-Hint Der Server kann den Client auf weitere Daten hinweisen, die dieser wahrscheinlich benötigt.

Von Firefox 11+ und Chrome unterstützt

Eigenes Modul für Apache ist vorhanden

Mehr Informationen: http://dev.chromium.org/spdy

12.07.2012 | Folie 32

http://dev.chromium.org/spdy


HTML & CSS

Performance Optimierung im Quellcode

12.07.2012 | Folie 33


HTML & CSS

Beschleunigung des „Start to Render“

Zeichensatz im Content-Type-Header (HTTP)− Der Browser kann gleich mit der Verarbeitung des Quellcodes beginnen und muss nicht erst den

Zeichensatz ermitteln.

12.07.2012 | Folie 34


HTML & CSS


CSS am Anfang der Seite− Der Browser beginnt erst mit dem Rendern, sobald das CSS vollständig geladen ist.

12.07.2012 | Folie 35


HTML & CSS


JavaScript ganz am Ende der Seite− Der Browser unterbricht das Rendern des Seiteninhalts, bis er das komplette JavaScript gerendert hat

Ideal: JavaScript nachladen, wenn „onLoad“ gefeuert wird:

Quelle: https://developers.google.com/speed/docs/best-practices/payload?hl=de#DeferLoadingJS

12.07.2012 | Folie 36

https://developers.google.com/speed/docs/best-practices/payload?hl=de


HTML & CSS


Bei der ersten Anfrage so wenige Inhalte wie möglich laden− Alles andere kann später noch geladen werden

− Achtung: SEO-relevante Inhalte müssen immer geladen werden!

Beispiel Amazon:

12.07.2012 | Folie 37

Mit JavaScript Ohne JavaScript


HTML & CSS

Langsame CSS-Selektoren

Generische Selektoren: body *− Selektoren so spezifisch wie möglich machen, um unnötige Prüfungen zu vermeiden

Tags als letzter Selektor: ul li a− Der Browser muss für jedes Tag ermitteln, ob der Selektor passt und dafür bei allen, wo er nicht passt,

bis zur root-node zurückgehen

− Besser Klassen verwenden: a.linkInAList

Redundante Selektoren: ul#importantList− Die id ist sowieso eindeutig

12.07.2012 | Folie 38


HTML & CSS

CSS beschleunigen

Nur die CSS-Regeln angeben, die notwendig sind− Auch ungenutzte Regeln müssen vom Browser geprüft und verarbeitet werden

− CSS-Dateien in Modulen aufsplitten und nur die benötigten beim Laden mergen und ausliefern

− Payoff: CSS-Dateien können nicht mehr so gut gecachet werden (Ein großer Nachteil)

@import vermeiden

12.07.2012 | Folie 39


HTML & CSS

Diverses

Keine leeren src- oder href-Attribute− Manche Browser senden bei nicht angegebenen Dateinamen noch einen Request für das Root-

Verzeichnis der Domain

Zahl der DOM-Elemente reduzieren

Immer „width“ und „height“ von Bilder angeben

AJAX beschleunigen und Browser Caching für AJAX ermöglichen

12.07.2012 | Folie 40


Tools

Tools zum Testen

12.07.2012 | Folie 41


Tools

YSlow

12.07.2012 | Folie 42

Bewertet verschiedene Faktoren, die zur FE-Performance beitragen

Firefox-AddOn Integriert sich in Firebug Herausgegeben von Yahoo!


Tools

Page Speed von Google

12.07.2012 | Folie 43

Ähnliches Prinzip wie YSlow, überprüft aber teilweise andere Faktoren

Extension für Chrome Herausgegeben von Google


Tools

GTmetrix

12.07.2012 | Folie 44

Online-Tool, das YSlow und Page Speed kombiniert

http://gtmetrix.com/

http://gtmetrix.com/


Tools

Quellen

12.07.2012 | Folie 45

Sammlung von Best Practices bei Google - https://developers.google.com/speed/docs/best-practices/rules_intro

Best Practices bei Yahoo! - http://developer.yahoo.com/performance/rules.html

https://developers.google.com/speed/docs/best-practices/rules_intro

http://developer.yahoo.com/performance/rules.html


Bilder

Bildquellen

12.07.2012 | Folie 46

Folie 1− Bild von Mostly Dans (flickr), Lizenz: CC-BY 2.0

Folie 3− Bild von wwarby (flickr), Lizenz: CC-BY 2.0

Folie 13− Bild von internets_dairy (flickr), Lizenz: CC-BY 2.0

Folie 41− Bild von mueritz (flickr), Lizenz, Lizenz: CC BY-SA 2.0

http://www.flickr.com/photos/dannyboymalinga/

http://www.flickr.com/photos/dannyboymalinga/

http://creativecommons.org/licenses/by/2.0/deed.de

http://www.flickr.com/photos/wwarby/

http://creativecommons.org/licenses/by/2.0/deed.de

http://www.flickr.com/photos/16339684@N00/

http://creativecommons.org/licenses/by/2.0/deed.en

http://www.flickr.com/photos/mecklenburg/

http://creativecommons.org/licenses/by-sa/2.0/deed.en

dmc digital media center GmbHRommelstraße 1170376 Stuttgart

Telefon: +49 711 601747-0Telefax: +49 711 601747-141 E-Mail: [email protected]: www.dmc.de

front end performance optimierung

Technology

end performance bestimmt

end performance wichtig

denverbindungsaufbau

browser mit dem

messen http html css

byte zeit

httphttp anzahl und

erste byte