Hacker News Reader

Comment by some1else | Hacker News Reader

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/1r7QXGYOLCh4fcUq0jDdD...

View on HN

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.

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.

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

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.

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

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.

Maybe if you read the first paragraph you'd find out

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.

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.

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.

I believe the encryption requirement was dropped at the last minute. HTTP2 will serve unencrypted connections.

Browsers aren't supporting that part though, so HTTP2 for the web is only encrypted.

Reply on news.ycombinator.com