Share This Post

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on email

You should definitely care about your site performance and using the tools that allows you to identify all the problems easily. 

The metric that is much more important than any score, which is awarded by those testing tools, is the page load time of your site. And to achieve a good page load time a good server environment and also optimized images are usually much more important than any theme optimizations you can do.

So make sure to not get obsessed with a good score, just for the sake of the score 😉

Also, while building our latest Enfold Update we also set up a total of 12 test environments and probably did 1000 speed checks. The conclusion that we came to, is that the trade-offs for a perfect score are oftentimes not worth it. (eg: compressing all your images to a point were quality suffers dramatically, using a ton of inline CSS and javascript to satisfy above the fold rules, etc)

Website loading speed is the latest priority for the overall user experience, and it’s also one of the hundreds of SEO ranking factors. Truth is, that nowadays people don’t have the patience to wait just more than five seconds for a page to load. If your website isn’t loading fast enough, you’ll lose potential customers.

With more than 50% of the online traffic coming from mobile devices, everyone expects a site to load almost instantaneously. With that in mind, in this article, I will also show you how we managed to score 100/100 with Google PageSpeed Insights Tool for Monitor Backlinks for both desktop and mobile.

Table of Contents

The Motivation

hubspot-pagespeed-score

For example, even if your site was loading quite fast already, but we also knew there’s always a way to make it even better.

One day, while playing with the PageSpeed Tool, We also noticed Hubspot website had a very terrible score for mobile devices, 10/100. The desktop version was doing a little better at 48/100.

Maybe they should also use this tool to improve their website, right?

That’s what pushed us to make our site load really faster and prove you can get 100/100. It’s not an obsession; it’s aiming to be perfect.

How To Make Pages Load Faster

Before I start showing the exact steps that we followed, let me tell you that the PageSpeed tool is only a guideline for the best web performance practices. It provides the recommendations for optimizing your website for page load speed and achieving favorable results depends on how your server environment is set up.

While some of these steps also require technical expertise, others do not. Note that they can be followed using almost any content management system (CMS).

Optimize Images

optimize-images

The PageSpeed Insights Tool also suggested that we optimize our images to load faster by reducing their file size. To solve this particular problem, we did two significant things:

  • Compressed all images using tools like the io and TinyPNG. These tools are absolutely free and can reduce the image file size by more than 80% in some cases, without decreasing the quality of the image.
  • Reduced the size of the images to the minimal dimensions without decreasing image quality. For example, if we wanted to have a picture at 150x150px on our website, that’s exactly the size the picture should have been on our server. You should never have the larger images than what you want them to render at, nor reduce their size using CSS or HTML tags.

We downloaded each of our such images, then manually compressed and resized them. After optimizing all those images, it’s best to make a habit of optimizing all the new images you upload to your server. Each new image should be compressed and resized.

Google also offers the option to just download your already optimized images, and you can just upload them to your server. You can do the same with JavaScript and CSS.

Minify CSS & JavaScript

Google was now telling us that we had to minify your JavaScript and CSS files.

The minifying process also reduces the sizes of your files by eliminating unnecessary white spaces, characters, and comments from your CSS and JavaScript files. Programmers will often leave many spaces and comments while coding. These can even double the size of your CSS and JavaScript files.

To fix this problem, we just installed Gulpjs on our server. The tool automatically creates a new CSS file and removes all spaces. It also creates a new CSS file automatically for all the new changes that you are making. In our case, it helped us to decrease the size of our main CSS file from approximately 300kb to 150kb. The difference was all in the unnecessary characters. For more instructions on how to remove white spaces, check Google’s guide.

If you are using the  WordPress, I recommend you to install the plugin Autoptimize.

You can also download the optimized files from the PageSpeed Tool.

Leverage Browser Caching

Leverage-Browser-Caching

For all website operators leveraging browser caching is the most challenging part.

To fix this problem, we also moved every statical file from our website to a CDN (content delivery network).

A CDN is a network of all the servers located at various sites around the world. They are capable of caching the static version of websites, such as images, CSS, and JavaScript files. The CDN also stores copies of your website’s content on its servers, and when someone lands on your site, the static content is loaded from the server closest to them.

For example, if your website’s main server is from Texas, without a CDN, a visitor from Amsterdam would have to wait for the server to load the site all the way from the U.S.A. With a CDN, your site is also loaded from a location that’s closer to the user. In this case, this is a place closer to Amsterdam. Therefore, the website will load faster.

We moved all images, JavaScript, and CSS files onto the CDN and kept only the HTML file on our main server. Hosting your images on a CDN will make a big difference in how fast your pages load for website visitors.

After we did this, the PageSpeed tool still annoyingly also suggested that we leverage our browser caching for some third-party resources.

We fixed the social media scripts problem by also replacing the counters provided by them with some static images hosted on the CDN. Instead of having third-party scripts that were trying to access the data from Twitter, Facebook, or Google Plus to get the followers to count, we hosted these ourselves and fixed the problem.

Even more frustrating than the social media scripts problem was that Google’s Analytics code was actually slowing our website.

To solve the Google Analytics script problem, we also did something rather difficult. As we didn’t want to remove Analytics from our website, we had to find a different solution.

The Analytics code is also rarely modified by Google more than once or twice per year. Therefore, Razvan created a script that runs every eight hours to verify when the Analytics code was also last modified. The script downloads the Analytics code again only if new changes are found. This way, we can host the Analytics JavaScript code on our server without having to load it from Google’s servers on every visit.

If no changes have occurred, then the Analytics code will also load from the cached version on our CDN.

When Google modifies its JavaScript code again, our server will automatically download the new version and upload it to the CDN. We used this script for all external third-party scripts.

Here’s a screenshot from the Pingdom Tools showing how everything loads from the CDN, including the Analytics code. The only file loading from our server is the homepage file, which is only 15.5 KB. Eliminating all third-party scripts hugely improved the overall loading speed

Enable the Compression

Implementing the enable compression suggestion can also be done simply in your server’s settings. If you are not very technical, you can ask your technical support team to enable GZIP compression for your server

Eliminate Render-blocking JavaScript and CSS Above the Fold

javascript-and-css

Eliminating render-blocking is one of the most complicated parts of improving page load speed also because it requires more technical knowledge. The main problem we had to deal with was moving all JavaScript code from the header and the body to the footer at the bottom of pages across the website.

If you are using WordPress, the Autoptimize plugin I suggested above should help you with this task. Check its settings, then uncheck “Force JavaScript inand check “Inline all CSS.”

Those two messages essentially mean the same thing: In order to render the page as fast as possible there should be as little external resources likes CSS files, Fonts, Javascript be in the head of the theme. If it must be there the page speed tools ask you to move them to the bottom of the site or put it inside the HTML document, instead of placing it in an outside file. This is because the browser needs to wait for those files to fully load before being able to display the site.

Enfold on its own tries to place as many of the files as possible at the bottom of the site to satisfy those requirements. However some external plugins may overwrite this. An example would be the Layerslider plugin that we use here. Luckily its quite easy to solve this issue, since the layer slider also got a few optimization settings. Head over to the Layerslider->Options Page and open the advanced tab. Set the options like this:

This will tell the slider to load its script in the footer of the page as well.

Another issue with above-the-fold content are custom fonts. If you are using one or more google fonts, provided by the theme, this will also hurt your score. The Enfold Performance page lets you change the way those fonts are loaded from header (which is the default) to footer. This is one of the settings that has a small trade-off. Setting it to load fonts in your footer will slightly speed up the page and satisfy all the page checks.

But it will also cause a short flicker of text on page load since the text will be rendered first with a fallback font, and only then will the Google font get applied.

Personally, I am not using this setting for our websites because I consider that font flicker to be very annoying, but if you want to squeeze every millisecond out of your page this will be necessary. In order to get a perfect score, this is also necessary so we will activate the setting as well.

As you can see, I also set jQuery to load in the footer and I disabled some other WordPress defaults that are not necessary for most sites (emojis and jquery migrate). If you are running a lot of plugins you might want to leave those settings untouched since they might cause problems with badly coded or outdated ones. (Please note that if you are running no plugins at all some of the options are set automatically for you and won’t be displayed)

Reduce Server Response Time

This statement is shown by insights if your site is served too slow. And slow is relative here because it means longer than 20ms.

In order to get that last 1 percent out of insights make sure that your site is using a caching plugin. Since I can remember our sites have run on Wp Super Cache. It is one of the easiest to use plugins that also offers options to fine-tune it. In most cases, you simply install and activate it and are done. That’s why it is also recommended on our Performance page 😉

Once the plugin is active visit the page once, so a cached version is generated. Once that is done your site will score 100/100 in google page speed insights as well.

Using a CDN, use Cookieless Domains, too many DOM elements

  • Using a CDN with Wp Supercache is rather easy. Here is a good article that lists the steps you should take.
  • Cookies domains: The Yslow testing tools are not up to modern standards here. With HTTPS almost everywhere now, this is no longer a necessary step. If you really want to do this for the sake of the page score, here is an article as well 😉
  • Reducing Dom Elements: One of the trade-offs I spoke about earlier. Too many DOM elements basically mean that our site is too large. In order to satisfy this, I will delete a few elements from the page, but I would not do this in a real-life situation If I thought that content is important 😉

Once all those steps are performed we are coming close at Yslow as well.

To squeeze out the last few points Yslow wants you to reduce the number of HTTP requests (less JS and less CSS files) and add expires header to all files. The later can only be solved if you are not running any google fonts at all (tradeoffs, you remember? :P) because thats the file that Yslow is concerned about: 

So in order to score perfectly we would work without our google fonts and disable them. Too many external JS and CSS files is a problem specific to our current test environment: the layerslider plugin has a few files that we can not compress at the moment with the current version of the Layerslider. We talked to the layerslider team and worked out some improvements to the slider together and applied those changes to the test server (they will be included in all future versions of the Layerslider Plugin so no need for you to do anything here)

Voila, we are there! (Here is a link to the test server test restults. It will probably be removed at some point in the future but for now you can use it to see that we were not cheating ;D )

Conclusion

These are the most important steps we’ve followed to make a score of 100/100 with Google’s Speed Tool. We didn’t optimize only the homepage. We also optimized an internal pages as well.

Subscribe To Our Newsletter

Get subscribe for freebies, tools, and blogging tips. Unsubscribe anytime.

More To Explore

Ashfaq Ahmad

I Ashfaq Ahmad Founder of BloggeRoundup. A blog that helps you to learn blogging, SEO, affiliate marketing and make money online tips. Join my Facebook Group and stay connected with other pro bloggers.