5 ms·

This guide is a comprehensive explanation of Chrome's Network timeline, but the optimisation recommendations are quite skewed towards the front-end. There's a m

This guide is a comprehensive explanation of Chrome's Network timeline, but the optimisation recommendations are quite skewed towards the front-end. There's a missing piece on server configuration, no mention of CDNs or asset/domain sharding for connection concurrency, server-side or client-side caching. It also doesn't take into account HTTP/1 vs. SPDY & HTTP/2. For example, loading JavaScript modules as individual files can improve performance for SPDY & HTTP/2, because changes in individual files don't expire the entire concatenated bundle. Here's a slide deck called "Yesterday's best practices are HTTP/2 anti-patterns", that re-examines some of Nate's advice: https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.p19 https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdD...

schneems 11y ago
Check his previous posts, he does lots of work on backend speed. If you put all that advice into one post, it would be pretty overwhelming.
- some1else 11y ago
  For anyone that's interested, here's a guide on scaling Ruby servers to 1000RPM, written by the same author: http://www.nateberkopec.com/2015/07/29/scaling-ruby-apps-to-1000-rpm.html http://www.nateberkopec.com/2015/07/29/scaling-ruby-apps-to-....
  - praseodym 11y ago
    Is it me or is 1000 requests per minute a laughable goal? That's 16.6 requests per second, i.e. 60ms per request _without any parallisation_. I'd expect any unoptimised app to be able to reach that goal.
    - aevv 11y ago
      Maybe if you read the first paragraph you'd find out
    - MichaelGG 11y ago
      Article is actually quite good, but it seems Rails is really slow. Twitter 2007 is said to be at 300ms/req. Others come in around 100ms. So it would seem that you don't get 16RPS without some effort.
nateberkopec 11y ago
I wanted a guide that focused on the one thing all web developers have in common - the page construction process in the browser. We all use different servers, languages, etc. HTTP2 will absolutely change a lot of how this works, you're right. I chose not to cover it as it won't be a real option for most developers until nginx supports it (still in alpha). The skills I'm teaching in the article re: the Timeline can still be applied when HTTP2 gains mass adoption, so you can test for yourself whether or not the recommendations in the article still make sense.
- some1else 11y ago
  Okay. I'm pointing these out because it says Full-stack in the title. Nginx servers can run SPDY until HTTP/2 is stable, or use an HTTP/2 capable proxy.
  - d0ugie 11y ago
    For those interested, the unstable (alpha) HTTP/2 element of NGINX is this patch for the 1.9.x mainline versions: http://nginx.org/patches/http2/README.txt http://nginx.org/patches/http2/README.txt
putlake 11y ago
HTTP2 only works for HTTPS sites. For a myriad of reasons, that is not practical for a lot of websites. HTTP 1 best practices are going to be needed for a long time.
- nateberkopec 11y ago
  I believe the encryption requirement was dropped at the last minute. HTTP2 will serve unencrypted connections.
  - MichaelGG 11y ago
    Browsers aren't supporting that part though, so HTTP2 for the web is only encrypted.
mandeepj 11y ago
Then you have to design your bundles in such a way that it contains the least changing files (like external files like jquery, underscorejs etc). The files that are changing frequently can kept together in a separate bundle like your internal app files.

schneems 11y ago

Check his previous posts, he does lots of work on backend speed. If you put all that advice into one post, it would be pretty overwhelming.

some1else 11y ago
For anyone that's interested, here's a guide on scaling Ruby servers to 1000RPM, written by the same author: http://www.nateberkopec.com/2015/07/29/scaling-ruby-apps-to-1000-rpm.html http://www.nateberkopec.com/2015/07/29/scaling-ruby-apps-to-....
- praseodym 11y ago
  Is it me or is 1000 requests per minute a laughable goal? That's 16.6 requests per second, i.e. 60ms per request _without any parallisation_. I'd expect any unoptimised app to be able to reach that goal.
  - aevv 11y ago
    Maybe if you read the first paragraph you'd find out
  - MichaelGG 11y ago
    Article is actually quite good, but it seems Rails is really slow. Twitter 2007 is said to be at 300ms/req. Others come in around 100ms. So it would seem that you don't get 16RPS without some effort.

nateberkopec 11y ago

I wanted a guide that focused on the one thing all web developers have in common - the page construction process in the browser. We all use different servers, languages, etc. HTTP2 will absolutely change a lot of how this works, you're right. I chose not to cover it as it won't be a real option for most developers until nginx supports it (still in alpha). The skills I'm teaching in the article re: the Timeline can still be applied when HTTP2 gains mass adoption, so you can test for yourself whether or not the recommendations in the article still make sense.

some1else 11y ago
Okay. I'm pointing these out because it says Full-stack in the title. Nginx servers can run SPDY until HTTP/2 is stable, or use an HTTP/2 capable proxy.
- d0ugie 11y ago
  For those interested, the unstable (alpha) HTTP/2 element of NGINX is this patch for the 1.9.x mainline versions: http://nginx.org/patches/http2/README.txt http://nginx.org/patches/http2/README.txt

putlake 11y ago

HTTP2 only works for HTTPS sites. For a myriad of reasons, that is not practical for a lot of websites. HTTP 1 best practices are going to be needed for a long time.

nateberkopec 11y ago
I believe the encryption requirement was dropped at the last minute. HTTP2 will serve unencrypted connections.
- MichaelGG 11y ago
  Browsers aren't supporting that part though, so HTTP2 for the web is only encrypted.

mandeepj 11y ago

Then you have to design your bundles in such a way that it contains the least changing files (like external files like jquery, underscorejs etc). The files that are changing frequently can kept together in a separate bundle like your internal app files.