Affiliate Link Disclaimer
This post contains affiliate links that will provide us with a commission - at no additional cost to you - upon completing a purchase.
We use affiliate revenue to provide discounts to small businesses with tighter budget restrictions.
Please consider using the links to help support small businesses.
We Were On A Mission To Achieve The Impossible
The Hunt For The Unicorn – A Perfect 100!
One does not just accidentally stumble upon a perfect score of 100 in PageSpeed Insights.
It takes serious dedication and commitment to make it happen!
Now, we have seen other blog posts that claimed to score a 100 in PageSpeed Insights and they may have for older versions of it.
Of course, often the test site is a bare WordPress install that has no third-party plugins, no third-party theme, and is no where near a real world website.
Running those same sites through PageSpeed Insights often shows scores pretty far from that perfect 100.
We will give WP Rocket credit though, because their website scores a 100 in PageSpeed Insights for Desktop.
In fact, you can see that their website was specifically tuned to get a better performance score.
We have tested many performance optimization solutions and none of them ever produced a 100 in PageSpeed Insights.
To be fair to WP Rocket, we have not specifically tested their plugin, but it is definitely something we intend on doing.
We created our own optimization solution because we knew we just would not see a perfect score any other way.
Before you can attempt to pull a perfect score of 100 in PageSpeed Insights, you have to understand the scoring metrics of Google PSI.
The performance score is generated based on the Lab Data, which consists of 6 separate metrics.
First Contentful Paint
How Long To Start Rendering!
First Contentful Paint makes up 15% of the PageSpeed Insights score within Lighthouse 6.
This metric can be a bit confusing because we used to focus on the time to first byte.
You want the First Contentful Paint to be very low, because that is the moment when the browser begins rendering your website.
The longer the time to First Contentful Paint, the longer your website will take to fully render within the browser.
Optimizing for First Contentful Paint is fairly straight forward and is what most optimization solutions implement.
Lazying loading images has become much easier with the “lazyload” attribute for img and picture elements.
Server response time is also a huge deal, which can be improved with a better server environment or implementing page cache.
It is recommended to keep the First Contentful Paint below 2 seconds, but should be below 1.5 seconds for best results.
Time That Contents Are Rendered!
Speed Index makes up 15% of the PageSpeed Insights score within Lighthouse 6.
Speed Index measures how quickly content is visually displayed during page load. The more content you have, the longer it will take to render.
The timing is generated based on video captured which computes the visual progression between frames.
The score for Speed Index is a comparison of your website’s timing compared to timings of other websites.
Currently, the recommendation is to keep the speed index below 4.3 seconds. However, that is still a really long time.
The lower the Speed Index, the faster the website is rendered within the browser.
Optimizing for Speed Index is a bit more complicated because you have to remove any repaints.
A repaint can occur when web fonts are either render blocking or loaded in and the text has to be rendered again using the loaded font.
Largest Contentful Paint
Timing For Rendering The Largest Content!
Largest Contentful Paint makes up 25% of the PageSpeed Insights score within Lighthouse 6.
This is one of the largest aspects of your overall performance score.
Largest Contentful Paint is the timing for when… well… the largest content is painted within the viewport.
Most of the time, this will be an image or a video. Sometimes this can be text found within the hero section of your website.
If you have any shifts or changes to the content, the timing will be updated to the last paint for the content.
Most often, this is higher because of a late loading web font, JS code that causes a repaint, or an image that takes a bit longer to load.
To be considered fast, the Largest Contentful Paint cannot exceed 2 seconds.
Optimizing the Largest Contentful Paint will focus on <img>, <image> inside <svg>, <video>, background images loaded with url(), and any block-level elements (<section>, <div>, <p>, …ect).
You want to avoid having any images or videos above the fold, because they can produce a very long time for Largest Contentful Paint.
If you decide to use background images, we recommend using a gradient and then lazy loading the background image.
Time To Interactive
When Your Website Becomes Interactive!
Time To Interactive makes up 15% of the PageSpeed Insights score within Lighthouse 6.
This is probably one of the hardest metrics to optimize for, because it was specifically created to catch when websites optimized content visibility at the expense of interactivity.
Time To Interactive measures how long it takes before a page is fully interactive, which is when the page displays useful content, event handlers are registered, and the page responds to user interactions within 50 milliseconds.
To be considered fast, the Time To Interactive needs to be less than 3.8 seconds. To be able to get a 100 in PageSpeed Insights, it needs to be considerably lower.
We include analytics, social media, chat systems, and even use JS to turn a browser into a server.
Front-end libraries like Angular and React can make a website appear to load faster, but simply defer rendering until later.
While it can keep a visitor on your page, browsers are eating far more memory than ever before – which can be very bad for mobile traffic.
Total Blocking Time
How Much Time Is Spent Being Blocked!
Total Blocking Time makes up 25% of the PageSpeed Insights score within Lighthouse 6.
Total Blocking Time measures the total amount of time that a page is blocked from responding to user input.
That user input includes mouse clicks, screen taps, and keyboard presses.
The total is calculated by adding up the blocking portion of all long tasks between First Contentful Paint and Time to Interactive.
Tasks that take longer than 50ms is considered a long task and the amount of time after 50ms is considered the blocking portion.
In order to be considered fast, your website needs to have a Total Blocking Time of 300ms or less.
With Total Blocking Time making up such a large percentage of the score, there really is not a margin for error.
Cumulative Layout Shift
Amount Of Shift In The Viewport!
Cumulative Layout Shift makes up 5% of the PageSpeed Insights score within Lighthouse 6.
We believe this should make up far more than just 5% of the score, because nothing is more annoying than getting ready to click and the content shifting.
It becomes super annoying when you are trying to read a blog post and scrolling causes something to load and you lose your place.
Imagine if the Like button just happened to shift under your thumb while casually scrolling through a photo album.
Maybe that wouldn’t be such a bad thing, but it would be annoying.
Websites should strive to have a Cumulative Layout Shift of less than 0.1 – which is 10% of the viewport.
If you have a Cumulative Layout Shift of 0.25 (25% of the viewport), that is considered very bad.
Google PageSpeed Insights only measures shifts above the fold, but you should strive to keep all layout shifts to a minimum.
This is especially true in blog articles, because too many annoying shifts can cause your readership to decline.
Optimizing Cumulative Layout Shift involves ensuring image elements have defined sizes (heights and widths).
If you are inserting content above existing content, you should consider alternative methods of loading that content.
When animations are being used, you should consider using transform to produce the animation.
A Perfect 100 In PageSpeed Insights
According to Google, a good score (90 to 100) is recommended to provide a good user experience.
They also say that a “perfect” score of 100 is extremely challenging to achieve and not expected.
This is because they claim taking a score from 99 to 100 needs the same amount of metric improvement that would take a 90 to a 94.
In order to get a 100 in Desktop, the following are required.
First Contentful Paint cannot exceed 550ms.
Speed Index must be lower than 750ms.
Largest Contentful Paint cannot exceed 600ms.
Time To Interactive must be lower than 1,350ms (1.3 seconds).
Total Blocking Time cannot exceed 70ms.
Cumulative Layout Shift must be lower than 0.024 (4%).
When we look at these timings, we can understand why Google says that it is extremely challenging.
However, our Technical Director loves a challenge and decided we were going to conquer it!
Building An Optimization Solution
An absolute PITA!
The worst part about building an optimization solution is that third-party code varies so much in quality and craftsmanship.
In PHP that would throw a Fatal Error and prevent stop execution of the code. Not in JS, it is 100% valid!
Maybe this was by mistake, because programmers know the pain of omitting a semi-colon. It is probably one of the most common bugs we implement into the code base.
However, if PHP accepted it, we would never know. Maybe, it is not intentional and they really meant to end the line with a semi-colon.
To be honest, our optimization solution started out as an experiment to see if it was possible to automate the removal of Unused CSS.
Google loves to recommend removing Unused CSS, but we noticed it only has a major impact for Mobile page loads.
Desktops are considerably faster and do not see much of an impact when parsing and processing CSS that does not apply to the DOM.
However, we started building out own own HTML and CSS parsers, which lead to writing code for other optimizations.
Another issue that we ran into is that you cannot assume that third-party code will be written to standards.
We also wanted our solution to optimize websites in real-time, which is required for removing unused CSS.
You have to compare CSS against the actual HTML that will be sent out to the browser, which requires output buffering.
The problem with output buffering is that it prevents all HTML while output is being buffered.
This can increase the time to first byte and make websites appear to take longer to load.
You cannot take longer to optimize a website than the savings you would generated with optimized content.
So, we decided to separate the optimization logic from WordPress altogether and developed our solution to live outside of WordPress.
Instead of using the database, settings are stored in .json files and the solution focuses exclusively on the HTML captured with output buffering.
This was a very smart decision, because our optimization solution will be able to be used with any PHP-based website.
We built a separate WordPress plugin to handle integration of our solution with WordPress.
By separating the optimization logic, we were free to choose exactly how our optimizations were going to be implemented.
This allowed us to make decisions that would drastically improve the performance of processing the optimization efforts.
Due to the issues with not being able to rely on third-party code to be written to the same standards, we disabled a few advanced optimizations by default.
Even with those optimizations disabled, the solution was still able to pull a 100 in PageSpeed Insights for Desktop.
Included In Our Performance Optimization Service
Lifetime License to Our Optimization Solution!
You might have noticed that we did not get into any specifics with regards to what work we did to achieve the 100 in PageSpeed Insights.
The reason for that is because it is a combination of many different efforts.
Our optimization solution was built to implement 3 of what we call the 4 Pillars of WordPress Speed Optimization.
However, it can only take a website so far and there are many efforts that need to be addressed with WordPress websites.
Nothing annoys us more than reading a blog article that makes a claim and then we follow the recommendations and do not see any of the results.
It took us hundreds of hours of building, researching, tuning, making adjustments, and fixing bugs.
That was on top of building our website with performance in mind from the very beginning.
We limit the use of animations and we do not insert images above the fold.
Since we are programmers, we do not need to use plugins to handle what we can do through PHP code.
The decisions we make are made based on what will help improve page load times – not what is faster or more cost effective.
Even with all of that, we are very confident that the solution will end up producing scores in the 90s for any WordPress website.
We have every intention on releasing the solution and licensing it similarly to how WordPress Plugins are licensed.
However, we still have a lot of work to do to ensure it covers every possible variation in WordPress websites.
So, we have shifted our service to fixate on the niche of WordPress Performance Optimization.
Every client who obtains our WordPress Performance Optimization service will receive a Lifetime License to the optimization solution.
We will also address every performance issue that plagues your website to ensure your page load times are low.
Our results are guaranteed to produce 90s in Google PSI or the service is FREE. We are that confident!
Absolute no down payment is required, simply let us create a clone of your website so that we can show you the results first.
If you are not happy with the results, you have no obligation to pay!
Our WordPress Performance Optimization service starts at $1,000.
If you want a faster loading WordPress website, we are standing by to help you achieve that goal!
Conclusion – Perfect 100 in PageSpeed Insights
Difficult? Yes! Impossible? No!
Unfortunately, we cannot guarantee that your WordPress website will see a 100 in PageSpeed Insights.
We will do everything in our power to get your website as close as possible, but optimization can become very pricey pretty quickly.
It is far easier to build a new website that comes with faster page load times than to optimize an existing website.
If a third-party plugin is responsible for sluggish page load times, replacing that plugin can take a long time.
More often than not, the theme is responsible as it can make a huge impact to performance for both the back-end and the front-end.
Page builders like Visual Composer are notoriously slow to process and generate the HTML that is sent to the browser.
Many themes can include an outrageous amount of CSS and JS which can extremely slow down page load times.
Even Divi, the theme that we use, contains a large amount of JS code – most of which we do not actually use.
Our WordPress Performance Optimization service is geared to resolve the largest impacts to page load times.
If scoring a perfect 100 in PageSpeed Insights does not sell you on that, there really isn’t much else we can say.
When you are looking for an expert team to handle WordPress Optimization, look no further!
We would love to hear from you and learn about the issues you are having. No obligation, we are just curious.