Frontend Performance

Jakob Schröter

20.01.2012 @ Hochschule der Medien Stuttgart

Bachelor of Computer Science in Media Master of Computer

Science and Media

Kajona CMS

Frontend Engineer

Schlagzeuger

Wanderer

PERFORMANCE

FRONTEND PERFORMANCE

Spalte2 LADEZEIT?

50 ms

100 ms

500 ms

1000 ms

Einfluss der Ladezeit

Glückliche User Mehr User

Mehr Umsatz

Kurze Ladezeit

Einfluss der Ladezeit

Amazon +100 ms 1 % weniger Verkäufe1

Yahoo +400 ms 5-9 % weniger Zugriffe1

Google +500 ms 20 % weniger Zugriffe1

Bing +2000 ms 4,3 % weniger Umsatz/Nutzer2

Shopzilla -5000 ms 25 % mehr Zugriffe

7-12 % mehr Umsatz

50 % weniger Hardware3

Mozilla -2200 ms 15,4 % mehr Downloads4

1 http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/ 2 http://www.slideshare.net/dyninc/the-user-and-business-impact-of-server-delays-additional-bytes-and-http-chunking-in-web-search-presentation 3 http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html 4 http://blog.mozilla.com/metrics/category/website-optimization/

User Experience

Empfohlene Ladezeit:

– vor 2006: unter 8 Sekunden Jupiter research

– 2006: unter 4 Sekunden Jupiter research

– 2009: unter 2 Sekunden Forrester Research

„Jede Website, deren Ladezeit eine Sekunde überschreitet, tut dem Benutzer weh.“ Jakob Nielsen

http://www.stevesouders.com/blog/2010/05/07/wpo-web-performance-optimization/

10 Golden Principles of Successful Web Apps

Speed Instant Utility

Software is Media

Less is More

Make it Programmable

Make it Personal

RESTful

Discoverabilty

Clean

Playful

http://thinkvitamin.com/web-apps/fred-wilsons-10-golden-principles-of-successful-web-apps/

SEO -> WPO

• Ist Search Engine Optimization ist ein Thema von gestern?

• Performance beeinflusst Google Ranking seit April 2010

„Das Internet ist nicht schneller geworden“

http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2

PERFORMANCE OPTIMIEREN Messen: z.B. JMeter

Bottlenecks finden: Profiling des Backends

Code optimieren / mehr Server-Hardware / bessere Server-Anbindung

Was wollen wir messen?

Wahrgenommene Wartezeit!

= Inhalt ist für den Nutzer sichtbar

= Nutzer denkt, er kann interagieren

Performance messen #1

• HTML-Seite generiert und geladen

• DOM-Ready-Event DOM ist aufgebaut, Inhalt evtl. sichtbar

• OnLoad-Event alle Ressourcen wurden geladen, Inhalt evtl. sichtbar

• Definiertes DOM-Element sichtbar

• „Above the Fold“ (AFT) keine Änderungen mehr am sichtbaren Inhalt

Performance messen #2

• verschiedene Clients

• verschiedene Locations

• verschiedenen Anbindungen

• Performance kontinuierlich messen…

80%

20%

Wahrgenommene Ladezeit einer Webseite

80%

20%

Wahrgenommene Ladezeit einer Webseite

80%

20%

Client

Server

Wahrgenommene Ladezeit einer Webseite

80%

20%

Client

Server

WAS PASSIERT IM BROWSER?

Your best friends

• „F12“-Tools

• Firebug

• Yahoo YSlow

• Google PageSpeed

• Speed limiter: Webscarab

• WebPageTest.org

• ShowSlow.com

HTML (Server) Resources (Client)

ANZAHL DER REQUESTS REDUZIEREN HTTP Requests are expensive!

HTTP Requests reduzieren

• Redirects vermeiden

• Dateien sinnvoll kombinieren – base.js, dragndrop.js, upload.js, …

– base.css, dashboard.css, lightbox.css

• Auch Grafiken – CSS Sprites – button.png, button_hover.png,

button_active.png, …

CSS Sprites

.button {

width: 10px; height: 10px;

background-image: url(sprites.png); background-position: 100px 40px;

}

.button:hover {

background-position: 110px 40px;

}

sprites.png

110px

40px

Intelligentes Browser-Caching

• Achtung, ETag!

Server Client

GET File

File

Server Client

GET File, if modified

File 304 not modified

Use HTTPs potential!

Intelligentes Browser-Caching

• Besser: Expires-Header

Server Client

GET File

File

Server Client

File

Expires 01.01.2013 00:00

Supercache: Gemeinsames CDN

• Google CDN – //ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js

• Aber: Single Point Of Failure

– Asynchron laden

– Lokales Fallback

Cache busters

• base-12.js

• styles-67.css

• background-890.png

• 890/background.png

• background.png?890

REQUESTS VERKLEINERN HTTP Requests are expensive!

Compression & Minifying

• alles was geht: HTML, CSS, JS, JSON, XML, …aber keine Bilder, PDFs, SWFs, …

• Komprimieren

– mod_deflate

• Minimieren

– YUICompressor, UglifyJS, ...

Compression & Minifying hdm-stuttgart.de

Original Minified Komprimiert Komprimiert + Minified

HTML 101 KB 97 KB 17 KB 16 KB

CSS 90 KB 68 KB 19 KB 14 KB

JS 243 KB 195 KB 73 KB 63 KB

434 KB 360 KB 109 KB 93 KB

-341 KB ≈ -79%!

Compression & Minifying laut.fm

Compression & Minifying netflix.com

“Adopting a single optimization, gzip compression, resulted in a 13-25% speedup and cut their outbound network traffic by 50%.”

http://www.stevesouders.com/blog/2010/05/07/wpo-web-performance-optimization/

IMAGE OPTIMIZATION

Image Optimization

JPG PNG GIF

• Richtige Abmessungen + „Für Web speichern“

• CSS-Sprites

Farbanzahl

smushit.com

130 x 86 px

hdm-stuttgart.de

smushit.com spiegel.de

smushit.com koeln.de

smushit.com laut.de

smushit.com laut.fm

HDM-STUTTGART.DE

-325 KB -97 KB

-422 KB

Compression & Minifying

Image Optimization

-49%

REIHENFOLGE DER REQUESTS HTTP Requests are expensive!

Order of loading resources

<script> blockiert weitere Downloads <script> blockiert Rendering -> Reihenfolge beachten -> defer/async-Attribute bzw. Loading-Tools nutzen

Order of loading resources

CSS Zwingend

notwendige Scripts Sichtbare Grafiken

Ergänzende Scripts

Pre-/Lazy-Loading

DOM-ready

base.css modernizr.min.js background.jpg button.png

dragndrop.js lightbox.js

onLoad

<head> <body> Dynamisch per JS

PRELOADING

Preloading

• Z.B. Loginseite

LAZY-LOADING

Post-loading

Asynchrone Requests

• Inhalte per AJAX nachladen

• Testen! ;-)

Domain sharding / CDN

• Schnellere Antwortzeiten/Übertragungsraten

– Schlanker Webserver

– Cookie-freie Domain

• Parallele Downloads (für ältere Browser) – nur 2 Requests per Host

s-static.ak.facebook.com

Usability

• Kann die Nutzerführung optimiert werden?

• Kann der Nutzer bereits etwas tun, während er warten muss?

NOCH NICHT SCHNELL GENUG? Advanced WPO

Rendering optimieren

• Progressive Rendering / Early Flushing

• Anzahl der DOM-Element reduzieren

• Reflow optimieren

JavaScript optimieren

• JavaScript Best Practices • DOM-Manipulationen • Memory Leaks fixen

• Verzögertes Parsen / Ausführen

<script>

/*

function weNeedThisLater () {}

var weNeedThisLater2 = 123;

*/

</script>

CSS optimieren

• Selektoren sind unterschiedlich schnell .myStyle { }

ul li .myStyle { }

• CSS braucht Rechenleistung

– border-radius, box-shadow, text-shadow, background-image, …

http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/

Chrome Speed Tracer

Strangeloop Site Optimizer

Fokus auf der vom Nutzer wahrgenommenen Ladezeit. Analysiert Nutzerverhalten und lädt Ressourcen bereits vor.

„IST JA GANZ SCHÖN AUFWÄNDIG…“

Web Performance Optimization

Sehr gute Tools verfügbar

• Yahoo YSlow

• Google PageSpeed

• Dynatrace AJAX Edition

• WebPageTest.org

Vieles lässt sich automatisieren

Integration in den Deployment/Build-Prozess

– JS/CSS-Dateien kombinieren

– Compression & Minifying

– Caching und Cache busters

– Bildoptimierung

– Verteilung auf CDN

Auf dem Server

• On-the-fly

– Mod_deflate

– Mod_pagespeed

– WEBO Site SpeedUp (PHP)

Externe (kommerzielle) Services

• On-the-fly in der Cloud

– blaze.io

– strangeloop.com

– Google Page Speed Service

• Monitoring

– Gomez

HTML 5 + CSS 3 + JavaScript

• CSS 3 – CSS statt Grafiken – Canvas

• HTML 5

– Network Timing API – Web Storage statt Cookies – Web Workers – Web Sockets

• JavaScript!!!

GOOGLE + CHROME SPDY Was Google hat, was wir (noch) nicht haben…

~50% reduction in page load time

Multiplexed streams

Request prioritization

HTTP header compression

Server push & hint

An experimental protocol for a faster web

use

Frontend Performance matters!

Enorme Auswirkungen

Basics sind einfach

Best Practices beachten &

weiter optimieren

Direkte Verbesserung für die Nutzer

don‘t fiddle – analyse first

Entlastet auch die Server

Kosten/Nutzen abwägen

Mobiles Internet

RIA

Weiterführend

• Bücher:

– Steve Souders: High Performance Websites

– Steve Souders: Even Faster Websites

• Test-Webseite: http://stevesouders.com/cuzillion

• http://developer.yahoo.com/performance/

• http://code.google.com/intl/de-DE/speed/

Beispiele aus der Praxis

Dynamische Bildauslieferung

• /image.php?src=image.jpg&width=200

• Standard:

– Kein Client-seitiges Caching

– Evtl. Server-seitiges Caching

– PHP wird ausgeführt

– Evtl. Session + Datenbank-Verbindung

Dynamische Bildauslieferung

• /image/w200/11259834/hdm-stuttgart.jpg

• Optimale Lösung: – Server-seitiges Caching

– Client-seitiges Caching • Cache Header + Expires Header + HTTP 304 Not Modified

• Cache buster + Redirect für alte URLs

– PHP nur wenn wirklich benötigt • Mod_rewrite

Best practices

• Nicht alles muss neu erfunden werden – HTML5 Boilerplate verwenden

• data-URLs

• http://caniuse.com/

• Memory Leaks im Client

• Messen was auf dem Client passiert

Frontend Performance

Jakob Schröter

jakob.schroeter@seitenbau.com