H/2 Image/Resource Prioritisation Seemingly Not Working

[Johan.T]

Hi,

Following Patrick Meenan’s talk at the Performance.Now() Conference last week, I grabbed an approx. 100KB image and ran it through the webpagetest dot org slash http2priorities.html image page generator. Subsequently, I ran that through WPT on Chrome 3G Fast.

As per his slides here: slideshare dot net slash patrickmeenan slash http2-prioritization (26 and onwards) I’m expecting the last 2 images, with the query parameter appended with -visible, to receive preferetial treatment in the resource loading waterfall.

Unfortunately, it doesn’t seem to be the case.

In the waterfall, you’ll see the image header chunks fetched around the 4,5s mark, an almost perfect line straight down. Resources 34 and 35 are the above the fold images. 34 gets discovered and picked up around the 6,5s mark (after resource 7 and 6 have loaded), and the 35th one not even until after 20 seconds (after all the other ones have loaded).

I see no prioritisation happening here. No interruption of the in-flight responsed.

Another surprise is the many dark purple chunks coming in. I get that serving progressive JPGs is done by just fetching enough data for the next level of progressiveness, but I’ve seen that a bit more concentrated in other waterfalls. Here it’s more fragmented in many more and smaller chunks than expected.

Resource details (Slightly redacted, links broken due to n00b post restrictions):

#34

URL: […]veyafb.jpg?h2unique=VnBdSBXpkr-visible
Loaded By: webpagetest.org/http2priorities.html?image=[...]veyafb.jpg:0
Host: […]m
IP: 104.20.34.x
Error/Status Code: 200
Priority: MEDIUM
Protocol: HTTP/2
HTTP/2 Stream: 65, weight 220, depends on 0, EXCLUSIVE
Request ID: 7364.34
Client Port: 43518
Discovered: 6.489 s
Request Start: 6.489 s
Time to First Byte: 2293 ms
Content Download: 11205 ms
Bytes In (downloaded): 100.6 KB
Uncompressed Size: 102.8 KB
Bytes Out (uploaded): 0.3 KB

Request 35 Response (34 practically identical):

expect-ct: max-age=604800, report-uri=“report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct”
status: 200
content-encoding: gzip
cf-cache-status: MISS
vary: Accept-Encoding
server: Cloudflare
last-modified: Wed, 20 Nov 2019 11:08:17 GMT
etag: W/“5dd51ea1-19b3a”
x-environment: Hipex/3 general
cache-control: max-age=14400
date: Tue, 26 Nov 2019 09:11:14 GMT
cf-ray: 53babbdd28e1c833-AMS
content-type: image/jpeg
:status: 200

As far as CF account settings goes:

Speed Optimisation

Image Resize is Off

Polish is Off

Auto Minify is Off

Brotli is Off

Enhanced HTTP/2 Prioritization is Off (Pat confirmed on Twitter this needn’t be on. Standard prioritisation should work out of the box.)

Rocket Loader is Off

Am I missing something here?

Regards,

Johan

[eva2000]

Do you have a link to your webpagetest.org test result url ?

[Johan.T]

Here’s the link, which I hope I can remove later again:

[eva2000]

You can remove your link now. I tested the online http2 prioritisation test on my own Cloudflare site and it seems to be working fine WebPageTest Test - WebPageTest Details using same test image Patrick uses visible.jpg

I did notice in your WPT result for last image 35 your response headers return gzip encoding which it should NOT do for images - maybe your origin server configuration related as it’s a cache miss so retrieving from your origin server

also only one of your 2 images supposedly marked for higher priority is actually showing the proper HTTP/2 dependency weight of 220x for request 34 but request 35 shows weight of 147x

compared to my working WPT HTTP/2 prioritisation test request 34 and 35 to get higher priority

response headers do not have gzip encoding like yours returned from origin server due to cache miss. Mine has additional headers added by origin server

HTTP/2 dependency weights are correct for request 34 and 35 higher priority with 220x weighting

[Johan.T]

Sharp! I had looked over the images being gzipped indeed. Let me address that first and see if it makes a difference.

[andrew36]

I tried to reproduce and it worked as expected

[Johan.T]

Strange. Whenever I re-run it, I’m not getting those results. Which location did you pick to test from? Might that matter? I’m testing with Amsterdam, NL - MeasureWorks. Chrome, 3GFast.

[eva2000]

FYI I am testing from Patrick’s recommended Dulles location with 3G profile not 3G Fast

[Johan.T]

Dulles, Thinkpad, Chrome, 3GFast indeed shows what Andrew sees. And that’s with setting Enhanced HTTP/2 Prioritization is Off still. I’ll shortly test with that On.

From that location, I’m also not seeing the Gzip compression on the Jpegs.

Thanks both of you for helping me on my way with this!