content-to-phone-in-1000ms

View Github Repository Open presentation in a new window

iamcarrico

See all presentation from iamcarrico

content-to-phone-in-1000ms

0 1

content-to-phone-in-1000ms

A practical approach to getting content to a phone in less than 1000ms

On Github iamcarrico / content-to-phone-in-1000ms

Getting Content to a Phone in less than 1000ms

We must get the content to the user, and we must do it fast. In a world constantly moving, getting a site loaded in under 1000ms is key to keeping users on your site, and engaged with your content. This is not a new idea, and the 1000ms barrier has been written about, presented, talked about in web circles for a while now--- but how do we actually do it? Working on a Drupal site, how can we decrease bloat on a page, to get our site delivered to the user quickly and efficiently. What steps can we take to decrease that first hit, so a page is available as soon as possible, especially for a mobile user. This talk will go over the tech, and the basics of the TCP protocol so you understand where the lag is in presenting a web page. It will describe the modules any frontend developer can use to help in presenting their content, and frontend techniques that can be applied by advanced themes to make your site the fastest on the net.

Ian Carrico

Web Performance Artist, Vox Media

What is this about?

  • What effects frontend performance
  • Guidelines to better page load
  • How the protocols we utilize (HTTP, TCP, SPDY) effect our sites

Slides

Why?

  • Bounce rates increase
  • Mental context switching happens after 1 second
  • Many countries are mostly mobile devices
  • We cannot rely on 4G to fix the problem for us
Google, Amazon, Bing and others have all done user tests on the effects of page load time on the user's experience, conversions and bounce rates. Not only do bounce rates increase after 1000ms (immensely), but the user's mental context switches after a second. This means they will start wondering if they left the oven on more than you're site's content. We especially need think about mobile devices because more and more users across the globe are using their mobile devices to access the web. Finally, we cannot rely on faster mobile speeds to solve the problem for us, because besides things like LTE not being rolled out everywhere in the globe, speed alone will not make our sites load faster.

Rule 1

They be more like guidelines.

There are very few hard and fast rules of web performance, and your specific sites needs and code will always be slightly different. The important thing is to always be trying new ways at getting a faster site, and always be be looking for places of improvement.

Test Everything

Every site is different, every app has different requirements. It is important as we improve our own site's performance that we measure a baseline, and test everything as we go along.

Tools

  • Web Page Test
  • YSlow
  • PageSpeed
  • Chrome's Dev Tools
  • Casper.js
We can't do anything without properly testing it. Be sure to grab a benchmark of how your site is currently performing, and then start making adjustments.

Test to Your Users

  • Your users are not you
  • Test under the conditions that your users access the site.
Every set of users are unique, and they have different needs. Some sites user base all use Google Chrome Canary, and that site can always use the latest and greatest techniques for web performance. Other sites primarily have users that use IE 8, and must have a very different set of tools to ensure their performance is excellent. Before we go deep into what we can do, take a look at the needs of your particular users, and test under those conditions.

Automated Frontend Testing

Chris Ruppel gave a great presentation on this at DrupalCon. Watch it.

https://amsterdam2014.drupal.org/session/automated-frontend-testing

Render blocking resources

Getting content to the user should be the first priority. We want to reduce the number of render blocking requests in the head of the document to the footer. We should try and get the critical CSS in the head, and load the rest asychronously.
Anything we have on the page that will prevent the site from loading is considered "render blocking". This includes JavaScript in the , stylesheets, etc. They will require the browser to download the resource before rendering the rest of the page.
This is taken directly from @igrigorik's presentation. Display of the page is blocked on the DOM, and the CSSOM loading. Those two (along with JS) come together to build the render tree. You'll note that both of these are reliant on the network, which we will get to next.

JavaScript

Move JavaScript to the footer Utilize async / defer Inline critical JS

Use the Magic Module

JavaScript in the header will block the rendering of the page. To prevent this, we can move most of our JavaScript to the footer, or load it asynchronously. Within Drupal, the easiest way to do this is my enabling the Magic module.

CSS

Inline critical CSS (the fold is back!) Load the rest of CSS asynconously (LoadCSS)

There is no "out of the box" Drupal solution for this (Yet!)

Unlike HTML, that can be parsed as it comes down, the CSSOM needs to be parsed as one. Luckily, browsers are REALLY good at doing this. But, we need to get an entire CSSOM to the browser quickly, and this will mean inlining the critical CSS.

TCP

TCP is the backbone of communication for http. It provides many methods to ensure the website arrives to our user, but is also comes with its own limitations. HTTP 1.1 doesn't always utilize TCP the best, which is why we have some tricks we use currently.

Odyssey, this is Houston, do you read?

It's not speed...

It's latency

It would make sense that if we can just increase people's speed of connection, then our sites will load faster. The fact is though, lowering latency will effect the page load time much more than speed will. The graph on the left shows the page load time decreasing as we increase speed of the connection, but it hits a point of diminishing returns. The right graph shows the page load time as we decrease latency (RTT = Round Trip Time), where we have a specific linear connection. (Graph courtesy of Ilya Grigorik) (Large Graph from http://chimera.labs.oreilly.com/books/1230000000545/ch10.html#BROWSER_OPTIMIZATION)

A Roundtrip

 
DNS Lookup
TCP Connection
TLS Handshake
HTTP Request
Total
Google Fiber
40ms
60ms
60-120ms
60ms
220-280ms
LTE
100ms
100ms
100-200ms
100ms
400-500ms
3G
200ms
200ms
200-400ms
200ms
800-1000ms
What happens we we request a URL in our browser that we have not been to before? The browser will do a DNS lookup, then create a TCP connection, then (maybe) a TLS handshake for SSL, then we can finally make our first HTTP request. For fiber connections, that isn't so bad, but what about LTE or 3G connections. We quickly deplete our 1000ms budget to almost nothing.

CDNs

  • We are limited by the speed of light
  • Put your content closer to the user.
This shouldn't be surprising, but the best way to fight latency is just to have a CDN. Get content as close to the user as possible, so each round trip is not as far.

Reduce redirects

REMOVE Redirects

Every redirect you do adds on extra (unneeded) round trip. This includes redirecting one domain to another, or even redirecting from http to https. There are many ways of removing redirects. Sharing direct links to content. If you are using https only, you can add the 'strict-transport-security' headers to your site, so that all subsequent loads always use https. There is also the ability of adding your site to Google/Mozillas HSTS list.

First Packet Response

A server will respond with 4 packets (RFC 2581) or 10 packets (RFC 6928), depending on your server's config. If you are using 10 packets (and you should), then that means the first packet response will be 14.6kb. If you can deliver the full render tree in a single response in that time, then you're site will load after the completion of a single HTTP resquest.

HTTP 1.1 Tricks

  • Domain sharding
  • Concatenation
  • Spriting
  • Inlining of assets

The fastest request you will ever make, is the one you don't.

Most modern browsers will open ~6 tcp connections per domain to download more assets. Thus enters domain sharding, where we create separate subdomains for a set of 6 assets, thus being able to load them. We can also concatenate assets to have fewer requests. This is great, except for when assets change often, which will cause large re-downloads for minor changes. Spriting images also allows for less requests to be made. Finally, inlining of assets removes entire requests.

Prepare for HTTP/2

The Artist formerly known as SPDY

HTTP/2 is already here, and there are extensions for both Apache and nginx to start using it today. It comes with many improvements to http, utilizing more of what makes TCP so great. But it will be some time before it becomes the defacto protocol.
HTTP/2 will help make the net faster. Much like the Mach Five, it has a bunch of little features to get sites to the user in unprecidented times. It's main goal is to fight the issue of latency that HTTP 1.1 has, and utilize TCP much more efficiently.

What is it?

  • Multiplexed streams
  • Request prioritization
  • Server push
  • Removal of redundant headers
  • Compressed headers
HTTP/2 has a lot of optimizations and performance benefits. It has been setup to allow a drop in solution for apache and nginx. The biggest benefit HTTP/2 gives off the back is the use of multiplexed streams, allowing for multiples files to use a single TCP connection. This removes the need for multiple TCP handshakes, each of which could cost 100's of milliseconds. With that also comes the need to prioritize requests, which the client can prioritize high-importance items over others. The server can also push resources to the client, instead of the client needing to make individual requests for everything. Finally, they will remove redundant headers, and compress any that are needed.

Tricks 2.0

  • Do not use domain sharding
  • Concatenation can hurt performance
  • Utilize Server.push for important assets

HTTP/2 module is in research
Many of the tricks we used in HTTP 1.1 can cause issues for HTTP/2, mainly domain sharding and concatination. The former will open more tcp connections are are not needed for HTTP/2, the later will mean entire assets are reloaded when small changes are made to any piece. Finally, where possible, push assets to the user instead of requiring the client to request them.

A Casestudy

https://iamcarrico.com

iamcarrico.com

  • Utilizes SPDY
  • Has a custom CDN
    • Moved DNS to AWS Route 53
  • Inlines critical CSS on first page load
  • Loads rest of CSS asynchronously
My personal blog I did some fun testing with to find how I can make it as fast as possible. It uses SPDY (nginx -> varnish -> nginx) for all connections. Since I had custom edge side includes code, I had to create my own CDN (NYC, Amsterdam, Singapore). On first page load, the CSS will be inlined, while following page loads will utilize the browser cache.

Results

  • PageSpeed: 98
  • YSlow: 98
  • Pingdom: 93 w/ sub 500ms load time
  • Web page test: 400-800ms load time (Usually As)
Some basic metrics put my site as incredibly fast (but please don't all go overload my servers!). YSlow and PageSpeed are both 98, and my two points I am missing are mostly out of my control. Doing some tests from Pingdom show that for the most part, content gets to the user under 500ms every time. Web page test puts my DOMContentLoaded at sub 500ms consistently, and the second page view is sub 250ms. I do get into trouble when users are very far away from one of my servers, or if DNS lookup takes too long. Even with those, I will still get consistantly under 1000ms for first page load. http://tools.pingdom.com/fpt/#!/dhgR27/https://iamcarrico.com http://tools.pingdom.com/fpt/#!/ca634J/https://iamcarrico.com http://www.webpagetest.org/result/140930_T3_HMM/ http://www.webpagetest.org/result/140930_HW_HMR/

What's next

  • Never
  • Stop
  • Improving
There will always be new things to try, and new ways of improving performance. I will be continually trying to make the site even faster, more performant, and utilize the next techniques to make it just a little faster.

Questions?

Go Read Ilya Grigorik's Book

Slides

Thank you

Y'all are the best. Really. Rock on. \m/