xzyfer

It's hard to say for sure. Server implementations can vary wildly, make sure to test any implementation closely. I know from talking to CloudFlare that their implementation respects browser hints. Their implementation is also open source.

I'm out y'all. Thanks for all the support. Feel free to follow up on Twitter at @xzyfer

The priority queue isn't the issue. In fact the priority queue is what kept our first paint times tanking because browsers prioritised render blocking resources instead of images.

The issue was due to the variance of image size. An image that is significantly larger than the page average will be loaded slower since all images get an equal share of bandwidth (priority).

We could further improve first paint times by pushing render blocking resources but we'd need to be serving those resources off the 99designs domain (with current push implementations). This opens us up to a class security issues we avoid by having an asset domain i.e. types of reflected XSS and serving cookies on assets.

For now we'll wait for the webperf working group to address the limitations with server push semantics.

The priority queue isn't the issue. In fact the priority queue is what kept our first paint times tanking because browsers prioritised render blocking resources instead of images.

The issue was due to the variance of image size. An image that is significantly larger than the page average will be loaded slower since all images get an equal share of bandwidth (priority). Adding sharding wouldn't help since the client only has a fixed amount of bandwidth to share and all images would still get the same share of it. Sharding could help if the bandwidth bottle neck was at the CDN but that's rarely going to be the case.

Browser do currently do this. H2 has two types of prioritisations: weighted, and dependency.

All browsers implement weighted resource prioritisation and weigh resources by content type. This is a hold over from what they do for HTTP/1 connections.

Firefox has dependency resources prioritisation. https://bitsup.blogspot.com.au/2015/01/http2-dependency-prio...

The spec purposely leave how these heuristics should work to the implementor. Things will change and implementations will diverge over time.

The server ultimately being in control means we can tell the server what resources are important for specific pages with absolute knowledge of the page.

You read it correct.

By not moving our render blocking assets like CSS, JS and fonts over to the http/2 we rule out performance changes due to improvements to head of line block.

Our images were always on a separate hostname so the DNS lookup over is the same. We also did some initial benchmarking and found the new CDN to be more efficient than the old one.

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.

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.

Thanks mate, glad you enjoyed it.

Totally. There are a bunch of ways to address the performance issue. As I alluded to at the end of the post there serious technology considerations when preprocessing so much image data.

We're currently looking at whether we can solve use IntersectionObserver for efficient lazy loading of images before the enter the viewport.

H2's single long lived connection means it's a contender to replace websockets. As a bonus you get to use HTTP semantics.

Server push at the edge is problem atm. Current push semantics require the HTML document say which resources to push. That's an issue if you're serving assets off a CDN domain.

Asset domains make less since with h2 from a performance perspective but there are still security concerns that need to addressed.

There are discussions happening on how browsers can allow authors to resource prioritisation hints. I'm curious to see where it goes.

We'd ideally like to be able to say – "prioritise 10 images in the viewport". You hack it together relatively efficiently using IntersectionObserver now, but support isn't great.

Thanks mate, really appreciate it.

Hey all, I'm the author of that blog post. I'll be floating around for a while, happy to answer any questions.

I've thought about this also. Alternatively some mixed format file like yaml front matter style.

Almost like it puts cats on you

Had a power nap, and now I'm back. Your feedback has been awesome

Awesome list dude!

I hate to break it to you, I'm a Lakers man :) I'd make the trek to Staples.

Added Sunday Street fests though :)

You had me at "Damn, you are going to be very drunk and full after completing my list". Love this btw. I'll give it a proper look over at a saner hour (it's 5am here).

I'm curious what the law are around hitching a tow from a cable car on my skates Marty McFly style.. :/

Don't mind if I do :) https://github.com/xzyfer/us-travel-checklist/commit/7ca2239...

I'm more of a Lego Land man myself :)

This was interesting. Thanks.

I don't see how it's any different from a gist. By using Github I've intentionally limited my audience.

I felt like that would be mayhem to manage, and curate. I'm trying to curate a list of unique, individual experiences.

I like your idea though. Lunch is on me! https://github.com/xzyfer/us-travel-checklist/commit/c09178e...