Real-world HTTP/2: 400GB of images per day • Hacker News Board

Re: Real-world HTTP/2: 400GB of images per day

#21

Post by MichaelGG » Fri, Jul 15, 2016, 2:50 AM UTC

joobus wrote: post #16

One way to "solve" the time to visual completion would be to make all the images, but especially the larger images, progressive scan. For very large images, the difference in visual quality between 50% downloaded and 100% downloaded on most devices isn't noticeable, so the page would appear complete in half the time.

If there's a way to tell it not to render until x% downloaded, sure. Otherwise slower connections see the low-q versions for a while and it can disconcerting. Either to some users or some PMs.

Re: Real-world HTTP/2: 400GB of images per day

#22

Post by rgbrenner » Fri, Jul 15, 2016, 2:55 AM UTC

Founder of NuevoCloud here. If I read this right, you guys used Cloudflare for http 2. So let me ask you this, when you did your comparison, were all of the images cached (ie: x-cache: hit) at the edge?

The reason I ask is because cloudflare, last I checked, still hasn't implemented http2's client portion. So when a file is not cached, it does this:

client edge node origin server.

Http2 is only used for the short hop between the client and edge node.. then the edge node uses http 1.1 for the connection to the origin server, which may be thousands of miles away.

In other words, in your test, depending on the client location and the origin server location.. your test may have used http 1.1 for the majority of the distance.

If you guys want to rerun this test on our network, we use http2 everywhere... your test would look like this on our network:

client edge node (closest to client) edge node (closest to server) origin server.

So even if your origin server doesn't support http2, it'll only use http 1.1 over the short hop between your server and the closest edge node.

You're welcome to email me if you want to discuss details you don't want to post here.

Edit: I should also mention, that we use multiple http 2 connections between our edge nodes and between the edgenode and origin server... removing that bottleneck. So only the client edge node is a single http 2 connection.

Re: Real-world HTTP/2: 400GB of images per day

#23

Post by xzyfer » Fri, Jul 15, 2016, 2:56 AM UTC

diegorbaquero wrote: post #20

Excellent and in-depth article. Thank you for sharing! Hopefully we'll see a follow up with future changes and tweaks both from webservers and browsers.

Thanks mate, glad you enjoyed it.

Re: Real-world HTTP/2: 400GB of images per day

#24

Post by pedalpete » Fri, Jul 15, 2016, 3:09 AM UTC

We've recently moved to Google Cloud Storage from AWS because of http/2. We had a bottleneck of the browser waiting when serving multiple large (8+files * 10mb+each).

I'm wondering if 99designs looked at any sort of domain sharding to get around the timing issues. If I understand correctly, wouldn't this get around the priority queue issue? Your js,fonts, etc. coming from a different address than your larger images, would create completely separate connections.

I'm not completely sure this would get around the issues mentioned, but I'm curious if it was looked at as a solution.

Re: Real-world HTTP/2: 400GB of images per day

#25

Post by taf2 » Fri, Jul 15, 2016, 3:26 AM UTC

hendry wrote: post #15

mkj wrote: post #5

This seems to bode badly for CDNs versus own tuned servers, unless there's a way for origin websites to provide hints on response ordering?

damn, CloudFront already doesn't expose many tunables, so yeah, this isn't going to work. Starting to wish Appcache manifest actually was made to work and that could use used as a queue somehow to prioritise important assets on a Webpage.

ServiceWorkers are the app cache done right. https://github.com/w3c-webmob/ServiceWorkersDemos

Re: Real-world HTTP/2: 400GB of images per day

#26

Post by b34r » Fri, Jul 15, 2016, 3:26 AM UTC

joobus wrote: post #16

One way to "solve" the time to visual completion would be to make all the images, but especially the larger images, progressive scan. For very large images, the difference in visual quality between 50% downloaded and 100% downloaded on most devices isn't noticeable, so the page would appear complete in half the time.

Doesn't that increase the file size though? They're looking at 3G load speeds, so any increase in file size is probably unwelcome.

Re: Real-world HTTP/2: 400GB of images per day

#27

Post by xzyfer » Fri, Jul 15, 2016, 3:28 AM UTC

rgbrenner wrote: post #22

Founder of NuevoCloud here. If I read this right, you guys used Cloudflare for http 2. So let me ask you this, when you did your comparison, were all of the images cached (ie: x-cache: hit) at the edge? The reason I ask is because cloudflare, last I checked, still hasn't implemented http2's client portion. So when a file is not cached, it does this: client edge node origin server. Http2 is only used for the short hop…

To the best of my knowledge you are correct about how CloudFlare works. For context this data was collected over the period about a month on real production pages with significant traffic.

The edges were well and truely primed.

Re: Real-world HTTP/2: 400GB of images per day

#28

Post by hendry » Fri, Jul 15, 2016, 3:29 AM UTC

taf2 wrote: post #25

hendry wrote: post #15

Earlier quoted context omitted.

damn, CloudFront already doesn't expose many tunables, so yeah, this isn't going to work. Starting to wish Appcache manifest actually was made to work and that could use used as a queue somehow to prioritise important assets on a Webpage.

ServiceWorkers are the app cache done right. https://github.com/w3c-webmob/ServiceWorkersDemos

My point is that you can't map Service Workers onto a simple manifest, i.e. a list of resources the httpd needs to push as a priority.

You "kindof" can with a Appcache "manifest". Stretch of the imagination, I know.

Re: Real-world HTTP/2: 400GB of images per day

#29

Post by xzyfer » Fri, Jul 15, 2016, 3:31 AM UTC

MichaelGG wrote: post #21

joobus wrote: post #16

One way to "solve" the time to visual completion would be to make all the images, but especially the larger images, progressive scan. For very large images, the difference in visual quality between 50% downloaded and 100% downloaded on most devices isn't noticeable, so the page would appear complete in half the time.

If there's a way to tell it not to render until x% downloaded, sure. Otherwise slower connections see the low-q versions for a while and it can disconcerting. Either to some users or some PMs.

This is correct. Visually completion will not be achieved until the entirety of the images within the viewport are downloaded.

However progressive jpegs could improve initial paint times. These are dynamic so each page would have it's own unique (although related) profile.

Re: Real-world HTTP/2: 400GB of images per day

#30

Post by cagenut » Fri, Jul 15, 2016, 3:35 AM UTC

Did I read this right that http1 was with cdn A (unnamed?) and http2 was with cdn B (cloudflare)?

If so, you really can't draw any conclusions about the protocol difference when the pop locations, network designs, hardware and software configurations could easily have made the kinds of differences you're seeing.