Memorize this – “SPEED MATTERS, SLOW SUCKS!” When you memorize this and make it a mantra for your website optimization efforts, you are talking the language of Google. Yes, speed matters so much that if your website is slow, Google is going to push it down in search results. Nobody wants that. Even you don’t want it, do you?
So, OPTIMIZE, OPTIMIZE, OPTIMIZE…
A well optimized site should load fast. But what should you do for optimizing your site? You test your website with Google PageSpeed Insights and you get terrifying visuals. Lighthouse results pin you down and you don’t have any clue whatsoever about things like First Contentful Paint, Largest Contentful Paint, Speed Index, Time to Interactive, Total Blocking Time, and Cumulative Layout Shift.
What do you do? Who do you go to?
No one! You don’t go to anyone! You don’t need to be a developer to achieve a near-perfect score on Google PageSpeed Insights.
Wait a minute!
Why am I saying ‘a near-perfect score?’ Why can’t it be a perfect score?
That’s impossible for many reasons. I will come to this later. But my suggestion is to “obsess with speed, but not a perfect 100!”
One simple reason why I say that you shouldn’t strive for a perfect 100 is that the test conditions keep changing. The conditions include everything from the device used to the internet connection speed to the exact location of test. As these parameters keep changing, so does the score.
Take for example, when you load a site on a mobile device using a Wi-Fi connection, it will load faster. When you use a 4G, the speed will decline a bit and the website will load relatively slower. Switch to a 3G network and you will see a significant drop in loading speed.
That explains why Google PageSpeed Insights test results are so skewed when you test the same URL again and again. There’s absolutely nothing you can do about it. What you can do is strive to get the best possible for different scenarios.
That’s the reason why I said – obsess with speed, but not a perfect 100!
Okay, coming to Google PageSpeed Insights, when you test you site, it is evaluated on 6 broad parameters.
What do they mean?
Let’s find out.
Core Web Vitals
The six broad parameters that you see on Google PageSpeed Insights are known as the core web vitals. Somewhere in 2021, these core web vitals will became the official ranking factor.
Core web vitals are real-world experience metrics. Yes, the content on your site is important, but that is not stopping Google from introducing the core web vitals. These real-world experience metrics address a few questions that include:
How fast is your website loading?
How fast is your website becoming interactive?
How fast is it becoming stable?
And so on…
Put it this way…
If you are a visitor to a webpage, how is your experience when you are interacting with the webpage through your mobile or your desktop? Is the website loading fast enough, or are you required to wait for long to see the webpage? Is the website becoming interactive quickly? Simply put, can you navigate around and click around on the webpage quickly enough, and will the webpage respond to all those clicks?
If your website is not performing right in all these metrics, your site will fall in bad books of Google and that is something you want to avoid.
Okay, now that you know that core web vitals are important, let us look at each of the parameters individual and try to understand what each of them mean.
Ready?
First Contentful Paint (FCP)
This represents just how quickly the content of your webpage such as texts, images, videos, etc. show up on the page. According to Google, the FCP of 0.9 seconds or less leads to good user experience.
Largest Contentful Paint (LCP)
It represents just how quickly the largest image, text, or video of your webpage shows up on the viewport (it represents the part of the website that a reader can see on the viewport or the screen without scrolling). So, LCP represents the largest thing in the viewport. Good user experience comes when the LCP takes 1.2 seconds or less. It may happen that the FCP and the LCP are the same.
Speed Index (SI)
It represents how quickly your webpage’s contents are visibly populated. It may sound pretty similar to FCP or LCP, it isn’t! It is dependent on browser viewport size, but it doesn’t indicate a milestone in the loading time of the webpage.
Instead, it uses a frame-by-frame analysis of the loading behavior of the page and eventually reflects the visitor’s page experience.
Of course, it is time to the other page load timings, making it a good overall benchmark for assessing website performance in entirety. A good user experience, according to Google is when the Speed Index is 1.3 seconds or less.
Time to Interactive (TTI)
Just because the FCP or the LCP has occurred, it doesn’t mean that your website becomes fully interactive. TTI represents the time when the browser becomes capable of reliably responding to the inputs from the user on that webpage.
Remember that just because a webpage has rendered some content doesn’t mean that it can become interactive within that time. Even if someone clicks, it might not actually respond to that click until other elements of the webpage loads.
Google says that for good user experience, TTI should be 2.5 seconds or less.
Total Blocking Time (TBT)
It represents the total amount of time the website was blocked from reacting to user inputs. This block may come from CSS or JavaScripts or other forms of scripts. Render-blocking CSS or JS are often the primary culprit for increase TBT.
Unless you are a developer (in which case you should already be knowing everything I am writing here), you are not supposed to know that the browser uses something called main-thread for parsing HTML, constructing DOM, executing CSS and JS, processing user events, and performing several other important tasks.
If any of the aforementioned tasks run for any more than 50 milliseconds, it is referred to as a Long Task. When a Long Task runs, the browser cannot interfere it, and hence, main-thread is considered blocked.
Google says that TBT should be 150 milliseconds or less. The lower, the better.
Cumulative Layout Shift (CLS)
It simply means unexpected shifts in the layout of the web elements during page rendering. All layout shits that happen are then quantified as an aggregate score. A good example of CLS is when you try to click on something, that clickable link or button unexpectedly shifts to a slightly different location. The result is a misplaced click.
CLS can be caused by many factors like lazy loading of images or ads. However, it can be deliberately caused by webmasters to earn from misplaced clicks on ads or shopping cart buttons. CLS can lead to terrible user experience, and hence, lower the CLS, the better it is.
According to Google, CLS should not have a score of any more than 0.1. It is not measured in time, and hence, you will not see seconds or milliseconds attached to the score.
First Input Delay
You will see something called FID or First Input Delay. What is that? It is the same thing as the TTI or time to interactive. There is no difference.
Core Web Vitals – Weight of Individual Parameters
Okay, now that you have a fair idea of what these parameters mean, you need to know how much weight each of the these parameters carry, and how much impact the can have on your website’s SEO.
Here is the weightage the Google gives to each of these parameters (irrespective of mobile or desktop):
- First Contentful Paint: 15%
- Speed Index: 15%
- Largest Contentful Paint: 25%
- Time to Interactive: 15%
- Total Blocking Time: 25%
- Cumulative Layout Shift: 5%
So, the maximum impact comes from both Largest Contentful Paint, and Total Blocking Time. If your website is performing terribly in these two areas, you have to fix them with absolute urgency.
For the remaining, do not make the mistake of thinking that they are not very important. Look at the cumulative weight of the remaining four elements! That’s 50%. So, if your website is not performing well in those parameters as well, you will be in serious trouble.
What Should You Do to Improve Your Core Web Vitals Score?
There is no single mantra or a magic spell. I cannot tell you exact what needs to be done for your specific site. It all depends on your site design, structure, and purpose.
For instance, if you have a photo-heavy site, it will be slower than a simple blog. Similarly, WooCommerce stores can be slower than blogs. Speed also depends on the theme, number of plugins you are using, and more [I am assuming that you are using WordPress that powers nearly 40% of the web].
However, there are certainly a few things you can do. Let’s check them out one by one.
Use a Good Hosting with SSD Storage
A hosting provider with fast SSD storage can help a lot. Well, your website needs to sit on a storage device in the metal server. There are various types of storage units. You will get the traditional HDD drives that have spinning or moving parts. They are slow. SSD drives, on other hand, are fast. The same storage unit will also have the web server that handles all the requests.
If the storage unit is slow, the response time for the web server will also be slow. This will have a snowball effect and eventually lead to a slow loading speed. You will very likely see the warning related to “Initial Server Response Time.”
I will always suggest web hosting companies like SiteGround, GreenGeeks (if you are settling for a shared hosting company), WPX hosting, Liquid Web (if you are settling for a Managed WordPress hosting), DigitalOcean, Vultr, AWS, Google Cloud Hosting (if you are settling for cloud hosting).
Use CDN to Reduce Initial Server Response Time
A slow storage isn’t the only reason for high initial server response time. If you are settling for a dynamic content management system like WordPress, you should also use a CDN to reduce the initial server response time.
WordPress, for example, dynamically creates pages using PHP whenever a request is received by the web server. This takes time. So, it is always better to create and store cached HTML copies of the pages. Whenever a request comes, the cached page is served quickly instead of creating the page dynamically. This also reduces the initial server response time.
This also helps in ensuring that your server is not overwhelmed by too many requests at once. A CDN server can handle those requests and send the cached copies to the browsers, thereby reducing the work load of the server where your website sits.
Serve Scaled and Next Gen Images
In case you don’t know, images are the main culprit in increasing the webpage size. They make up 21% of the webpage weight! You can read my full article on image optimization here.
So, you have to optimize your images before uploading them to your WordPress site. I usually recommend that an image should not exceed any more than 50 to 60 KB post optimization.
Google is pushing for WebP format of images, and you need to find a way to serve that format. They are very lightweight and loads quickly. Remember, not all browsers will support WebP. So, you will need JPG or PNG formats as well. Try to use SVG images wherever possible.
You can use a plugin or a third-party service for delivering WebP version wherever possible. I usually rely on both Cloudflare and LiteSpeed Cache for this. They can both serve WebP images to supported browsers.
Coming to the issue of scaled images, you should not try to resize the image using CSS. That leads to extra CSS calls (that can become render-blocking or add to Long Task). You should use multiple copies with each copy having different dimensions. This is what is called scaled images.
Usually, you don’t have to worry about creating multiple copies. WordPress does that automatically. All you need to do is upload the image. That’s it! If you want, you can use a third-party service like Optimole that can not only server scaled images depending on the viewport of the reader, but also optimize your images to smaller size and even serve WebP images whenever possible. Remember, Optimole is an image CDN that uses Amazon CloudFront.
Use CDN
Use CDN! That is a must! It can not only help to reduce the server response time, but also server static resources of your website from servers across the world, thereby speeding up your website.
A CDN will make copies of your website’s static files that include images, CSS, JS, HTML files, and keep them stored in servers spread globally. When a user requests your website, the CDN will serve the cached files from the server closest to the user. This saves a lot of transit time and makes the website load fast.
I very strongly recommend Cloudflare because not only is it completely free to use, but also, the free version will give you protection against DDoS and DoS attacks. If you can spend $20 a month for Cloudflare, it will give you a lot more features including WebP version of images, Web Application Firewall (that prevents hacking and malware injection), country blocking, Always Online, and much more.
In case you don’t know, Always Online is a feature that will make your website available even if your actual server is down for some reason.
However, using Cloudflare is a choice. You can settle for other CDN providers like KeyCDN, Amazon CloudFront, etc.
Use an Efficient Cache Plugin
It is necessary to get an efficient cache plugin. I always recommend using LiteSpeed Cache, which is by far the best. Combine this with LiteSpeed web server or OpenLiteSpeed web server, and you get cutting-edge cache system. LiteSpeed Cache with LiteSpeed or OpenLiteSpeed server gives true server-side caching.
If you want to LiteSpeed Cache with Apache or Nginx, that is also possible (read my LiteSpeed Cache review and user guide).
A cache plugin will allow you to cache the static resources of your website, enable browser caching, and optimize your website by minifying and combining CSS and JS files. Such plugins can also help you to defer loading of render-blocking assets like CSS and JS.
Here is a quick snapshot of what LiteSpeed Cache can do for you:
- Cache the static resources of your site.
- Enable browser caching.
- Enable Keep Alive feature.
- Minify and Combine CSS and JS files.
- Defer loading of CSS and JS files.
- Make Google fonts load asynchronously.
- Remove query strings.
- Localize Gravatar and even localize many external domains like CDN, Google analytics, Google tag manager, and more. Localization will allow them to load quickly from your server instead of calling the resources from third-party servers that eat up a lot of time in DNS lookup and other factors.
- Offers 1-click database optimization features.
- Converts MyISAM table engine to InnoDB engine, which is much better.
- Converts images into WebP images.
- Allows lazy loading and gets rid of CLS issues caused by lazy loading by offering a low-quality image placeholder.
Combining CSS & JS files
Minification of CSS files and JS files is fine. That’s not going to cause any problem. It only removes the unnecessary characters. Without those characters, these files work just fine. So, you can happily minify them without any type of impact on your website.
However, when it comes to combining the CSS files or the JS files, you should proceed with caution. There will be various CSS files and JS files for your website. Some may come from the theme you are using while others may come from the plugins you are using.
Combining them can cause problems and break your website’s functions or overall design. Some are safe to combine while others need to be left alone. Moreover, when you combine multiple CSS files or JS files, the eventual result can be a big file. Typically, if a CSS file is exceeding 60 KB, its problematic.
My suggestion to you will be to try to combine them before you implement a CDN. CDNs will aggressively cache your website files. Once you combine CSS and JS files after activating CDN and something goes wrong, the cached files can cause problems. The CDN can continue to show a broken site even though you reverted the changes you made.
Use lightweight themes and plugins that have small CSS files. That will ensure that even when you are combining them, they don’t cause a lot of issues.
If you can identify which particular CSS and JS files cause problems upon combining, you can exclude them and combine the rest.
Combining CSS and JS files may or may not improve your site speed. Just try things before activating CDN.
Defer Loading of CSS Files and JS Files [Issue of Render-Blocking Files]
In case you are not aware, CSS files are meant to be render-blocking. If you don’t apply CSS properly, what you will experience is called Flash of Unstyled Content or Flash of Unstyled Text. This is what it looks like:
That itself is a broken page. You don’t want that to happen. Your page design should render properly. What more? Flash of Unstyled Content (FOUC) can lead to CLS. Usually, FOUC stays for only a fraction of a section or until you refresh the page or clear the browser cache. When that happens, the layout anyway shifts and that can lead to CLS.
Similar is the problem with deferring JS files. Certain JS files are needed for proper functioning of the website and they need to load before other things. A JS file can be responsible for allowing a user to interact with a webpage. Preventing the JS file from loading earlier will break that function.
In short, there are certain CSS and JS files that are ‘critical.’ Yes, they must load first even if they are render-blocking. You may not always be able to eliminate the issue of render-blocking.
However, not all CSS and JS files are critical. They can be safely deferred, that is, made to load last. This is where you need to find out which ones are critical and which ones aren’t. Once you find that out, you can exclude those files from deferred loading and let them load early.
Identifying them might not be so easy. You may need expert help. One easy way to deal with this is to reach out to the theme and/or plugin developers and ask them directly. Alternatively, you can ask a developer to figure this out for you.
I usually don’t recommend deferring CSS or JS files, but you can always experiment.
Generating Critical CSS and Inlining It with HTML
Some cache plugins will ask you to generate critical CSS and inline it with HTML. You should never do this, especially when you are using page builders that already have very bloated CSS files. In fact, you shouldn’t be using page builders in the first place.
Now, what really is critical CSS? It is the CSS that is required to load the part of the webpage that is called “above the fold”. When you generate critical CSS, it will break the CSS file into two parts and load the part that is needed for loading “above the fold” part of the webpage. The second part loads gradually.
The question is why do you want to make it more complex when your page builder already has extremely complex CSS files?
Moreover, when you inline the generated critical CSS with HTML, every time a user’s browser downloads your website, it has to keep redownloading the critical CSS files. This means that even if the browser keeps or stores static CSS files, it will make no difference. The critical CSS has to be downloaded, eventually slowing down your website.
Defer Off-Screen Images
A particular webpage on your website may have multiple images. Some will be “above the fold”, while others will be “below the fold”. Above the fold essentially refers to part of the webpage that shows up on the viewport of the user when it first loads. If the “above the fold” part of your webpage has images, they should load quickly.
But if there are images in “below the fold” part of your webpage, they don’t need to load immediately. They can load when the user starts scrolling. This is where lazy loading comes in handy. But lazy loading can cause CLS or cumulative layout shift.
The best way to deal with this problem is to use a very low-quality image placeholder (best if the image placeholder is in SVG format). A very low-quality image placeholder can load almost instantly irrespective of the position of the image and eliminate the CLS issue. The actual image can load shortly after that. This can help to speed up your website. LiteSpeed Cache has this function available. You need to just enable it.
DNS Prefetch
There will be several third-party resources on your website. For instance, you will have Google Analytics code. That is a third-party script and everytime a user’s browser requests your website, it also requests the Google Analytics from Google’s server. That request performs a DNS lookup.
Loading the external domains do take some time. So, the ideal thing to do here is to preload the domain. It simply resolves a domain before the resources from those domains are requested. If the domains are already prefetched, the browser doesn’t have to wait for the DSN to resolve. It will almost instantly request and receive the resources, thereby decreasing the webpage load time and increasing its speed.
LiteSpeed Cache can do this for you! It can prefetch DNS. You need to let the plugin know the URLs of those external resources on your website or webpage. Even Perfmatters plugin can do that for you.
To find those external sources, you can open your website in Chrome and right-click on it and then click on Inspect. From there, click on the Sources tab. You can see the list of all external URL.
Make a note of the URLs and place them in the required field of the plugin you are using for this. If you know how to do this my coding, just add the prefetch code in the header of your site.
Here is what you need to add:
<link rel=”dns-prefetch” href=”//cdn.domain.com”>
<link rel=”dns-prefetch” href=”//fonts.googleapis.com”>
<link rel=”dns-prefetch” href=”//www.google-analytics.com”>
<link rel=”dns-prefetch” href=”//www.googletagmanager.com”>
[Note: the CDN URL must be the actual CDN URL you are using]
Replace GIFs with Videos
If you are using large GIF files for animated content, you should consider using MPEG4 or WebM videos instead, because GIF files are not only inefficient in delivering animated content properly, but are also pretty heavy files, and can slow down your website.
Some Crucial Suggestion for You
If you are using WordPress, you need to know that it is a beast! It needs a lot processing power and hence, never ignore the importance of a good hosting company. But apart from that:
- Never use a page builder. They are extremely bloated with CSS files and they WILL slow down your website.
- Always use a very lightweight theme. GeneratePress (Premium) is a good option. It is extremely lightweight and brilliantly coded.
- You should use only those plugins that you need. Don’t use too many plugins. They will make your website a sloth.
- Try to use a server that has LiteSpeed or OpenLiteSpeed web server. Use LiteSpeed Cache along with it! LiteSpeed offers the most cutting-edge technologies that can help you to achieve incredible speeds without compromising functionalities.
- Do not use too many ads per page. That’s going to slow down your website terribly. If you can (that is, your website traffic permits), settle for a reputed ad network like Mediavine that uses lazy loading ads.
- Avoid using contact forms embedded in your website. Try using third-party services like Google forms and just provide a link to those forms on your website. Using a contact form on your site will require you to use another plugin called WP SMTP. You don’t really need an extra plugin.
- Do not use too many images per post. That’s going to slow down your website a lot.
A Word on AMP
Core Web Vitals are going to become the de facto criteria for appearing in Google Top Stories.
Previously, you needed to have AMP or Accelerated Mobile Pages for appearing on top stories. It is now going away. It will no longer be a requirement to appear in Google Top Stories. However, you will still have to qualify for regular Google News inclusion by meeting the regular requirements.
But once the Core Web Vitals role out properly, you need to meet a certain threshold of Core Web Vitals to be featured in top stories segment.
So, if someone is suggesting that you focus on AMP, you need to question that person’s credibility.
Do Not Run for a Perfect 100
Keep in mind – YOU CANNOT EASILY SCORE A PERFECT 100 on PageSpeed Insights. The reason is fairly simple. When you use third party codes and scripts like Google Analytics, AdSense, etc. there will be a drop in website speed.
There are many factors that can lead to a drop in page load speed. Eliminating each and everything is not possible. Google never tells you that you have to score a perfect 100. Yes, it is desirable to have a score of 90 to 100 for both mobile and desktop. However, for mobile, even a speed of 60 to 90 is quite fine depending on the type of website you have. On a desktop, the speed, I believe, should be at least 80 to 90, and preferably more than 90.
I am not saying that scoring 100 is not possible. Yes, you can score it on desktop. On mobiles, you can reach 99 as well! It is all about how well you are optimizing things.
Here is a screenshot of my website’s results:
The image above is of mobile test results. The image below shows the results for desktop:
As I said, achieving 100 on Google PageSpeed Insights is a possibility. On mobile, you can always stay above 90 with proper optimization.
Conclusion
Okay, I have given long lectures and even gave screenshots of my website’s performance. There is still a lot of work left. There are certain inner pages with poor performance. I need to fix them.
But how do you think I achieved these results? I did whatever I suggested you to do! I use DigitalOcean cloud hosting, I use only 8 plugins and GeneratePress theme, and I use LiteSpeed Cache on OpenLiteSpeed web server. Yes, there is Cloudflare as well.
You want to know what plugins I use? Well, here is the list:
- Broken Link Checker.
- Cloudflare.
- Code Snippets.
- GeneratePress Premium (yes, it is a plugin that gives the free GeneratePress theme its full power.
- LiteSpeed Cache.
- Mediavine Control Panel (by the ad network I use).
- Redirection.
- Yoast SEO.
I don’t have embedded contact forms. I use Google forms and give simple links to them on my site’s sidebar.
You can see the end result!
You see, using the right set of tools in the right combination allowed me to achieve such great results, and helped me to eliminate most of the warnings that PageSpeed Insights used to give me previously. I am not a developer. I don’t know coding. I just rely on the information I find through Google search.
It took me months to figure out the issues, and there’s an enormous amount of work still left. You can achieve this too.
Remember, at the end of the day, you need a functional website that serves the purpose. People aren’t really after fancy looking websites that use bloated codes. The mantra is, keep it simple! When you do that, you should easily score a near perfect score on Google PageSpeed Insights.
A perfect 100 is often elusive. Don’t run after a perfect 100. Strive to make it better and better. You may, one fine day, stumble on that magic figure!
