Improve Your PageSpeed Score

Improve Your PageSpeed Score

In years past, PageSpeed score was calculated on what techniques were applied to a web page. While ultimately the motivation behind the legacy versions of PageSpeed was to improve page load time, it wasn’t until the release of PageSpeed v5 (and Lighthouse v3) that the PageSpeed metric became truly meaningful.

When PageSpeed Metrics Became Meaningful

It was early on Monday November 12th, 2019 that I received a very urgent set of emails from an early adopter of the Pegasaas Accelerator WP WordPress plugin. I had opted to sleep in an extra hour that day — it wasn’t like there was going to be anything pressing that I had to deal with on what was observed as a national day off in lieu of Remembrance Day which fell on the Sunday.

The subject of those emails was something along the lines of “PageSpeed is telling me that my scores of my pages dropped from 95/100 to 45/100 overnight!” and “This is urgent, what is going on!?”

As it turns out, Google had just released their updated PageSpeed Insights tool which was suddenly based off of the Lighthouse v3 tool. In this new version of Google PageSpeed Insights (GPSI), the “PageSpeed Score” was not derived not from arbitrary specific best practices that were applied to a web page, but rather from a calculation based upon the affected result of how your page loaded.

By that, I mean that your “score” now depended entirely on how the page load and render actually affected the user’s experience. How fast the page first displayed, fully loaded, and how interactive it was, was what the score was based on.

Based on Merit, not on Showing Up

You could have a page that had very little on it, that did not apply much in the way of best practices, but if it loaded and rendered faster than a page that had all the best practices applied, the faster page would score better.


I was thrilled to learn that Google had finally based its PageSpeed system off of the user experience.

Prior to this release, we were planning on building our own system of analyzing page load time, so that we could truly see what the improvements were that resulted from the Pegasaas Accelerator WP plugin being installed on a site.

So, I was so stoked to learn that the data being returned from the Google API was now including all of the data that I was planning on having to build out myself! It was a late birthday present to me!

Happy Birthday, Now Get To Work

Except, of course, there was that issue of the PageSpeed scores dropping like a stone overnight…

Three weeks later, I had built new capabilities into the Pegasaas system that had pages that were once scoring in the 90’s with GPSI v4, that then plummeted to 25/100, back up to 85/100. By the first week in December, we released Pegasaas Accelerator WP v2.0 which included all of the metrics that I had dreamed of including, and had pages loading even FASTER than they had just one month before.

And let me be clear, these scores that I speak of were the mobile PageSpeed scores. The “desktop” scores were now very easy to attain in the 90’s because desktop browsers were that much faster. But as over 60% of users globally are now using a mobile device to search Google, the “desktop” device has become a fairly insignificant metric to base your PageSpeed scores off of.

New Metrics in a New Interface

Included with the “PageSpeed Score” that is displayed in the interface are six new “metrics”: Time To First Byte, First Contentful Paint, First Meaningful Paint, Speed Index, Time To Interactive, and First CPU Idle.

Time To First Byte

The first, Time To First Byte (TTFB), is the only metric that the PageSpeed score is not directly calculated from. As it is something that the web performance community looks at, we felt we needed to include it.

Pegasaas Accelerator WP improves the Time To First Byte by employing caching of the web page. If your website runs on an Apache web server, we take it a step further by bypassing the WordPress system if a cached web page exists. The result is TTFB times of < 150ms.

First Contentful Paint

I’m not even sure “contentful” is a real word, at least my spell-checker says it isn’t. But essentially, this First Contentful Paint (FCP) is when the content is first painted to the web browser.

This particular metric is weighted as 3/5 for importance when the PageSpeed score is calculated, so pretty important. A fast First Contentful Paint is obtained by deferring all render blocking resources and injecting critical CSS into the page. By not requiring JavaScript or CSS to be loaded before rendering, you can achieve 1-2s render times for a mobile device.

The only thing that keeps the FCP from being low, if you’ve deferred all of your render blocking resources, and you’ve injected critical CSS into your page, is if your page has a lot of HTML elements (DOM nodes) and/or your critical CSS is very large. You need to understand, it takes time to apply all of the CSS rules appropriately to the web browser… even longer on a mobile device.

Of course, Pegasaas Accelerator WP has included deferral of render blocking resources, and automatic detection and injection of critical CSS since version 1.

First Meaningful Paint

Often, this metric is identical to the First Contentful Paint metric. If you have images or fonts that need to load in order to render the page, then this metric can be higher than the First Contentful Paint. Essentially, First Meaningful Paint (FMP) is when the primary content of the page is visible.

Another aspect of a delayed First Meaningful Paint is if the critical CSS is dramatically incomplete which would require the deferred stylesheets to fully load. This would also result in something called the Flash of Unstyled Content (FOUC) which is where you see the page in a jumbled form slowly build and become the page it was designed to be.

Since version Pegasaas Accelerator WP version 2, we have included the stripping of redundant Google Fonts for mobile which helps to reduce the FMP metric on those sites that include a lot of variations of a font. This stripping method uses the “middle of the road” method of removing the non-typical variations for mobile, so the first meaningful paint is as fast as possible.

This is the least important of the five metrics that are used to calculate the PageSpeed score for a web page. This means that it isn’t integral to keep the FMP to the same as the FCP time, however if your FMP is higher than 2.0s, it will begin impact the overall PageSpeed score to some small degree.

First CPU Idle

The second least impacting metric of the five, First CPU Idle (FCI) is when the CPU first becomes idle and is minimally interactive. Arguably, this is possibly one of the more difficult metrics to target as it can be affected by resources that are loading (JS/CSS/images/fonts) or JavaScript that is being parsed and executed.

Generally speaking, if you have any sort of JavaScript that animates sections of your page, you’re going to have a higher FCI metric.

Again, this is a fairly low impact metric, so you can get away with times that are around 3.5s. Ultimately, you don’t want to have the user wait more than 3 seconds for their mobile device to become interactive. If a user tries to scroll becomes the CPU is engaged on making a animation occur, that is a negative affect on the User Experience.

Our plugin offers Lazy Loading of JavaScript resources to help bring down the First CPU Idle metrics, since version 2.3 — if you don’t need it loaded until after a user scrolls, it should be lazy loaded (just like images!).

Time To Interactive

The Time To Interactive (TTI) metric measures how long it takes for the page to become fully interactive. This is basically the more fully observed version of First CPU Idle.

TTI can be difficult to keep low if you have a lot JavaScript and CSS. As Time To Interactive is the most important of the metrics that factor in to your PageSpeed score, every effort should be made to make the page interactive as soon as possible.

One of the methods that have often been used in the past to reduce the Time To Interactive is to combine resources such as JavaScript and CSS. This type of strategy is counter productive, however, as it ends up causing a higher First CPU Idle, and contributes to longer loads times for subsequent load times, as the combined CSS cannot be used on secondary pages.

In addition to it being counter productive for the reasons mentioned above, combining resources is not necessary for most modern web servers that support the HTTP2 that allows for multi-plexing. With multi-plexing, much of your CSS and JavaScript can be loaded in parallel. Combining only serves, for new web servers, to delay the page load.

With Pegasaas Accelerator, we provide the ability to Lazy Load CSS (Deferring Unused CSS) and JavaScript, and image files. These features affect not only the Time To Interactive, but also the Speed Index.

Speed Index

The Speed Index (SI) metric is similar to the “page fully loaded time” that is seen when using tools such as GT Metrix — it is essentially how long it takes the contents of a page to be visibly populated.

This metric is what most developers think of when they’re testing for “page load”. It used to be, before we deferred render blocking resources and injected critical CSS, that we targeted the “page load time” under 3 seconds to be considered a fast loading page. In truth, if your Speed Index is under 2.7 seconds, it is considered 100/100 for that particular metric.

In reality, with modern websites using 10, 20, 30, or more JavaScript files to render a page, it can be very difficult to achieve for a mobile visitor. However, if you know which files can be ‘lazy loaded’ until after the initial page load, then you can utilize the Lazy Loading of JavaScript power feature in Pegasaas Accelerator WP.

And, if the critical CSS snapshot is accurate, you can enable the “Defer Unused CSS” option in the plugin to shave even more time off of the page load.

Web Performance Optimization, Simplified

When I set out to develop the Pegasaas Accelerator WP plugin, it was fueled by my frustration that there were no plugins that put all of the pieces together. There were no plugins that “just did it all” that I could “set it and forget it”. Some would do part of the puzzle, but wouldn’t provide the metrics to show how well my pages were doing.

I was frustrated, because I felt I had to have a second job just monitoring the web performance of my site.

Which is why I built Pegasaas Accelerator WP. Personally, I needed my WordPress websites to load fast… and to load faster than my competition. And I needed whatever was going to do that for me to be simple to operate.

So there you are! Pegasaas Accelerator WP — give it a try and if you like it and feel it is worth a small monthly fee to include a global CDN, more monthly API optimizations, more image optimizations, etc etc etc…. then I’ll keep developing it to provide the most comprehensive automated PageSpeed optimization tool available.

Comments are closed.