WebPageTest

There might have been an update to WebPageTest yesterday, which affected this. Since yesterday afternoon, any website tested at any WPT location has resulted in its base html file receiving a failing mark for 'Cache Static Content. Prior to yesterday, the test did not rate the base html file for 'Cache Static Content'.

Yeah, good catch :-) I updated the caching logic to be a lot more explicit. It used to not check html and a couple of other mime types and it used to give an automatic pass to anything that had an expires header, regardless of the time.

The new logic (should) decode the date, expires, age and cache control headers and calculates the actual TTL for every resource. The only resources that are ignored are:
- no-cache (pragma or cache-control)
- negative expires time (usually set for explicitly dynamic content)
- app manifest files

I would expect your HTML to have a negative expires time or explicitly be set to not cache. Can you shoot a sample test over for me to look at?

I made the change (and was planning on talking about it tomorrow) because there were a good number of sites that were setting text/html for all kinds of content (javascript, images, all sorts of crazy stuff).

Thanks for the explanation, Pat. Here's a link to a test result:

http://www.webpagetest.org/result/111027...imization/

Quote:Response Headers:

HTTP/1.1 200 OK
Cache-Control: private
Content-Encoding: gzip
Content-Type: text/html; charset=ISO-8859-1
Date: Thu, 27 Oct 2011 12:37:34 GMT
Pragma: private
Server: LiteSpeed
Set-Cookie: bblastvisit=1319719054; expires=Fri, 26-Oct-2012 12:37:34 GMT; path=/; domain=.laptopgpsworld.com
Set-Cookie: bblastactivity=0; expires=Fri, 26-Oct-2012 12:37:34 GMT; path=/; domain=.laptopgpsworld.com
Vary: Accept-Encoding
X-Powered-By: PHP/5.2.17
X-UA-Compatible: IE=7
Transfer-Encoding: chunked

Unless I'm misreading the specs, private just means that a shared cache cannot cache the page, it will not prevent the browser itself from caching the page. For dynamic content it should be no-cache.

I could easily be wrong, that's just what I got from browsing around and from my memory.

No, Pat, you are correct. I just read about it on W3.

I've corrected it on my end:

http://www.webpagetest.org/result/111027...imization/

Quote:Response Headers:

HTTP/1.1 200 OK
Cache-Control: private, post-check=0, pre-check=0, max-age=0
Content-Encoding: gzip
Content-Type: text/html; charset=ISO-8859-1
Date: Thu, 27 Oct 2011 13:56:17 GMT
Expires: 0
Pragma: no-cache
Server: LiteSpeed
Set-Cookie: bblastvisit=1319723777; expires=Fri, 26-Oct-2012 13:56:17 GMT; path=/; domain=.laptopgpsworld.com
Set-Cookie: bblastactivity=0; expires=Fri, 26-Oct-2012 13:56:17 GMT; path=/; domain=.laptopgpsworld.com
Vary: Accept-Encoding
X-Powered-By: PHP/5.2.17
X-UA-Compatible: IE=7
Transfer-Encoding: chunked

In case other vBulletin users experience the same, to correct it go to:

vB AdminCP > vBulletin Options > Cookies and HTTP Header Options > Add No-Cache HTTP Header > Yes > Save

Excellent :-)

Hi Pat,

Three months have passed since we talked in this thread. In the past week, I've done some changes to the configuration of my site. The changes included a new Cache-Control header:


The "must-revalidate, max-age=0," part is (if I'm correct) telling the browsers not to cache (my html). The "s-maxage=86400" part is letting proxies cache it.

This is not a common scenario, but I wonder if you think the WebPageTest should not fail it with an "F".

Some test location (for example your Dulles, VA) give it an "A", but some (I can list them if needed) constantly give it a failing "F" (example).

I've corrected it on my end by replacing my existing:

Expires: 0

with the following:

Expires: Sat, 26 Jul 1997 05:00:00 GMT

Now the test gives me A.

http://www.webpagetest.org/result/120123...b59dffcc6/

Hmm, the base html file in the "Repeat View" is highlighted yellow. Does it mean my headers are still not the way they should be?

Yellow just means that the browser made a request and got a "not modified" (or other 3xx code) as a response. In this case I think that's exactly what you want.

Looking at the headers: http://www.webpagetest.org/result/120123.../#request1 it looks like there is an X-Cache: hit response which means it was served directly from the CDN.

Thanks Pat!