search

andydavies / http2-prioritization-issues

Tracks issues / notes for HTTP/2 prioritization across browsers, CDNs and servers
MIT License
265 stars 7 forks source link

Fastly seems to have regressed despite 3 re-runs on WebPageTest #18

Closed mangs closed 4 years ago

mangs commented 4 years ago

Summary

I've had my eye on Fastly for about a year and am currently undergoing an evaluation with my job's infrastructure team to switch to them partially because of the results here. I've successfully re-run the tests here over the past few months, but today is a totally different story: unfortunately, they seem to have regressed in a major way.

Server / CDN etc.

Fastly

Browser

N/A: I re-ran the existing, passing test entry on the GitHub readme.

Link to WebPageTest result

This is the 3rd re-run I've done today with basically identical results: https://www.webpagetest.org/result/200406_JM_b519b629ad1060f18e4ce9c020210851/

I did the same as I've been doing over the past few months: open the passing result URL on the GitHub readme (https://www.webpagetest.org/result/181222_ZR_ed26f1066e51f9ef689aba928646ebb7/), then hit the "Re-run the test" button. Something seems to be very wrong unless I'm unaware of some recent change in the standard. But Akamai seems to have identical behavior as before, so I'm puzzled.

Link to upstream bug report

N/A

andydavies commented 4 years ago

@mangs

The tests above are run on a 3G network profile, and when Chrome detects a slow network it paces requests in a similar way to it does under HTTP/1.1, and that's what I think you're seeing in the tests.

Fastly still looks OK when run on the 3G Fast network profile - https://www.webpagetest.org/result/200406_DT_9e6d50b70c982a158167f354ea608fa0/

(Sure I've got a link to the Chrome 3G behaviour somewhere, I'll try to find it this afternoon and add it to the thread)

mangs commented 4 years ago

Thanks @andydavies ! I was hoping I was missing something. Much appreciated.