Hacker News Reader

Comment by jacquesm | Hacker News Reader

The biggest impact you can have on your users experience is to trim down the number of connections and the size of your pages. Long after that you can start worrying about round-trip-times to the server.

This blog post is a nice example: 30 requests (ublock origin blocked another 12, with those enabled the time to load increases to a whopping 28 seconds), 2.5M transferred, 7 seconds load time. And all that for 4K payload + some images.

View on HN

Number of connections isn't that relevant with HTTP2

Yes it is.

The number of connections to one host isn't relevant in HTTP2. As ublock is blocking some ~20 connections these are going to different hosts. Connecting to a different host in HTTP2 is no different then HTTP1.1

If your HTTP2 is terminating at MANY boxes within your infrastructure you are failing to understand how HTTP2 works. Connections within a single TLS/TCP/IP connection are free, new TLS/TCP/IP connections cost exactly as much as before.

Come to think of it, it's pretty ironic. For years, admins have been told to move static content to a different domain to trim down the request size (since browsers won't include the cookies for the main site). Now that might reverse, and it might be best to send all HTTP requests to the same server (for large sites: most likely some load balancer or haproxy or whatever) in order to benefit from HTTP/2 multiplexing.

HTTP/2 really seems more like a front end balancing and caching protocol.

Handle your TLS/HTTP2 termination on the same boxes and use HTTP1.1 within the internal network.

Unfortunately back here in the real world only about 10% or so of all websites support HTTP/2 so it is very relevant.

Given this article is about how you can improve _your_ response times, I think the author and audience probably have the the ability to implement HTTP2.

That can be fixed just as easily as reducing the number of requests.

Adding http2 is easier then reducing the number of requests.

And infact reducing the number of requests using things like spritemaps, bundling js and css is actually an antipattern with http2.

> And infact reducing the number of requests using things like spritemaps, bundling js and css is actually an antipattern with http2.

Those are just ways to lose some of the impact of bloat without addressing the bloat itself.

If you address bloat directly it will benefit all users.

If you shard on http2 it will take longer since now it makes multiple ssl connections which have have the ssl handshake.

With http2 it's all multiplexed into one connection. So you have the one ssl connection, but that one connection has multiplexed connections inside it. And since it's one tcp, the tcp sliding window has opened up and is actually faster then opening a new tcp connection.

If you migrate to HTTP2 or move to a host that already supports it then cutting down on "round trips" is an obsolete concern altogether.

HTTP2 does not magically bundle all connections to one. It still very much depends on how you build up your page.

It does not magically split one connections into many. One domain == one connection. Sure it won't undo your "domain sharding" hacks and merge your CDNs, yeah :)

yeah, but we're talking about what website operators can do to speed up their site. you can try to dramatically reduce the number of files you need to send. OR, you can just enable HTTP2. HTTP2 seems like a more simple answer.

HTTP2 doesn't magically change the number of hosts you communicate with (CDNs, ad networks, tracking providers, etc) and most importantly, it doesn't reduce the amount of shit developers are piling onto web pages.

Reply on news.ycombinator.com