Web Performance Optimization

Jakob Schröter

http://www.jakob-schroeter.de/ http://www.seitenbau.com/

Developer Convention 2011

PERFORMANCE

WEB 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

• Search Engine Optimization ist ein Thema von gestern Steve Souders

• 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

Aber: 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.com

• ShowSlow.com

HTML (Server) Ressources (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.2012 00:00

Supercache: Gemeinsames CDN

• Google CDN – //ajax.googleapis.com/ajax/libs/jquery/1.6.4/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 ressources

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

Order of loading ressources

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

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

NOCH NICHT SCHNELL GENUG? Advanced WPO

Advanced WPO

• Rendering optimieren

– Progressive Rendering / Early Flushing

– Anzahl der DOM-Element reduzieren

– Reflow optimieren

• JS & CSS Optimizations

– …

Chrome Speed Tracer

Strangeloop Site Optimizer

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

http://www.strangeloopnetworks.com/

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

Web Performance Optimization

Sehr gute Tools verfügbar

• Yahoo YSlow

• Google PageSpeed

• Dynatrace AJAX Edition

• WebPageTest.com

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

– strangeloopnetworks.com

– Google Page Speed Service

• Monitoring

– Gomez

GOOGLE + CHROME SPDY Was Google hat, was wir 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

Performance matters!

Enorme Auswirkungen Basics sind einfach

Von Anfang an Best Practices beachten

& ggf. 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/

Web Performance Optimization

Jakob Schröter

http://www.jakob-schroeter.de/ http://www.seitenbau.com/

Developer Convention 2011