WebPageTest

josephscott · (This post was last modified: 10-24-2014 09:21 AM by josephscott.)

I've running more tests and I think I've got another useful data point.

A couple of weeks ago I was experimenting with 'gzip_static on;' in Nginx. I noticed that when that was turned on, and there was a pre-compressed file available, that the HTTP responses from Nginx looked more like a traditional static file ( which makes sense, it really is at that point ).

Specifically, look at the 'Response' section of Request #1 for the test that @igrigorik ran earlier in this thread - http://www.webpagetest.org/result/141023...1/details/

What is missing from that response is the "Content-Length:" header. I didn't think much of this originally. I figured that when Nginx was doing compression on the fly it simply didn't do the extra work to include that value in the response.

Then I remembered that with "gzip_static on;" it would include it in the length in the response. So I combined that with this experiment, turning gzip_static on and creating a pre-compressed test-slow.html.gz for Nginx to use ( gzip -6 test-slow.html ). A quick call with curl confirmed that with all of this in place "Content-Length: 1019" was included in the response.

Now for the moment of truth, I ran a new WPT test: http://www.webpagetest.org/result/141023_Z6_13WH/

The TTFB is back down to 35ms again!

So perhaps the issue really is with Nginx and the cross sections of SPDY and compression.

I should have looked closer, when compressing on the fly Nginx is doing "Transfer-Encoding: chunked".

This does a good job of explaining the situation with Nginx, HTTP compression, and content length - https://github.com/CPAN-API/cpan-api/iss...t-10258159

I think I've figured this out. Doing more tests to confirm.