I guess it comes as no surprise to you that the Internet of today is all about speed, and it’s now every second that matters. Social media audiences got really spoilt by receiving what they want the very moment they asked for it. And with no exaggeration, this July was simply game changing for all SEO community due to the fact that page speed is now officially a ranking factor for mobile devices. In this light, our team has conducted an experiment to track correlation between page speed and pages’ positions in mobile SERPs after the update.
The level of Google’s dedication to improving mobile user experience is mind-blowing. Since mobile-first indexing has been rolled out in February 2018, Googlebot crawls and indexes pages with the smartphone agent in the first place. And, of course, social media marketers got affected by these updates like no one else. According to the Social Media Marketing Industry Report, bloggers and social media marketers mainly use social media for:
- Increasing traffic – 78%
- Generating leads – 64%
- Improving sales – 53%
The pressure is really high as, according to the research conducted by Google, 50% of your visitors expect your page to fully load within less than 2 seconds. And, as the same research states, people that had negative experience speed-wise with your mobile page are 62% less likely to make a purchase. I guess I don’t need to mention that not matching these requirements means losing money, audience, and reputation. So, in this article, I’m going to shed some light on the new rules for page speed measuring that I feel social media marketers need to know to not let this happen.
New rules
1. Separate tabs for page speed and optimization in PageSpeed Insights
You may have already noticed that the PageSpeed Insights tool looks somewhat different at the moment. Back in the days, after entering a URL, the tool would supply you with just one rating and a set of parameters like redirects, compression, minification, etc. that were believed to influence this total score.
Now that the tool experienced some changes, your website is evaluated according to two criteria: speed and optimization. Speaking of optimization, this is just the same old checklist that I’ m sure you remember from the previous version of the tool. However, when it comes to speed, it’s now measured on the basis of 2 parameters:
- FCP (First Contentful Paint), it measures how long it takes for the first visual element to appear for a user.
- DCL (DOM Content Loaded) measuring the amount of time needed for an HTML document to be loaded and parsed.
2. Switching from lab data to field data
The tricky thing about the above listed metrics (FCP and DCL) is that it often happens that the numbers you see in your tests don’t actually coincide with the ones Google shows in the speed tab. Why does it happen? The explanation is rather simple: Google incorporates data from its CrUX (Chrome User Experience Report) database, which means that these metrics are being calculated based on real user measurements.
The controversy occurs when Google sees your site as slow because of users’ poor connection speed, for instance, although it may be perfectly optimized from your perspective. Sadly enough, with Google switching from “lab” data to “field” data, there’s hardly anything you can do to improve your “field” data except for optimizing your website.
3. Optimization Score and rankings
I’ve slightly mentioned in the beginning of the article the experiment our team has recently conducted. The aim of the experiment was to understand the influence of Speed Update on mobile rankings.
In order to understand the correlation between page speed and mobile SERPs before the update, we’ve taken one million pages in mobile search results for analysis. It turned out that a page’s Optimization Score had a strong correlation (0.97) to its position in Google search results. We went further and conducted the same research after the update was officially rolled out. With another million pages, their Optimization Scores, median FCPs, and median DCLs for each unique URL being analyzed, the experiment revealed that:
- In mobile search, an average page ranking in between 1 – 30 positions has been improved by 0.83 Optimization Score points in comparison with the first experiment.
- The relationship between an average Optimization Score and the position in mobile SERPs is still extremely high – 0.95.
- There’s hardly any correlation between median FCP/DCL metrics and search results.
That brings us to a conclusion that Optimization is exactly what needs to be improved and worked on in the first place. And although now FCP and DCL can be hardly named ranking factors, with Google constantly raising its standards, these metrics might sometime become ones.
How to improve Optimization Score
Now that we know that it is Optimization Score that rules mobile rankings, let’s see what you can do to improve it. There are now 9 factors officially stated by Google that do influence Optimization Score. So, after you’ve analyzed your mobile website’s speed and spotted (hopefully not) its weak places, consider these 9 rules for Optimization Score improvement.
1. Try to avoid landing page redirects
If you want to improve your website’s performance, think of minimizing the number of redirects on your landing page. However, if you really need a redirect, it’s better to use 301 for a permanent one and 302 for a temporary redirect. Googlebot now supports these two redirection implementations:
- HTTP redirects
- JavaScript redirects
The core difference between these two is that HTTP redirects may cause some latency on the server-side, while JavaScript ones slow down the clients’ side.
2. Reduce your file’s size by enabling compression
Start off with turning on and testing gzip compression support on your web server. This can significantly reduce the size of the transferred response (by up to 90%). Have a look at the sample configuration files for most servers through the HTML5 Boilerplate project. What is more, consider going through your mobile website in order to remove any unneeded data where it’s possible because the best-optimized resource is a resource not send.
3. Improve the response time of your server
The best practice is keeping your server response time under 200ms. There’s quite a number of reasons why you server responses not as fast as you want it to. These are: slow database queries, slow routing, slow application logic, resource CPU starvation, memory starvation, etc. The first step towards resolving the issue is actually measuring your server’s response time. To that tune, I would suggest carrying out such audits on a regular basis to monitor any future performance regressions.
4. Implement a caching policy
In order to automatically control how, and for how long the individual response can be cached by the browser, use cache-control. Think of implementing Etags. By doing this, a revalidation token will be automatically sent checking if the resource has changed since the last time it was requested.
5. Minify resources
What you need to do here is to minify your HTML (HTMLMinifier), CSS (CSSNano), and JavaScript (UglifyJS) resources. By saying that, I mean removing all the redundant data (code comments, unused code, etc.) without affecting the way the resource is being perceived by the browser.
6. Optimize images
This is an uber important activity as image optimization can reduce your total page load size by up to 80%. There are 2 types of image compression: lossy and lossless. The thing is, when saved in a lossy format (JPEG), your image will look a tiny bit worse comparing to the original one. As a rule, these images take up a very small amount of memory and are very good for the web. Speaking about lossless images, they look better quality-wise but are much larger in terms of size. Both GIF and PNG are lossless formats.
So, the very first step towards image optimization is getting rid of unnecessary resources as well as metadata where it’s not needed. Next, instead of encoding text in images, you consider using web fonts. Adjust your images for them to fit a display size and replace them with CSS3 where possible. Select smaller raster formats, but make sure that they don’t interfere with quality.
7. Optimize CSS delivery
In case external CSS resources are small, you can insert them directly into the HTML document. By doing this, you will get rid of small external resources as well as allow the browser to go on with rendering your page. I would also advice you against inlining large data URIs in CSS files because it can negatively affect page render time. Besides, avoid inlining CSS attributes because that can result in unnecessary code duplication.
8. Give preference to visible content
Try keeping above-the-fold content under 14.6kB compressed, otherwise some additional round trips between your server and the user’s browser will be inevitable. So, in order to not let this happen, you need to limit the size of your data. This can be done by restructuring your website in a way that it loads crucial content first and by minifying the amount of data (HTML, CSS, and JavaScript ) used by your resources.
9. Remove render-blocking JavaScript
First and foremost, you should try to avoid blocking external scripts because otherwise the browser will have to wait for the JavaScript to be fetched, which may add some extra roundtrips for the page to be rendered. However, if the external scripts are small, inline their contents into the HTML document in order to avoid any extra network requests. Remember that inlining enlarges the size of your HTML document, that is why it should only be done with small scripts.
What is more, use the HTML async attribute on external scripts to prevent JavaScript from blocking the parser and defer non-critical scripts and 3rd party JavaScript libraries at least until after the fold.
You can find these tips summarized in The Ultimate Guide to Improving Your Optimization Score. If you’re willing to dive deeper into the topic of the above listed rules go ahead and visit Google’s PageSpeed Insight Rules for more detailed tips and technical information. A good news for marketers is that they don’t necessarily need to be developers to improve their site’s performance speed-wise.
