Get Started

In this post we will cover Google’s PageSpeed Insights suggestions for optimizing text based resources such as HTML, CSS, and JS. The suggestions offered often sound like technical jargon, so below is my attempt to demystify what they mean and what can be done about them.

Before diving deeper into the subject. It is important to be able to know what resources are causing the suggestion in the first place. When running a PageSpeed Insights test, under each suggestion there is a “Show How To Fix” link. When you click that link it shows the resources that PageSpeed thinks should be fixed. Doing this, you can find out if the problem is being caused by a specific plugin, a theme file, or if the resource is on a different domain.

In general, when you visit a web page, the first resource that is requested is an HTML file for that page. It’s a file that contains the basic content and structure for the site. The HTML file may request CSS resources which are used to describe how the page should look, it may also request JavaScript resources which are used to describe how the page can be interacted with.

Remove Render-Blocking JS

Your browser reads the HTML file from top to bottom. By default when the HTML requests a JavaScript resource, the browser stops reading the HTML file until that resource has been downloaded and executed. This means that if a JS resource is requested near the top of the file, the page must stop loading before it has even had a chance to display anything. This is known as Render-Blocking JS.

There are a couple of solutions for this such as telling the browser to not load JS until the rest of the HTML has been read, or telling the browser to download the JS while it is reading the HTML and only execute it once it has been fully downloaded. I won’t go over these solution in depth, because they are going to be very difficult to implement without technical expertise in this area and even then it may not be practical when using WordPress.

The reason for this is because most JavaScript files are loaded by WordPress plugins. Which means as soon as the plugin is updated, the files will revert back to how they were unless the author of the plugin themselves corrected the problem.

Follow these steps to improve this suggestion:

• Use as few plugins as necessary.

• If you see that a plugin is causing a lot of render-blocking JS, try to find an alternate plugin that is coded better.

• If the problem is due to a code-snippet, see if there is an alternate async compatible code-snippet available.

• Decide whether the performance:benefit ratio is worth having the plugin or code-snippet.

Minify Resources

This is the practice of removing all white space and non-executable code from JS and CSS files. This makes the file size smaller which will make it faster to download. In addition to this you can concatenate files together, i.e. if you are loading five JS files, they can all be combined into one file so that only one resource needs to be requested and loaded. The only downside to this is it reduces code readability and can occasionally cause bugs if not configured properly. Plugins like autoptimize can perform this task for you.

Follow these steps to improve this suggestion:

• Use autoptimize to minify and cache your JS and CSS files, ask a web developer for assistance if you need help configuring it

• Don’t use plugins that require loading a lot of resources

Optimize CSS delivery

You want your CSS to be consolidated into as few files as possible because a page cannot be displayed until all CSS has been downloaded and processed. If this were not the case, the user would see a flash of unstyled content until the CSS had finished downloading and processing.

There is a tricky way around this. You can put only critical CSS (The CSS needed to format the HTML before scrolling the page down a.k.a “above the fold content”) in the HTML itself (Inline CSS). Then you can tell the browser to ignore loading the rest of the CSS until the page has been displayed. This is fairly difficult to implement properly without a web developer, and in my opinion doesn’t give a big enough performance boost to justify its implementation for most web sites. Also, if you ever change your CSS file, your critical CSS would need to be updated.

Follow these steps to improve this suggestion:

• Use autoptimize to minify and cache your JS and CSS files, ask a web developer for assistance if you need help configuring it

• Autoptimize can also be used to implement critical CSS, which should likely be done by a web developer

Enable Compression

JS, CSS, and other filetypes can be compressed on the server before they are sent to the user, making their file size smaller. We have this taken care of in most cases, but you can let us know if you get this warning for a resource being loaded by your server and we can update your server configuration for you.

Follow these steps to improve this suggestion:

• If you’re hosted with us, email us or use our contact form to have us take a look. Make sure to check first if the resource that needs to be compressed is actually loading from your Orange Geek VPS

• If you’re not hosted with Orange Geek, ask your current web host about this issue

In our final post in this series we will be covering the rest of Google PageSpeed Insights Suggestions as well as general mobile optimization tips.

 


Stay tuned for the final post in this series:

June 26 – PageSpeed III – Optimize the Mobile Experience, Browser Caching, & Redirects

In this post we will cover in depth how to address the “Optimize Images” suggestion provided by Google’s PageSpeed Insights.

Images likely make up the majority of your websites page size. Page size is one of the primary factors that influence a sites’ load time. When checking to see if your images are optimized you should be looking at 3 qualities: format, resolution, and size. When Google provides the “Optimize Images” suggestion it is because one or more of these qualities is not optimal.

Format

First let’s discuss what format you should save your images in for use on a website. I will only be going over the 4 most common formats as they are the ones that should be used 99% of the time. The format you choose should depend on the content of the image.

JPG – JPG is a lossy format, this means that when you save the image it is compressed and artifacts are introduced, lessening image quality. When saved at a high enough quality these artifacts should be imperceptible to the human eye, especially at the resolutions used on the web. WordPress automatically saves your jpgs at 90% quality when they are uploaded. This image format is ideal for photographs and is likely the correct option for most of the images on your website.

PNG – PNG is a lossless format which means it can be saved with no loss in quality. The down side is that it produces images with a much larger file size than JPGs when there is usually no perceptible difference between jpg and png versions. PNG should be used on images that contain type, screenshots, images with less than 16 colors, and images that require transparency. The site header is commonly a PNG.

SVG – SVG is a vector format, this should be used when the image needs to be highly scalable, social media icons are commonly in vector format. PageSpeed insights will let you know if you have an svg file that is not being compressed. If you get that warning let us know and we can optimize your server configuration for SVG files.

GIF – The GIF format should almost never be used. Only use it when you require the use of animation. If you do use a GIF you should serve it from a server that is optimized for displaying GIFs such as giphy or gfycat. It is becoming more and more common for HTML5 video to replace GIFs.

The most common mistake here is when PNGs are used when JPGs would be optimal. In this case there are WordPress plugins that will convert all PNG files to JPGs. Using JPG instead of PNG also provides the benefit of taking up less space on your VPS.

Resolution

Image resolution is one of the easiest things to get wrong on a WordPress blog. If an image has a problem with its’ resolution Google PageSpeed will call it an “improperly scaled image” A lot of the time it is wrong simply because of a poorly coded WordPress theme. If you look at the two images below they appear identical, but the first is being loaded and displayed at a 680px width, the second image is being loaded at a 1000px width and then scaled down to 680px.

The first image is ideal because it is displaying at exactly the width of the blogs content. It is not loading at a higher resolution and then scaled down. Higher resolution images mean larger page sizes.

A properly coded theme will tell WordPress what sizes of images to create whenever an image is uploaded. By default WordPress generates a thumbnail, medium, and large image for every image uploaded. If a theme needs a specific size it will tell WordPress to generate a new size with a different name. i.e. “Slideshow Size at 800x300px”. It will then tell WordPress to use a “Slideshow Image” in the relevant part of the theme. If the theme is coded poorly it may not specify what image to use, so WordPress will use the unoptimized full resolution source image by default.

Fixing this issue can unfortunately be technical and may require an experienced web developer. They will need to:

1. Either change your theme
2. Add correct image size definitions to the current theme in the themes functions file and in every file where images are referenced.
3. Run the ‘Regenerate Thumbnails’ plugin to create thumbnails for the new image definitions out of the original source image.

If you have changed themes in the past and now realize there are some improperly scaled images in some of your previous posts, it is because the correct image sizes were not generated for previously uploaded images. You will want to run ‘Regenerate Thumbnails’ to fix this issue. We also recommend running the ‘Thumbnail Cleaner’ Plugin if you have switched themes and ran ‘Regenerate Thumbnails’ previously. It will get rid of image sizes that are not being used by the current theme which would make the space on your VPS run out faster than usual.

Another common mistake made when it comes to image resolution is with images manually placed in a sidebar widget. The theme doesn’t automatically resize images placed manually, such as in a text widget, so a full size 1000x1200px source image will be used when a 300x300px size would be appropriate.

Size

The size of an image is determined by the format, quality, and resolution of the image. If Google suggests “compressing” an image, they are suggesting you display the image at a lower quality. The easiest fix for this is to install an image compression plugin that will automatically compress your images on upload. These compressions should not cause a loss in quality noticeable to the naked eye. If you only care about compressing images going forward you just need to install a plugin (we recommend ShortPixel or EWWW image optimizer), activate it with the compression settings you want, and it will automatically compress every new image uploaded via WordPress. If you want to optimize all images previously uploaded to the server you will need to run the “bulk image optimizer” option. Most plugins charge for this service and depending on how many images your website contains it may be somewhat costly and take multiple hours to finish.

Hopefully this gives you a good idea of where to get started when Google’s PageSpeed Insights says you need to optimize images. To sum it up, if the details on the report say “Losslessly compressing <image> could save…” it’s a sign that you might want to use an image optimizer plugin. If the details say “Serve scaled image…” it means that either your theme is not generating/using the correct image size or you have a manually placed image that is over sized.

Join us next week as we cover how to handle several CSS and JS file problems in depth.


Stay tuned for the following posts in this series:

June 19 – PageSpeed Part II – JavaScript/CSS
June 26 – PageSpeed III – Optimize the Mobile Experience, Browser Caching, & Redirects

Three primary factors are going to affect the speed of your site: hosting, requests, and page size.

1. Hosting – Your site is never going to be faster than the server that it’s running on allows it to be. That is why at Orange Geek we have taken careful consideration into how much power you need in relation to how many people are viewing your site. We will work with you to ensure that the hardware your site is running on is never the bottleneck holding you back from a faster loading site. All plans at Orange Geek are on their own VPS (Virtual Private Server). This means that your site has its own dedicated resources and computing power. As long as your site is in our range of recommended monthly page views for your current plan, you are good to go in this category. Upgrading a plan unnecessarily will likely not improve the performance of your site, you should look at optimizing the below factors first. If you have any questions about hosting, we’d be happy to answer them for you!

2. Requests – Every resource loaded by your site including: HTML, CSS, Javascript, images, etc. must make a request to a webserver for that resource. Your pages’ speed will be affected by the source, number, and size of the resources you send requests for.

Source – Your site will load internal and external resources. An internal resource is one that is being loaded from the same server as your site, most of your resources should fall under this category.

i.e. your site at https://mysite.com is loading the resource https://mysite.com/wp-content/uploads/themes/mytheme/mycss.css

An external resource is a resource that is loaded from any other server. You want to avoid external resources whenever possible. This is because you have no control over the server that is loading that external resource or how responsive it is. In general, only use external resources for trusted sites or when necessary.

i.e. your site at https://mysite.com is loading the resource http://www.google-analytics.com/analytics.js This is fine as google is a trusted source and you don’t want to host analytics.js locally in case google makes any changes to it.

Number – The number of resources you send requests for can depend on several things: plugins, number of posts, number of images, ads, social icons, etc. Intuitively, the less stuff you have loading on a page, the faster that page will load. Some WordPress plugins can lessen the amount of resources that need to be loaded by combining them into a single .js or .css file.

Size – The size of a resource depends mainly on the type of that resource. Text resources such as css and js are usually small. They can be made even smaller by compressing the files. Images have a larger size than text but can be compressed by lowering the quality and size of the images. Size can also be reduced by using the proper image format for the type of image you are loading (.jpg, .png). Videos are often very large in size, most times it is preferable to load them as external resources from a server that specializes in video hosting such as youtube or vimeo.

3. Page Size – This is the final factor affecting how fast your page is going to load. Really it is just a direct result of the requests your site sends. It is the total size of all loaded resources. The less a user has to download on your site, the faster it will be loaded. Optimizing images, using less plugins, compressing files, and loading less content are all effective ways to decrease your page size.

To view information on the number of requests and the size of a web page, we recommend you use a tool such as Chrome Development Console. There are similar tools in all modern web browsers; however, when using Google Chrome you can simply press the F12 button, click the network tab, and then refresh your page. The following information will be similarly displayed:

1. An individual request
2. The status of this request, 200 means the resource was successfully loaded
3. The file type of the requested resource
4. The total time it took to load this individual resource
5. The size of this individual resource (not given if it was already in your cache)
6. Total number of requests sent by this page
7. The total size of all loaded resources
8. The time it took to fully load all resources, doesn’t appear until page has no resources left to load. You may want to enable a browser extension such as adblocker to get a more accurate reading here.

All the suggestions offered by Google’s PageSpeed test are due to one of the 3 factors being sub optimal. In the next posts we will start looking into individual suggestions, how they have an effect on these factors, and specifics on how to follow the suggestion.


Stay tuned for the following posts in this series:

June 12 – PageSpeed Part I – Image Optimization
June 19 – PageSpeed Part II – JavaScript/CSS
June 26 – PageSpeed III – Optimize the Mobile Experience, Browser Caching, & Redirects

 

Let’s start by clearing something up that can lead to a lot of confusion, PageSpeed and page speed are two separate things. PageSpeed Insights is a tool created by Google that “measures the performance of a page for mobile and desktop devices” and based on that performance assigns your site a score. On the other hand, page speed, aka “page load time”, is the time it takes for your page’s content to fully load. PageSpeed Insights is not a direct measurement of page speed.

PageSpeed Insights is not a direct measurement of page speed.

Google PageSpeed Insights

PageSpeed Insights provides suggestions to improve the performance of your site. These suggestions, as Google refers to them, are exactly that. Most of the time they are useful and should be implemented. For example, a common problem we have seen on WordPress blogs are unoptimized images and improperly scaled images. Fixing problems such as these is usually trivial and may drastically reduce your page size and overall load time.

Other times the suggestions may be impractical, costly to implement, or don’t make sense for your website. An example of this is when a suggestion says to “remove render blocking JavaScript” for a plugin that you have installed. In this instance your only options would be to remove the plugin or ignore the suggestion. Your goal should be knowing which suggestions should be implemented and which suggestions won’t have a noticeably negative impact on your websites performance or ranking.

Ignoring any suggestion means that your site will not receive a 100/100 Insights score. This is fine, you don’t need to get caught up on achieving an unrealistic score.

The average score of a site ranked on GTMetrix is 71%, and Google says a score of 85 indicates that a page is performing well.1 Google has never reported that PageSeed Insights score is a ranking factor. The most important ranking factors for SEO are:

Content
Backlinks
Meta data
Mobile responsiveness
Page load time

That isn’t to say that PageSpeed Insights has no bearing on your sites ranking, although its affect is indirect. All suggestions made by PageSpeed have some impact on page speed (load time), which is a ranking metric. Again, your goal is to determine how negatively each suggestion is impacting your performance before determining if it is worth the cost of fixing it.

Page speed – Page load time

Page speed is an important metric for your site and was made a ranking factor in 2010.2 Most visitors will not stay on your site if it continuously takes too long to load. These two factors affect your overall load time the most:

Page size – total size of all the loaded resources
Number of requests – total number of all resources (scripts, images, ads, css, etc.) being loaded by your site

Minimizing each of these will improve your page speed. In our next post we will be going over what affects your page size and total number of requests, what is a recommended result for these metrics, and how to effectively decrease these numbers to improve your overall page speed.


Stay tuned for the following posts in this series:

June 5 – Page Size and Number of Requests
June 12 – PageSpeed Part I – Image Optimization
June 19 – PageSpeed Part II – JavaScript/CSS
June 26 – PageSpeed III – Optimize the Mobile Experience, Browser Caching, & Redirects

  1. https://developers.google.com/speed/docs/insights/about
  2. https://webmasters.googleblog.com/2010/04/using-site-speed-in-web-search-ranking.html