Front End Performance Optimierung

Front End Performance
Mehr Geschwindigkeit für Webseiten

Überblick

Worum geht es?

 Messen
 HTTP
 HTML & CSS
 Tools

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

Relevanz

Warum ist Front End Performance wichtig?


Relevanz

Auswirkung auf Website Nutzung

+0,4 Sekunden

Suchanfragen: - 1 %

+ 2 Sekunden

Umsatz: - 4,3 %

+ 0,1 Sekunden

Verkäufe: - 1 %

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


Relevanz

Seit 2010 behandelt Google die Ladezeit
einer Website als Rankingfaktor


Messen

Was ist die Ladezeit einer Website?


Messen

Time to first Byte


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


Messen

Start Render / DOMContentLoaded


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


Messen

Document Complete


Messen

Document Complete

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

 Die JavaScript Engine sendet das „onLoad“-Event


HTTP

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


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


HTTP

Cookies

 Beispiel: 415 Zeichen im Cookie


HTTP

Cookies

 ~70 Requests an denselben Host


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


HTTP

Cookie freie (Sub-)Domain mit TYPO3

1. Neuen ServerAlias eingerichtet


HTTP


2. Per tx_ja_replacer in TYPO3 Links auf statische Dateien ausgetauscht


HTTP


 Keine Cookies mehr bei statischen Dateien:


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


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


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


HTTP

Starkes Caching

GET

200 OK
Expires: 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


HTTP

Starkes Caching - Cache-Control-Header

 Header:

Cache-Control: max-age=31536000, public


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


HTTP

Schwaches Caching

GET

200 OK
E-Tag: 123

GET
E-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.


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

Header set Last-Modified "Mon, 01 Jan 1970 10:00:00 GMT"
</filesMatch>


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-Modified
Header unset Etag


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


HTML & CSS

Performance Optimierung im Quellcode


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.


HTML & CSS


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


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


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:

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


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


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


Tools

Tools zum Testen


Tools

YSlow

 Bewertet verschiedene Faktoren, die zur FE-
Performance beitragen
 Firefox-AddOn
 Integriert sich in Firebug
 Herausgegeben von Yahoo!


Tools

Page Speed von Google

 Ähnliches Prinzip wie YSlow, überprüft aber
teilweise andere Faktoren
 Extension für Chrome
 Herausgegeben von Google


Tools

GTmetrix

 Online-Tool, das YSlow und Page Speed
kombiniert
 http://gtmetrix.com/


Tools

Quellen

 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


Bilder

Bildquellen

 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


dmc digital media center GmbH
Rommelstraße 11
70376 Stuttgart

Telefon: +49 711 601747-0
Telefax: +49 711 601747-141
E-Mail: info@dmc.de
Internet: www.dmc.de

Front End Performance Optimierung

Weitere ähnliche Inhalte

Ähnlich wie Front End Performance Optimierung (20)

Front End Performance Optimierung