What every web developer needs to know

Or, what everyone needs

to make performance web sites and applications

Don't Panic

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

Features People Want

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

Why you should care

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

Time Limits

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

Speed matters

Customer satisfaction

Page views

Conversions

Revisits

Money

Where is the problem?

Modern webpages are not so simple anymore
Taken from Archive.org
Comparing January 1st 2013 to May 15th 2014
Total transfer size: 1284 kB - 1762 kB
Total requests: 88 - 95
From total, fonts only: 14 kB - 59 kB
From total JavaScript only: 207 kB - 282 kB
JS requests: 15 - 18
On the bright side, Flash goes out of style

Tendency: Upwards

Bandwidth is not the problem

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


Download times for 1762 kB:
At 3.1 Mbps 4'547 ms
At 10.1 Mbps 1'395 ms

Your Enemy is Latency

Speed of light

TCP

SSL (TLS)

Mobile networks

Old webservers

Old libraries

Old kernels

Too many requests

Latency

IP (Internet Protocol)
TCP (Transmission Control Protocol)

Latency is the time between a client making a request to a server and the response from the server returning to the client

Ping anyone?

RTT (Round Trip Time)

Potential improvements

The battle for milliseconds

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

The Fiber potential

Refractor of ~1.5

Potential of improvement only ~33%

Ain't gonna happen soon either

You can't do anything about it


TCP connection

NY -> London RTT 56 ms

Open TCP connection: 56 ms

No data sent yet!

Slow start

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!

The Mobile dilemma

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!

Slow start mobile

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 disclaimer

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 control the windows

You can do things about this

Modern systems use 10 instead of 4

More TCP Performance

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

Welcome to TLS Hell

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

Too many requests

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?

Inline it

Inline css, images, javascript
+ Less connections
- More bits
- Less cacheable on client side

Inline Hybrid

"Above the fold" inline

Base styles inline

Rest loaded async after page loaded

And you can even use local storage as cache!

In HTTP 2.0, forget everything

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

Mobile and RRC

Radio Resource Controller

Controls your phone!

Strength of signal

Channel

Battery consumption

Battery power on mobile

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

From Idle to data

Pre LTE: 300 - 5000 ms

LTE: < 100 ms

LTE-Advanced: < 50 ms

Market share LTE: below 10% (Europe 2013)

Going idle

Idle timeout varies from network, to mobile to everything

You can't predict idle

A good average is in the 20 - 30 seconds range

0.2% of bits use 46% of battery

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

How to not kill your battery

Bundle requests

Use push, not poll

Burst transmissions (download song)

Unfortunately, no API to tell the device you are done

You might notice

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

TL;DR

Send less bytes

Get the bytes closer to the client

Use less connections

Reduce latency

Optimization

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


Measure first! Optimize. Measure again. Repeat.

Thanks for listening



Christian Riesen

http://christianriesen.com

Checklist

  • Congestion windows at 10 or more
  • Window size larger (if need be)
  • New kernel
  • Reuse connections (keep alive)
  • Disable slow-start reset on idle connection
  • Fast open TCP connection (data on first trip)
  • Configure TLS to use less connections
  • Don't kill the mobile battery
  • Bundle files (and compress them) for HTTP 1.1
  • Use inline where it makes sense (Hybrid, above fold)

What every web developer needs to know

By Christian Riesen

What every web developer needs to know

How to make performance websites and applications.

  • 1,845