LongCache

We demonstrate a common but little understood speed problem usually labeled as Leverage Browser Caching. Various tests report this fault condition slowing down pages. But they don’t explain much about what it is and how to fix it. It’s pretty simple – and we offer a nice plugin solution.

There are various sites for testing page speed. Our favorite is WebPagetest.org. It’s a popular place so you usually have to wait in line – plus their test is pretty comprehensive adding more delay for results. Our go-to test for faster quick-and-dirty results is GTmetrix.com

Lightweight: 0.5 millisecond load time. 6.3k package size.

Here’s a screengrab of a Pingdom speed test for an optimized site:

The test says there are two “failures” (big red Fs). Those are #1 Minimize request size and #2 Leverage browser caching. That seems like pretty harsh criticism for a page that loads in only 658 milliseconds on cheap, shared hosting. We soon discover the bad review isn’t really warranted. Let’s take a closer look by expanding the “accordion” performance insights:

We almost laugh out loud at the itemization of errors. First, there’s only one URL that doesn’t fit into a single packet causing the first error condition: Minimize request size. And that’s an HTTP request call to Google CDN for a webfont. Completely beyond our control and something Google should care about more than us. Let’s move on and just ignore that single call. But talk about harsh – a red “F” (41). Why speed test scores are bogus READ MORE here: http://pagepipe.com/online-speed-test-scores-are-especially-useless-for-mobile-speed-improvement/ The second category, Leverage browser caching, says there are 6 errors. Five are image files and the last file is another Google font. Again, we have to ignore the errant Google font. Note: A simple font solution would be killing (removing) Google fonts and use the native browser fonts in the CSS stack. We could do this with Remove Google Font References plugin. But we feel the fonts add to the page “style.” The pages are pretty fast already and load time is more important than getting a good speed score. So how do we get rid of this Leverage browser caching problem? They give us a hint with the instructions:

The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future.

What does that mean? They are talking about a web speed trick called far-futures expiration. It is a best-practice for speeding up your website by using Expires or a Cache-Control Header. This is server-side coding that is added in the .htaccess file that resides on your server. There are many tutorials on how to do this manually. But if you are inexperienced at editing these kinds of files via Cpanel or FTP, we have a simpler, automated plugin solution. Read on: LongCache plugin adds a “far future expiration” date for various file types (like image files) to improve site performance. This is a best practice advocated by the Yahoo Extreme Performance Team. It keeps files and images cached longer. There is also a radio button to enable Gzip – a nice addition. (More about Gzip >) A first-time visitor to your page causes many HTTP requests, but by using the Expires header those components become cacheable. This avoids unnecessary HTTP requests on subsequent, repeat page views. The web server uses the Expires header in the HTTP response to tell your visitor’s browser how long a component can be cached (stored).

The Expires response header gives a date when a page component becomes stale.

Using a far future expires header affects page views only after a user has already visited your site. It has no effect for first-time visitors and the browser’s cache is empty. The impact of this performance improvement depends on how often users return. About half of your users or more could be return visitors. Your server’s .htaccess file can be appended by using some simple plugin settings:

Enable the LongCache plugin.
Set the expiration to 365 days (yes, 1 year).
Select all of the file types you are using.
Select Gzip compression.
Save.

The plugin doesn’t add page weight to your site. We call this a “weightless” plugin.

Will you see a speed improvement? It depends. If you didn’t have Gzip already activated on your server, you will see a big improvement. You’ll have a better speed test result. Returning visitors will have a better user experience because images and other assets are already on the browser cache waiting. You’ve paid homage to a theoretical speed improvement. The effort to make it happen is minimal. So why not just do it? We do – always. Leverage Browser Caching score is now an “A”. The only file that can’t be cached is the webfont from – ahem – thanks, Google.

Other SpeedHospital Proceedures

Instant-jQ Instant-jQ lets you use faster universal cached resources for better speed. WordPress theme developers normally use the resident jQuery…

Learn More

SpeedSwitch Loading plugins redundantly and globally decreases the speed of your pages. It’s best to deactivate heavy plugins on pages…

Learn More

KrunchKore Extra collection of 11 discrete plugins to strip or disable unneeded and unused baggage. This rescue kit includes an…

Learn More