[wp-hackers] Plugin conflicts with latest version of Jetpack

Mike Schinkel mike at newclarity.net
Wed Jan 2 17:45:41 UTC 2013

On Jan 2, 2013, at 6:04 AM, Otto <otto at ottodestruct.com> wrote:
> This happens because you either:
> a) don't have a proper "Expires:" header being sent with the static content,
> b) the expiration has, well... expired, or
> c) you manually refreshed or hit F5 or something to that effect when
> you were testing your theory. Browsers treat a refresh differently
> than normal browsing.
> Content that is browser-cached and has an expiration date will not be
> re-retrieved, or even checked for last-modified, in a normal browsing
> situation... until the content has expired. Refreshing is not a normal
> browsing situation, it's an explicit request by the user to get new
> data.
> Check that you are correctly setting Expires headers for your static
> content, and see what happens when you're browsing among pages
> normally instead of reloading a page for testing purposes.

I've been studying HTTP since 2006, but I'll be honest I'm often confused by what I see in practice so I could well learn something here.

Let's take this CSS file as an example since I know the setup of that server and it's a newly installed WordPress 3.5:


If I do an HTTP request using a free Mac tool called HTTP Client I get these headers:

Content-Length: 9216
Date: Wed, 02 Jan 2013 17:02:37 GMT
Server: Apache
Last-Modified: Sat, 22 Dec 2012 09:21:13 GMT
Accept-Ranges: bytes
Connection: close
Content-Type: text/css

That is on a bog-standard CPanel install without a caching plugin.  As you can see, no Expires header.  Given the setup which is pretty similar to a lot of shared hosting wouldn't you expect similar for most WordPress installs?  My understanding is the server needs to be configured explicitly to serve Expires headers for static content which is something that most WordPress users are unlikely to have done.  Or am I missing something or misunderstanding?

On the other hand would you not agree that an Expires header does not help with the first page load and we know from Google's campaign to focus site owners on site speed that a first page load is critical for serendipitous surfing and discovery via search engines?  If you have a page that loads 10+ plugin's CSS and JS files it's going to be slower on 1st load than if it only serves what it needs. Of course if all the CSS files are bundled into one or just a few CSS files then that changes the equation but that too is not something I understand most WordPress users to have configured.

Educate me.


More information about the wp-hackers mailing list