Christian Riesen
Fullstack Web Developer at Liip. Creator of rokka.io. Focus on API's, image handling and large scale applications.
Or, what everyone needs
to make performance web sites and applications
Lot's of low level stuff ahead
You don't need to know all the details
Make better "everythings"
Much comes from this freely online readable book: High-Performance Browser Networking by Ilya Grigorik
1. Well structured and relevant content
2. Speed
3. More stuff
We ignore speed as a feature mostly
The unsurprising attitude is a little like this...
Amazon says for every 100 ms improvement in latency, their revenue goes up 1%
2,000 ms delay on Bing search pages decreased per-user revenue by 4.3%
An Aberdeen study of over 160 organizations concluded, a one second delay has the following effects:
7% loss in conversions
11% fewer page views
16% decrease in customer satisfaction
0 - 100 milliseconds feels instant
100 - 300 milliseconds small perceptible delay
300 - 1'000 milliseconds it just works
1'000 - 10'000 milliseconds mental context switch
above 10'000 milliseconds users quit
Customer satisfaction
Page views
Conversions
Revisits
Money
Global average: 3.1 Mbps (+17%)
South Korea: 14.2 Mbps
Switzerland: 10.1 Mbps (+24%)
USA: 8.6 Mbps (+27%)
Average bandwidth speeds as seen by Akamai servers in Q1 2013
Speed of light
TCP
SSL (TLS)
Mobile networks
Old webservers
Old libraries
Old kernels
Too many requests
New York to London: 5'580 km
Time for light in vacuum: 19 ms
Time for light in fiber: 28 ms
Rount trip time (RTT): 56 ms
Light, once around the equator:
In vacuum: 133.7 ms
In fiber: 200ms
Refractor of ~1.5
Potential of improvement only ~33%
Ain't gonna happen soon either
You can't do anything about it
NY -> London RTT 56 ms
Open TCP connection: 56 ms
No data sent yet!
Congestion window about 1.5 KB
Start with 4 windows
Connection (56 ms)
6 KB for first round trip (112 ms)
Doubles after success
12 KB for second round trip (168 ms)
24 KB for third round trip (223 ms)
42 KB in 223 ms!
300 milliseconds round trip are the norm
More on bad connections
Bad connections can be crowded places
The problem is:
People expect mobile sites to be as fast or faster!
Congestion window about 1.5 KB
Start with 4 windows
Connection (300 ms)
6 KB for first round trip (600 ms)
Doubles after success
12 KB for second round trip (900 ms)
24 KB for third round trip (1'200 ms)
42 KB in 1'200 ms!
Over 5x compared to non-mobile
Mobile can be faster (under ideal conditions)
HDSPA can be around 100 ms
The new 5G is supposed to be sub 50 ms
You can do things about this
Modern systems use 10 instead of 4
Keep connections open (Keep-Alive)
Don't let it restart with slow-start on idle connections
Window scaling, make it bigger
TCP Fast open, data before initial roundtrip is over
Lower latency! Close the gap between user and data
SSL != TLS but close enough
TCP connection + 3 more roundtrips (or more)
Mobile: 1'200 ms before even data flows
Configuration can bring that down to 2 extra trips
New servers and clients can bring it to 1 extra
HTTP 1.1 way
Bundle up CSS files into one big one
Bundle up JS files
Image sprites
Load in header only CSS
Load JS in footer (non blocking)
Print CSS is non blocking, put it in its own file
Use multiple hosts to spread files and connections
Want more?
"Above the fold" inline
Base styles inline
Rest loaded async after page loaded
And you can even use local storage as cache!
One connection can load items in parallel
No need to splice files together
Hybrids might still be faster
Look up SPDY for the current implementation of HTTP 2.0
Modern servers and browsers already speak HTTP 2.0
Radio Resource Controller
Controls your phone!
Strength of signal
Channel
Battery consumption
Full on, drains power a lot
Almost as much as screen
Timeout for lower power mode on LTE
Second timeout for Idle mode
Older standards just go idle
Pre LTE: 300 - 5000 ms
LTE: < 100 ms
LTE-Advanced: < 50 ms
Market share LTE: below 10% (Europe 2013)
Idle timeout varies from network, to mobile to everything
You can't predict idle
A good average is in the 20 - 30 seconds range
Use case Pandora, measured by AT&T
Downloads song in seconds when it changes
Player sends data every 60 seconds for tracking
Turns on the radio to full every 60 seconds
Then idles out, eating battery
Full reconnection happens all the time, no keep alive
Bundle requests
Use push, not poll
Burst transmissions (download song)
Unfortunately, no API to tell the device you are done
Numbers are averages (apples to apples), can be a bit lower
Server side response is assumed as 0 milliseconds
No routing, firewalls, load balancers mentioned
The assumption is you are fiber wired into the server
That's of course wrong, but not the subject here
Send less bytes
Get the bytes closer to the client
Use less connections
Reduce latency
The First Rule of Program Optimization:
Don't do it.
The Second Rule of Program Optimization (for experts only!):Don't do it yet.
Michael Anthony Jackson
Christian Riesen
By Christian Riesen
How to make performance websites and applications.
Fullstack Web Developer at Liip. Creator of rokka.io. Focus on API's, image handling and large scale applications.