Hi,
If you take a look at the waterfall view on this test
You’ll see the first batch of images have a very fast content download time, and the second batch have a very slow content download time
Is this related to http/2?
When I look at a waterfall in Chrome on my machine or using other tools like GTM I don’t see the same slow content download.
Thanks.
Yes, that looks like HTTP/2 but it also looks like the server doesn’t support prioritization/dependencies and is sending all of the resources down at the same time. Usually for a HTTP/2 server that does support prioritization you will see a long light bar and staggered content download chunks as each resource downloads in priority order.
You won’t see it locally unless you slow down your network connection at a packet level (Chrome’s internal throttling won’t show it).
Thanks for the quick reply Patrick!
Web Server is nginx 1.10.3
I assume prioritization/dependency tree building is controlled by the nginx http/2 implementation internally?
I understand what’s going on - kinda 
But clients who don’t understand http/2 start wondering why 7kb images take 2+ seconds to download is hard to explain.
Something is certainly wrong with your hosting.
Unsure the exact problem.
I steer clear of NGINX like the plague, as it only slows down well tuned LAMP Stacks.
If you look at detail of first image, the priority dhervivation seems completely broken.
Try first upgrading to Apache-2.4.33 + disabling NGINX + retest with Apache only. If your Apache is broken, unlikely NGINX can work around the problem. Recent Apache version changes have related to HTTP2 prioritization, so be sure Apache is latest.
If that’s working + you still think you require NGINX, then upgrade NGINX to 1.14 + retest.
If problem persists, likely this relates to NGINX + you’ll have to open a ticket with them.
This could relate to various bandwidth throttling code in Apache or NGINX, so best to also test disabling any sort of bandwidth munging + retest.
Just a quick counterpoint on NGINX, I’ve had nothing but good luck with scaling NGINX for php serving and found it much easier to deal with than Apache.
Both benefit from running the latest versions though as HTTP/2 support in each is relatively recent and prioritization wasn’t supported in the initial releases. Looking at the nginx changelog there have been a lot of HTTP/2 fixes since 1.10 (though none about prioritization jumped out at me).
FWIW, I generally find it a lot easier to use a CDN in front of my actual serving and most of them are much further along with HTTP/2 implementations (and even QUIC).
Hi!
I have similar results for all assets, not only for images, using Dulles, VA - Moto G4 - Chrome - 3GSlow configuration.
I am using akamai with h2 and I noticed since May the results are worst in the same environment.
April Test
[attachment=804]
May Test.
[attachment=805]
Thus, I would like to know if webpagetest changed anything on how testing on 3GSlow.
Regards,
Guille.
Hello!
Confirming pazguille’s problem, we have noticed similar difference in our test results.
All of the resources are loaded slowly in May/June, comparing to our results in March (not only images).
There were no changes in the environment. Only file sizes were changed a bit, but absolutely insignificantly.
Please compare median runs:
March tests - WebPageTest - Running web page performance and optimization tests...
June tests - WebPageTest - Running web page performance and optimization tests...
styles.css March
Time to First Byte: 403 ms
Content Download: 163 ms
Bytes In (downloaded): 27.4 KB
styles.css June
Time to First Byte: 430 ms
Content Download: 586 ms
Bytes In (downloaded): 27.5 KB
main.js March
Time to First Byte: 403 ms
Content Download: 950 ms
Bytes In (downloaded): 177.1 KB
main.js June
Time to First Byte: 431 ms
Content Download: 3858 ms
Bytes In (downloaded): 175.9 KB
March:
[attachment=808]
June:
[attachment=809]
