[d0ugie]

Amazing how many e-commerce sites there are out there with time to first byte in excess of 3s, DOM loads over five seconds, as if they have no idea they are throwing away sales and killing their SERP ranks. And the fixes quite often don't require money or that much skill, just a little help from something like Varnish in many cases.

Is the only good way for me to use QUIC with NGINX (or any server that can deliver most of what NGINX does) to use GoQuic and quick-reverse-proxy from github? I realize that, I assume due to the protocol being quite different and using UDP, that it may require a lot of from-scratch retooling by the NGINX devs to light it up (otherwise we'd have had it from them long ago, I imagine), but we need to cut down on round trips baby. Would be nice if Google were to give https://cs.chromium.org/chromium/src/net/tools/quic/ an update with a happy .deb to get it running. Kind of a funny page for google not to serve with quic, guess they like a little irony.

Further parenthetically, I am all in favor of Google making the web better both with things like protocol development, pagespeed, image and video things, and also with search signals that give sites with https and speed a ranking boost. Money talks.

[matahwoosh]

Also, a note on QUIC. Seems like the spec is a draft and is not going anywhere right now, but Google has made big progress with TCP BBR control-flow algo, and there's also TCP Fast Open and TLS 1.3 0-RTT to look forward to.

Moving more delivery (not just static content) to edges + using HTTP/2+Push should help a lot with perf, too.

[matahwoosh]

There's definitely some truth to how (at least some of) e-commerce sites could be easily sped up. Part of the problem is that you have a combination of legacy stack, organizational inertia, lack of know-how and resource outsourcing (so 3rd party vendors owns parts of the stack).

And specifically, wrt caching and varnish, as soon as you put something in your cart and you're cookie'd pages you visit are not cacheable.