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 Pingdom.com – and after that GTmetrix.com
Here’s a screengrab of a Pingdom 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 GoDaddy 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 – an “F” (41).
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 Pingdom 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.
[pullquote]The plugin doesn’t add page weight to your site. We call this a “weightless” plugin.[/pullquote]
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 Pingdom 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
LongCache We demonstrate a common but little understood speed problem usually labeled as Leverage Browser Caching. Various tests report this…
For ages we’ve wanted the ability to switch off FontAwesome icon font. We see it as unnecessary baggage many themes include as a feature. In fact, most themes include it now. Sometimes, this 70k+ file is added to page weight just to make a single icon – like the magnifying glass in the search field, or perhaps the hamburger icon for a mobile menu. What a waste!
We learned we could “dequeue” that icon-non-feature in the WordPress functions.php file. But this always proved tedious or broke things. We wanted a faster, safer way to test. We asked our local WordPress meetup if they knew of a plugin that would remove FontAwesome painlessly. No one had any clue.
With TourniKit plugin not only can we dequeue FontAwesome, we can get rid of Google fonts and other heavy assets like unused sliders that have universal page loads.
Description: A tool for experienced frontend performance engineers to take control over the scripts and styles enqueued on their site.
Hey! We are front-end performance engineers! But the plugin doesn’t say, “Font Awesome Remover plugin.”
The word “experienced” in the description is scary. But the damage done by novices can be quickly undone with some built-in safety features.
Once the plugin is activated, browse to any page on the front of your site. An Assets link will appear on the top right of the WordPress admin bar. Click that to view and manage all assets globally.
The plugin control on the front because the assets only get enqueued on the frontend, so the plugin doesn’t really know anything on the backend. That’s why we only show the link on the frontend. But many people don’t understand this link location. It’s not in the admin dashboard. It dequeues assets globally – not per page.
What if I dequeued jQuery (or something I shouldn’t have done) and now my site is broken. Go to the list of plugins in your admin panel. Find TourniKit and click the “Restore Dequeued Assets” link. Nice and easy.
What a beautiful unusual plugin with a lot of hidden speed potential.
Oh, and it’s *virtually* weightless. Perfect.
Here’s another example: Navigate to a page where you’d like to disable some request that are superfluous. The unwanted request will show up in a speed test waterfall chart. In this case, the plugin Blog Manager Light loaded Twitter scripts. We don’t use twitter. And it loaded a stripped-down Font Awesome icon set that we didn’t need either.
We turned those unneeded requested scripts off with TourniKit plugin.
Other SpeedHospital Proceedures
TourniKit For ages we’ve wanted the ability to switch off FontAwesome icon font. We see it as unnecessary baggage many…
WordPress works fine. But you need plugins to add extra features and functionality. Without plugins, WordPress is not-worth-as-much. Plugins give you control over website functions and performance without writing any code. Choosing the right plugins play a big role in your mobile speed success.
It seems as simple as searching for the most popular plugins. Then installing and activating them on your website. The result: an instant functionality upgrade without needing technical knowledge.
The problem is most popular plugins are slow loading. They bog down your site. Often globally, meaning slowing every single page and post. We call that site drag. Other plugins are more forgiving. They don’t suffer from site drag. Instead, they load only where used – or where there’s a shortcode installed. How can you know if a plugin causes site drag? Experimentation. This undocumented gotcha isn’t in read.me files.
The plugin directory is one of WordPress’ great assets. It provides over 55,000 applications extending WordPress. It’s also completely open and free. Any author can contribute. Anyone can download. The plugin auditing process and security analysis are sometimes flaky. Bad plugins happen.
Many plugins have identical functions – but they’re not built the same. Some hog resources. Others are fine quality. You can solve about any WordPress problem with a plugin – or a plugin combination. We do research and experimentation to discover plugins helping mobile WordPress speed. We appreciate alternatives to bloated popular plugins.
WordPress.org used to place a label on plugins not updated in over 2 years. Now they indicate how many update version have been missed instead. This staleness warning may mean the plugin won’t work – or worst case – could break your site. Often, we find old plugins work great. Especially for speed. Even when they aren’t updated for years.
This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.
This shelf-life warning, above, scares people from unrealized opportunities. So we still test obsolete plugins. There are many compatible-and-clean 8- or 10-year-old plugins. There are always risks with even the biggest and best – and most popular. These unpredictable gambles include plugins with millions of active installs and recent updates. Even WordPress or Yoast stubs it’s toe. It happens to the peerless.
The Plugin Review team takes down a plugin if it’s becomes vulnerable. But they don’t always notify users when this happens – or tell us to remove a bad plugin. We know this from sad experience.
SpeedXray measures load-time impact expressed in seconds for every plugin you have activated. It helps narrow down plugins causing potential speed issues. SpeedXray doesn’t work with newer PHP version 7+. You need to dial back PHP in your hosts Cpanel to version 5.6.
Description: See which plugins are slowing down your site. This plugin creates a performance report for your site.
After testing, don’t leave it installed. At least, disable it. It’s not needed except when measuring. This keeps your site fast.
There are attempts to prove SpeedXray plugin doesn’t work well – or that it’s results are meaningless. Surprise! We agree. What’s important are the relative results. Not the absolute numbers generated. It’s ranking the worst-offending plugin to the least – with values in seconds. Data is presented in alphabetical order, not in milliseconds. We sort in a spreadsheet. But there’s intuitive data to analyze and we appreciate it. Some say the results are ±30 percent off. Not from our experience. There’s no way to prove accuracy. We don’t care. Our gut says the ranking is correct enough.
SpeedXray is needed for speed assessments. It shows information not represented in any known speed report we’ve found. It’s not crippled when using workarounds for it’s shortcomings (dialing back PHP).
Let’s look at some SpeedXray results for PagePipe.com which loads in under 1 second. We were using the free theme Magazeen-Lite at the time of this test (active installs: 400+, Zip download: 432k). It’s load time is 37 milliseconds according to SpeedXray. Fast! We selected this bare-bones theme because it’s package size was small and light. NOTE: We’re now using the Twenty-seventeen default theme – even though there are newer default themes. Load time is around 20 milliseconds.
We have: 56 free WordPress plugins. What?!
That’s right. 56 are active. 4 are inactive. SpeedXray says they all load in 396 milliseconds. Good enough. We suspect they load faster than that. But as we’ve said; it’s plugin rank that’s important for sorting.
The inactive plugins include:
Broken Link Checker (which we run quarterly).
UpdraftPlus Backup/Restore (set to run automatically once per week).
Replace Image (enabled as needed).
Optimize Database after Deleting Revisions (we activate and run once monthly for cleaning).
Most of our inactive plugins are “resource intensive.” That means they hog database and RAM on the host server. If they all were running at once, our generous hosting provider would – with total lack of courtesy – shutdown our site. Our resource overages affect our other 23 shared-host neighbor’s speed. Can’t upset the server neighbors! NOTE: We were finally forced to buy more resources by GoDaddy for RAM overruns.
After installing iThemes Security plugin, we got a GoDaddy email notification. It said our hosting account exceeded its resource limits. We dumped the plugin. Read More.
A few other speed tidbits: Worth-The-Read plugin used to be set active only on posts, not pages. It’s our third heaviest plugin at 39 milliseconds. That’s actually pretty light – but we’re picky. How did we do that? Selective plugin activation. Read more here. [Note: we got rid of this plug at a later date.]
Our heaviest plugin is SS Downloads. We activated this plugin only on “download posts.” There are about 7 or 8 posts with this feature. It has a 120 millisecond load. It’s 30 percent of the total plugin weight. We found selective activation conflicted with the Autoptimize minification plugin. Downloads then produced a 404 error. We tested with another minification plugin substitute, Better WP Minify. The same error occurred. Minification was more important to speed than selective activation of SS Download. That isn’t always the case. But it was this time. Minification often is tricky and nonessential. If we deselected minification on the download posts, it broke the site – a catch-22.
In the end, we deleted the SS Downloads plugin. And we didn’t install a minification plugin.
Pareto principleis still alive! 10 of our heaviest plugins contribute to 80 percent of the cumulative weight (see column 3. The red text indicates the 80 percent cutoff). Roughly 80 percent of the effects come from 20 percent of the causes. In this case, 80 percent of the slowness comes from 20 percent of our “red-heaviest” plugin choices. These slower plugins needing the most scrutiny.
Easy Forms for MailChimp plugin is number four rank at 26.5 milliseconds. The solution: don’t use it on every sidebar. We place a sidebar 3.5k PNG image linking to a signup page. Then we only affect one page. This we sometimes refer to as offloading. But we aren’t offloading to another site or server, just to another page. Update: We now let MailChimp completely handle the signup on their site instead of bogging down ours with their script. They host our designed signup page. So we no longer do onsite page offloading. We do server offloading to MailChimp. Signup page example below:
Here’s the SpeedXray ranking results:
The only plugin we’d consider dumping – if we were under duress – is WP Counter (rank: 7, speed: 13 milliseconds). But it makes us feel good and crazy about our work. We can view some simple visitor stats in our dashboard. Look! There you are – visiting us!
We decided to run a test on WebPagetest.org. This produces a homepage worst-case scenario (950 milliseconds). Pingdom being best-case.
It’s not the quantity of plugins – it’s the quality.
Is this homepage beautiful?
No. It’s fast. It focuses on usability. Site goals are the foundation for decision making. We’ll improve branding and expressive aesthetics later. That costs money – and always slows down the page. The page needs to prove itself with results first. Then we’ll formalize the graphics. Or maybe we’ll leave it “as-is.”
How to extract SpeedXRAY data by rolling back PHP 7.x to PHP 5.6 or 5.4
Are delinquent plugin slowing your site speed?
Too many activated plugin slowing your site is a speed myth. The number of plugins isn’t important. It’s not the quantity, but quality that affects speed. Your site can have over 80 plugins – and still load in under 2 seconds. The WordPress average number of active plugins is 25 per website.
Another web speed myth is that popular or paid plugins are the best. It’s often the opposite. Popular plugins usually slow down sites most. Testing reveals the truth.
You can deactivate all plugins and then retest your site speed. If the site loads faster, you know there’s a problem with one or more plugins.
This tedious method then requires activating plugins one at a time for problem discovery. Repeated speed tests are required consuming time and energy.
An alternative method is using the SpeedXray plugin to evaluate plugin load time in milliseconds . This older plugin only works using server-language PHP 5.6. You need to rollback PHP to version 5.6 from newer versions – for example – PHP 7.1 or 7.2.
The SpeedXray Plugin is a more intelligent way to track down resource hogging plugins.
Our goal is ranking the slowest plugins consuming 80 percent of plugin overhead.
This Pareto principle – or 80/20 rule – helps identify the sweet spot for balancing functionality and user experience with the fastest load time.
This technique is also known as value analysis. Slow plugins then are selectively activated – or substituted with faster alternatives – or eliminated.
Note: Many managed WordPress hosts, such as WP Engine, do not allow site owners C-panel access.
This video tutorial demonstrates a workaround to extract SpeedXray plugin data for ranking individual plugin overhead. This is our method of quantifying performance optimization.
Shown here is GoDaddy C-panel access. This feature is included with low-cost Linux hosting.
Scroll down to the software section.
Click the select PHP version link.
That opens an area to switch PHP options.
Here it’s currently set to version 7.1.
Roll back the version with the drop down menu to version 5.6. Click the “Set to current” button.
Version 5.6 is the required for SpeedXray. It doesn’t and can’t run on newer PHP versions.
On the site we’re testing, there are 69 active plugins.
We’ll determine which ones cause the most site drag using the Pareto Principle or 80/20 rule. That is where 80 percent of consequences come from 20 percent of the causes.
Go to the SpeedXray plugin in the WordPress dashboard and click the “Scan Now” text link. Then press the “Start Scan” and “Auto Scan” buttons. Scanning takes about 25 seconds to complete.
When presented, click the “View Results” button.
The SpeedXray plugin produces pie charts representing qualitative results. These displays aren’t very helpful. We want quantified data for benchmark comparisons of potential speed savings.
Click the “Email these result” text link below the pie chart.
A small window pops open labelled Email Report. We’ve never had any success emailing plugin results to ourselves or others.
Instead, with your cursor over the “results” text box, right click and select “Inspect Element” using your browser inspector tool. Or use another equivalent function.
This opens a developer tools window. The code of interest, labeled text area, is highlighted in dark blue. Click in that area. Then double click the code and you’ll see a small format change. The code is still highlighted. Do a keyboard [control-C] and copy this code.
Paste the raw code [control-V] into a standalone text editor. Name and save the file.
Close the email windows.
Deactivate SpeedXray plugin.
Note: Leaving it activated slows your site. Leaving it installed for later reactivation has no speed consequence.
Go to your C-panel and restore the PHP setting to version 7.x.
We analyze the saved data with a spreadsheet program.
When the final sorted results are shown notice which plugins are the heaviest.
#1 – Yoast SEO plugin – that load time has doubled since this test. We say get rid of that slow plugin.
All the heaviest plugins can be substituted of eliminated. Notice WP Rocket is one of the heavier ones. The irony. A speed plugin. Also, WP Disable another speed plugin causes global site drag. Avoid these plugins.
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…
Apopular WordPress form plugin is installed on over 1 million WordPress websites. The favored culprit is Contact Form 7. It adds 37k page weight to all pages on your website. And a 79.9 millisecond delay. Everywhere. Even when the plugin is only used on one page – such as your contact page – the plugin “globally” slows down all pages. This “global” activation is even more problematic for heavier plugins like Google Maps or social media controls. We call global plugin activation “site drag.”
Other form plugins are lighter and faster. But substitution isn’t the solution or our main concern. What if we absolutely needed to use Contact Form 7 plugin because there is a special addon plugin that gives us more extended utility (And, there are addons!) How can you prevent global loading?
We fix it with a plugin that restricts a heavy plugin to just the pages where it’s needed. SpeedSwitch plugin allows you to selectively activate or deactivate a plugin using the post or page URL, the address of a World Wide Web page.
While our main focus is page-speed improvements, here’s another example of how plugin deselection can help:
We’re using the WP Image Borders plugin (266k compressed download) on a client’s website. It makes it easy to add image borders to pictures on pages or posts – but activation is global. The plugin adds borders to images on all pages.
But we don’t want borders around every image – as in the case of these circular buttons show here – the border ruins the look. So we deselect the border plugin for just that page. Problem solved.
Other SpeedHospital Proceedures
SpeedSwitch Loading plugins redundantly and globally decreases the speed of your pages. It’s best to deactivate heavy plugins on pages…