Last month, we announced Project Lightspeed, our code optimization project to improve the efficiency of Thrive Themes plugins, themes and software on your website.
We are doing this in response to Google's upcoming Core Web Vitals algorithm update, where they will include website user experience into their 200+ ranking factors for Google Search.
The very same day we announced Project Lightspeed, Google amended their timeline, now saying that Core Web Vitals will be a gradual rollout beginning in mid-June and ending in late-August.
In this article, we'll provide an update on:
- 1Our progress on Project Lightspeed
- 2A breakdown of each Core Web Vitals metric
- 3Examples of how our code optimization can improve those metrics
A Quick Summary:
At Thrive Themes, we keep our cards close to our chest for a number of reasons. We don’t have a public roadmap outlining our planned updates or ETAs. The easiest explanation for why is: "Plans can change."
However, this year we've made two exceptions.
First, we've announced in advance our 2021 plans for Thrive Apprentice, our online course plugin for WordPress.
Our initial plan was to release a public beta of Project Lightspeed earlier this month, but with Google's amended timeline, we are now going to include more advanced code optimizations in a single release early in June, before the algorithm update begins.
That release will include a simple migration tool, meaning optimizations will only take effect when you are ready to enable them and they can be disabled at any time with a click.
We will share tutorials on how it works when it’s ready.
"But… does it work?" Yes!
Core Web Vitals and code optimizations are far, far from easy work. This is arguably some of the most advanced work we've had to do.
But we know that all you really care about is: does it work?
So far, the answer is: yes.
We are seeing notable performance improvements when split testing pages where Project Lightspeed has been enabled vs. pages where it hasn't.
Towards the end of this article, I’ll share our testing scenario and show you the impact of Project Lightspeed (or click here to jump straight to the tests).
But all of that will mean nothing without a proper understanding of Core Web Vitals, what we are optimizing and why. So let’s dig into that first.
Understanding Core Web Vitals Metrics
The content of this article includes some images, animations and information provided by Google for developers and webmasters. If you'd like to dig deeper into this research, we recommend starting here: Google's Core Web Vitals.
There are 3 Core Web Vitals:
Google measures these 3 metrics and provides performance scoring benchmarks. How your site performs on these metrics will count as one of their 200+ algorithm ranking factors.
It’s important to remember that getting a great score is not going to magically make your website rank. But if you have a page that is already fighting for a specific spot on the search engine results page, improving your Core Web Vitals might give you an edge over your competition.
Core Web Vitals is not strictly about speed; It’s about website user experience. The tools you use to measure your website usability will report more than just the 3 Core Web Vitals, but it is only these 3 in the new algorithm update.
We’re actually pleased to see that Google is measuring worthwhile metrics.
Often a site owner curious about speed punches their URL into a speed measuring tool and makes the mistake of focusing only on ‘time to fully loaded’.
'Time to fully loaded' is arguably the least important metric for website usability, as it accounts for the loading of content that a visitor won’t even see until they engage with a page and scroll down to the end.
It’s like measuring a car’s top speed instead of acceleration. Are you really going to drive at 250kph? Acceleration is more likely to impact your everyday driving than top speed.
It's the same with websites.
Your website visitors won’t sit there with an open browser and a stopwatch, waiting for their browser to acknowledge it has downloaded all resources before they start read or interact with the page.
What really matters is how quickly content begins to appear and becomes usable while it is being downloaded after a visitor first arrives, and that can be measured by specific time milestones during page load.
That’s what Google is measuring, so hats off to them for focusing on the right metrics.
How Google Measures Core Web Vitals Data
Google has provided a free tool called Google Page Speed Insights. That's what we're using in our tests.
However, Page Speed Insights uses Field Data when available, not Lab Data, which can sometimes be problematic for testing. Other recommended testing tools are Google's web.dev/measure and webpagetest.org.
What is Field Data?
Field Data is collected by Google from their Google Chrome Browser, and only from users that have agreed to share such data. This means it is real-world data, reporting metrics back to Google that your site visitors have actually experienced.
It’s not a simulation- it’s from real humans.
If your website gets lots of visitors who are on a decade-old mobile phone with terrible internet connection, your metrics will be slower than another website that attracts desktop users on fast wifi internet connections.
The point is to optimize your website for the types of visitors that are coming to it.
The catch with Field Data is that it’s not always available. New websites or web pages with low traffic won’t have enough meaningful data for Google to use to assess usability of your websites.
Field data is generated as a 28-day trailing data set updated daily. That means if you make a big change to your website, the Chrome User Experience Report will take 28 days to gradually update and reflect the full changes in Google Page Speed Insights.
What is Lab Data?
Lab Data is not real world users. It’s a simulation of what your website’s user experience would be for a particular user + device + internet connection.
To calculate Lab Data, Google uses something called Google Lighthouse, an open source website benchmarking tool built right into the Google Chrome browser.
You can change the lab data test from desktop to mobile, and even pick a specific mobile device or internet speed.
Unlike Field Data, Lab Data is immediately available. You can test your site, make a change, and test again to see what difference it makes- no need to wait 28 days.
However arbitrary lab data tests will never truly represent real human interactions.
That's why Google Page Speed Insights will use Field Data if it’s available. If it isn’t, it will fall back to Lab Data.
Why is a website slower on mobile, according to Google?
We hear this question often.
"Why is my website slower on mobile?"
Technically, it isn't.
If Google doesn't have sufficient Field Data for your webpage, then their Page Speed Insights will default to Lab Data only.
And since Google is taking a wild guess at who your website visitor might be, they've settled on a specific device:
A 5-year old Motorola Moto G4 smart phone (released in 2016) with speed throttling to emulate the top 25% of fast 3G internet or the bottom 25% of slow 4G internet.
In fact, they even have a device emulator for the Moto G4 built right into the Dev Tools of Google Chrome:
But why are they benchmarking with a 5-year old Moto G4 on throttled internet?
Because it was considered 'average'.
The Moto G4 was a popular device that sold for $200 USD and sits around the average/middle of the spectrum between high performance phones and cheap over-the-counter phones.
It wasn't exceptionally fast or slow... for it's time. (There's talk of Google updating their benchmark device to a newer phone soon).
The choice to throttle internet speeds to the highest 25% of 3G internet is because faster 4G and 5G internet isn't as readily available world-wide, and wifi connections cannot be guaranteed.
So your website isn't slower. It's the same.
But the device that connects to your website and processes the data is slower. The goalposts have moved for the purpose of benchmarking fairly.
Google's benchmarks are more generic. Unfortunately, it also means the bar gets set frustratingly high so that websites consider the usability impact on users with slower devices too.
When a website gets enough proper field data from real users, then Google starts calculating your metrics based on the 75th percentile of your visitors, taking into account the actual devices and internet speed they connected with.
If your website attracts more desktop users on fast internet, your Core Web Vitals score will increase. But if your site attracts mobile users with 12-year-old devices on the slowest internet known to mankind, then your field data will make your scores plummet.
Now, let's look at each Core Web Vital in detail.
#1. LCP - Largest Contentful Paint
Largest Contentful Paint is a speed metric that measures how long it takes for the biggest visual object above-the-fold to be displayed during the first few seconds of a page visit.
It’s not everything above the fold, it’s only one single object.
For each web page, the object can be different, but it’s always either an image element, background image, video poster image, text element container or icon.
The term ‘contentful’ means it’s the part of the page that is considered the content that a visitor consumes. The border of a box or the font of a text element isn’t contentful- it has no meaning. Content is words they can read or an image that means something to your visitor.
Notice that LCP is a Core Web Vital, but officially FCP (First Contentful Paint) is not. Google aren’t interested in when the first object renders, but are measuring the one that contributes to the greatest percentage of the viewport, as that’s when visitors feel like the content they are expecting is now displaying.
For example, on this webpage, the LCP object is a content box with a background image:
If the size of that content box was reduced, then the LCP object would likely be the headline text instead and we'd see a reduction in the LCP time reported in Core Web Vitals.
But for the purpose of testing, we're using out-of-the-box templates without making any favorable edits to skew the numbers.
Optimizing for LCP means finding new ways to load the largest above-the-fold object faster.
#2. FID - First Input Delay
First Input Delay is the time it takes from when a visitor clicks on something on your page and then the appropriate action occurs.
An example would be clicking on a toggle element, a button or link, or clicking into a lead generation field to input an email address. It doesn’t include scrolling or zooming, since that is not considered interacting with the content of your page.
Unfortunately, First Input Delay can only be calculated from Field Data. This is why speed testing tools don’t report FID, but instead report the next closest metric, TBT - Total Blocking Time.
The reason FID can’t be measured with Lab Data is because it entirely depends on what a human user is trying to do on your website. It requires a human to click on your page content before it can calculate how long it takes for the page to react.
Each web page has a different purpose. Consider the difference between a login page on your website and a blog post or ultimate guide. On the login page, a user is going to quickly want to enter their username and password- meaning their first input starts sooner. But on a blog post, they’ll simply scroll down the page to read. They might not even trigger a first input at all.
Note that it measures first input delay. Not second or third. There are 2 reasons for this:
- 1The first input gives the user a strong impression of whether or not your site is going to be easy to use.
- 2The first input is more likely to be delayed, since it can occur while the browser is still downloading assets. Subsequent inputs will most likely be instant.
Because FID can’t be measured with lab data, the closest measure is Total Blocking Time. This is the combined total amount of time during page load that a user input would be blocked or delayed if they were to attempt an input.
At no point would a user be delayed by the entire TBT time, but by reducing TBT, you’ll inevitably reduce FID. However, only FID accounts for a real human interaction.
Optimizing for FID means trimming down the number of assets that load at the time a user intends to interact with your page.
#3. CLS - Cumulative Layout Shift
Have you ever loaded a website and seen elements jump and move around while they are loading? That is called layout shift, and it’s best understood with this clear animation from Google:
Unlike other metrics that can be measured in seconds or milliseconds, CLS is a score between 0 and 1. The lower the score, the better.
Google calculates CLS based on the amount of display area impacted by the shift (as a fraction of the total viewport space) multiplied by the greatest distance it moves (as a fraction of the total viewport height or width).
A layout shift only occurs when existing elements that are visible in the viewport change their start position. A change of element size or addition of new elements doesn't trigger CLS, unless they move the start position of another element within the viewport at the time.
According to Google's Web.Dev resources:
Unexpected movement of page content usually happens because resources are loaded asynchronously or DOM elements get dynamically added to the page above existing content. The culprit might be an image or video with unknown dimensions, a font that renders larger or smaller than its fallback, or a third-party ad or widget that dynamically resizes itself."
CLS is very subjective to what you are trying to do on your webpage and why. It's when it's unexpected for a visitor that it can be an issue, so loading spinners and reserving space on a page can help to keep everything in place.
How Project Lightspeed Can Help
But we saw that we could potentially improve all 3 Core Web Vitals if we moved to a modular approach.
Look at these opportunities Google mentions in their report.
Note that Google does call them 'suggestions' and clearly states, "They don't directly affect the performance score".
That's true. But by addressing them, we can nudge some of the Core Web Vitals which in turn affects the score.
The new modular approach to our code means our software has to look at the content of your pages built with Thrive tools, and compile unique CSS and JS files that only contain what’s necessary for that specific page.
On top of that, important CSS can be moved inline meaning it would be written right into your page source code rather than in a separate file to be downloaded, making for quicker access in the first milliseconds that a visitor arrives at your site.
Largest Contentful Paint should be improved because above-the-fold CSS is more readily available with fewer assets to download first.
Cumulative Layout Shift is not likely to be impacted much because it isn't a speed measure anyway. As you'll see soon, an untouched Thrive Architect landing page out-of-the-box gets great CLS scores even without any optimization.
The Impact of Project Lightspeed on Core Web Vitals
We created a test to confirm that we’re on the right track.
The goal of this test was to see the impact on Lab Data results of the 3 Core Web Vitals metrics between the same page with versus without our code optimization enabled.
For our test, we used a Thrive Architect landing page that everyone has access to: the Upsell page from the Hydrogen Smart landing page set.
We chose this one because it’s a medium-long page with a good balance of images, text, columns, a pricing table and a toggle element. It’s an example of a real-world page that you would see in the wild.
We made no changes to the page at all, simply testing how it works out-of-the-box.
We hosted two versions of the page on the same hosting server, a quality Cloudways host.
Hosting plays a huge part in website load times, so we wanted to test a replicable environment for a site with good hosting. This way we know hosting isn’t the bottleneck contributing to any speed issues, and it isolates our code optimizations.
For these tests, we did not enable caching, minification or a CDN (content delivery network). These are important additions that should be added to a website if you want to maximize your performance.
However, we are testing the raw changes only by enabling one new feature.
Here are the results:
Before - Project Lightspeed disabled:
After - with Project Lightspeed enabled:
Before - Project Lightspeed disabled:
After - with Project Lightspeed enabled:
Let’s interpret those results.
First, you'll notice that the Desktop Scores, even before Project Lightspeed was enabled, were very good, getting a 94 and then a 97 with optimizations enabled.
Hopefully that's not a surprise to you. The average desktop/ laptop computer has a fast processor and good wifi internet speed.
But since we know that Google has set the bar high with their Moto G4 mobile results on throttled internet, that becomes the challenge to improve.
On Mobile, we saw the score rise from 71 to 91 with these improvements on specific Core Web Vitals:
For a website with no caching and no CDN, that’s a good improvement at the click of a button. Of course there are more optimizations we could do (and we will), but we expect each one to create smaller and smaller improvements.
Project Lightspeed includes versioning, meaning that we can refine it and add more optimizations over time, without bringing any harm to your website.
We're confident you'll see an improvement, but how much an improvement will depend on many factors including your host, server configuration, page content, plugins and the device type your target audience uses.
No. When we release Project Lightspeed into the public version of our software, nothing will change until you are ready to enable it.
We always recommend that significant changes to a website are made in a testing or staging environment. Our code optimizations only affect the front-end that loads to your site visitors, and we will have a very easy toggle in the backend of your site that allows you to disable Project Lightspeed and default to our previous code behavior.
Yes. Project Lightspeed will include a migration tool, where you can simply click a button to optimize the Thrive code of your entire website and let it run. It will take a few minutes to prepare your new code. After the code is prepared, you can enable or disable it with a click.
Yes, however you may find different settings in your caching plugin will start to give better results than they did before. In some of our tests, we were surprised to see that caching and minification made a much smaller improvement than it did before our optimizations. Expect that you might need some trial and error to discover what new caching options work best for your setup.
No, not at all. You don't have to enable the Project Lightspeed settings at all and your website will continue exactly as it has been with Thrive Themes tools.
No. Where we can, we try to provide set-it-and-forget-it solutions, though a lean site also means you'll need to learn best practices for building fast pages. Project Lightspeed does include version control, which means we can add more optimizations with time and your website will know if/ when it's worth running a site-wide optimization again.
We’re optimistic that Project Lightspeed will make an improvement to your Core Web Vitals.
However, we must stress that our code optimization is only one piece of the puzzle. There are 3 things you can do right now:
- 1Use good hosting: Premium hosts are configured to deliver fast sites.
- 2Optimize your images: Serve compressed, resized images for quicker loading.
- 3Use Website Caching: Reduce server 'thinking time' by caching reusable assets.
Beyond that, there are also some recommendations we’re hoping to provide to help you grow your site following best practices that won’t cause issues.
For now, stay tuned.
In early June, we’ll publish a step-by-step guide on our blog showing you where and how to enable Project Lightspeed safely on your website.