Google pagespeed insights headache.

Web Hosting Podcast

Today on Episode 24, Web Hosting Podcast. Are you obsessed with page speed ranking? Speed is always a great thing to have but the realization is, getting that perfect score is almost impossible with a website. Megan joins me to discuss some things that may cause your site to be slow. We also dive into pagespeed insights and discuss some surprising and shocking results we got.

What can make your website slow?

• Slow hosting environment
• Images too large
• No caching setup on website, expires
• long database queries
• Running old versions of software, PHP, Apache, CMS software (WordPress, Drupal, Joomla, etc..)

If you use google pagespeed insights or pingdom website speed test, you may have got a low score for your website. A low score would be something in the 60-70 range. Anything above a 80 would be considered a pretty good score. I just want to point out that you should not obsess about getting a perfect score.

google pagespeed insights

Pingdom website speed test

Both of the pagespeed tests use a score from A (great) to F (fail). Of course you want to try and get all A in your grade score. But sometimes it is just not possible.

For a base line, I installed a default version of wordpress (4.9.8) on a domain I own. Right after installing, I ran both google pagespeed and pingdom website speed tests. The site is being served over SSL using the default free cPanel SSL certificate.

Google – Mobile = 70
Google – Desktop = 92

Pingdom = Overall 88 (B)

When you first run the test, you will get a list of currently applied optimizations as well as improvement recommendations.
My list of currently applied optimizations on a default install are as follows. NOTE: these may be different depending on your hosting providers setup and environment.

Avoid landing page redirects
Enable compression
Minify HTML
Optimize images
Prioritize visible content

From the list, you can see that I do not have redirects for the landing page, I have gzip compression enabled, my html is minified, my images are optimized, and I have content that is visible that is prioritized. But what does this all mean?

Landing Page Redirects :
This occurs when you redirect the main site the user is going to, to another page. Google provides some great examples.
Here are some examples of redirect patterns:
example.com uses responsive web design, no redirects are needed – fast and optimal!
example.com → m.example.com/home – multi-roundtrip penalty for mobile users.
example.com → www.example.com → m.example.com – very slow mobile experience.

Enable Compression :
We actually discussed this in the very first episode and it is worth noting again. Compression will shrink down elements before sending them to the browser. This saves bandwidth and can improve site speed by sending smaller elements through the internet. You can enable gzip compression in cPanel by going to “optimize website” and click on compress all content.

Minify HTML :
According to google here is what they mean by Minify HTML:
Minification refers to the process of removing unnecessary or redundant data without affecting how the resource is processed by the browser – e.g. code comments and formatting, removing unused code, using shorter variable and function names, and so on.
You should minify your HTML, CSS, and JavaScript resources:
To minify HTML, try HTMLMinifier
To minify CSS, try CSSNano and csso.
To minify JavaScript, try UglifyJS. The Closure Compiler is also very effective. You can create a build process that uses these tools to minify and rename the development files and save them to a production directory.

Optimize Images :
This rule triggers when PageSpeed Insights detects that the images on the page can be optimized to reduce their filesize without significantly impacting their visual quality.
This means that I do not have a image that is to large and scaled to fit the area. Do not scale images in your web framework. Always scale the image before uploading.

My initial run of items that needed improvement.

Reduce server response time
In our test, your server responded in 0.64 seconds.
There is not much to be done here. That is almost 1/2 a second for a response time. It could certainly be better, but this value will shift up and down depending on a lot of factors. If this value is higher than 1 second, then you may have a overloaded server.

Eliminate render-blocking JavaScript and CSS in above-the-fold content
Your page has 1 blocking CSS resources. This causes a delay in rendering your page.
None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

Leverage browser caching
Setting an expiry date or a maximum age in the HTTP headers for static resources instructs the browser to load previously downloaded resources from local disk rather than over the network.
This is simply setting a cache header or expires header. We covered this in Episode 1.

Minify CSS
Compacting CSS code can save many bytes of data and speed up download and parse times.
Like the Minify of HTML above, this is the same only for CSS. Removing objects and comments that are not needed will shrink the file size and allow the file to be served faster.

Minify JavaScript
Compacting JavaScript code can save many bytes of data and speed up downloading, parsing, and execution time.
Like the Minify of HTML above, this is the same only for JavaScript. Removing objects and comments that are not needed will shrink the file size and allow the file to be served faster.

Now here is where things get sketchy with these reports. Remember, my initial scan was Desktop 92, Mobile 70. On my next run, the test was worse and the only thing I changed was the .htaccess to allow for caching (See below). Now with this single change in place, my score is Desktop 90, Mobile 57. What gives here? Dropping 2 points on desktop after applying a fix makes no sense, and even worse is mobile dropping 13 points. To make matters worse, running the test a 3rd time with no changes except caching results in even lower numbers. Desktop 89, and Mobile is back up to 64. So lets make some more changes and see what happens.

Browser caching in .htaccess file
# 3 Months

Header set Cache-Control “max-age=7257600”

# 1 Week

Header set Cache-Control “max-age=604800”

Deleted two plugins
Hello Dolly and Akismet

Added
w3 total cache.
For this plugin, I enabled and then set the following options to turn them on. The first time I enabled this plugin, I got a 500 error. I had to remove the browser cache line from above, then the site rendered and I was able to adjust the settings for w3 total cache. Once the settings were saved, I was able to add the browser cache from above and things worked fine.

Page Cache enabled and using Disk : Enhanced
Minify enabled and using Disk : Enhanced
Database Cache enabled and using Disk
Object Cache enabled and using Disk
Browser Cache enabled
Fragment Cache set to disk

Click on Save All Settings and purge any cache by going to Performance in the top menu and Purge all caches.

After removing those two plugins, and adding w3 total cache my scores are as follows on the first run.
Desktop 97
Mobile 93
These numbers held after repeated attempts over several hours. It is still a mystery as to why the numbers dipped so bad after just adding caching, which should have helped the numbers not hurt them.

The changes above resulted in only needing two fixes, according to google.
Eliminate render-blocking JavaScript and CSS in above-the-fold content
Leverage browser caching

I am not going to worry about the first one, Eliminate render-blocking JavaScript and CSS. But what gives with the second one, I thought we added browser caching already. Well, we did, but there are some things you may not want to cache, or in this case W3 total cache does not want cached. The file in question is a minified JavaScript file, and it is likely that this file will change over time as you build your website and add plugins. If you cache a file that is known to change, then your users may not get the new file until the cache expires. So be aware when you want to cache files, make a note on which ones might change regularly.

With these settings my pingdom website speed score went from 88 (B), to 96 (A).

As you can see it is pretty simple to get some good scores, if you are worried about that. And you should be worried about some of them. Browser caching, minify files, everything helps improve the user experience. But focusing on getting that 100 is a lofty goal and not practical for a website that has valuable content. Try and keep it real by getting in the 90+ range and resolve the issues you can fix. W3 Total Cache is one of the easiest plugins to setup and use just to get these speed benefits and get your score up. There is no coding it is all done for you.