How I Improved Google Core Web Vitals 122% and PageSpeed Scores 92%

How I Got Nerdy to Make Google Happy

Introduction

Speed matters. It makes the difference between winning and losing, life and death in warfare, sports, the animal kingdom (like my dog trying to catch the rabbits he was never able to), and especially with websites.

Here’s how I improved Core Web Vitals and the Google PageSpeed score for a legacy website that had over one million pages. True to my nerdiness, it was a lot of fun to dive under the hood to do this.

Optimizing websites for speed really lets you get into how sites are built and loaded. It’s very dev-centric, and even though I was confident in my technical SEO skills, there was a lot to learn to diagnose and communicate what needed doing.

Note: This isn’t meant to be a comprehensive guide on how to optimize sites for speed, but how I was able to do it for a uniquely built site.

Why Pagespeed and Core Web Vitals Matter

Slow sites cost businesses money and contribute to a poor user experience. For instance, Google found that low page load speed increases bounce rate by 123%.

Slow speed can lead to:

• Lower rankings
• Higher Bounce rates
• Lower conversion rates
• Lower revenues

This has Real-World Consequences:

• More than 50% of people will leave a page if it takes longer than three seconds to load. (Akami)
• Conversion rates drop an average of 4.42% with each additional second of load time. (Portent)
• The highest ecommerce conversion rates are for pages that load in 2 seconds or less. (Portent)
• 70% of people say page speed impacts their decision to buy from a site. (Unbounce)
• Walmart saw a 2%  increase in conversions with each second they improved load time. (Cloudflare)

What Are Core Web Vitals and Web Vitals?

Google introduced a new set of metrics called Web Vitals, and a subset of these metrics: the Core Web Vitals. There are three, which measure different aspects of how quickly and how well well pages load for users.

In 2021, Google rolled out the Page Experience Update, which incorporated page load speed and Core Web Vitals as major ranking factors.

Here’s a quick overview of these Google metrics.

Core Web Vitals

Largest Contentful Paint (LCP)

Largest Contentful Paint measures how long it takes for a page’s main content to load. A good score when a page loads in 2.5 seconds or less.

• Good: 0 – 2.5 sec
• Needs Improvement: 2.6 – 3.9
• Poor: 4+

First Input Delay (FID)

First Input Delay measures how long it takes for a page to become interactive. A good score is 100 milliseconds or less.

• Good: 0 – 100 ms
• Needs Improvement: 101 – 300
• Poor: 300+

Cumulative Layout Shift (CLS)

Cumulative Layout Shift measures the visual stability of a page. In other words, how well a page’s elements go into their “proper” place. If you’ve landed on a page and things keep jumping around, that’s because of poor CLS. A good score is .1 or less.

• Good: 0 – 0.1
• Needs Improvement: 0.2 – 0.25
• Poor: 0.25+

Web Vitals

First Contentful Paint (FCP)

First Contentful Paint measures the time it takes for any of a page’s content to become visible on the screen. A good score is 1.8 seconds or less.

• Good: 0 – 1.8 sec
• Needs Improvement: 1.9 – 3.0
• Poor: 3+

Total Blocking Time (TBT)

Total Blocking Time measures the time between the First Contentful Paint and the Time to Interactive where the main thread is blocked long enough to prevent responsiveness. Blocking occurs because of Long Tasks, which are main thread tasks running for more than 50 milliseconds.

TBT is considered good when blocking time is less than 50 milliseconds.

Time to Interactive (TTI)

Time to Interactive measures how long it takes for a page’s resources to become responsive to users.
A good TTI is 3.8 seconds or less. This is best measured in Lighthouse.

PageSpeed Score

If there’s an “overall” metric to measure a page’s speed performance, it’s Google’s PageSpeed Score. Scoring 90 or above is considered good.

• Good: 90+
• Needs Improvement: 50-89
• Poor: 0-50

The Situation I Faced

The site I was working on had been cobbled together over the years and had over one million pages. The homepage and editorial content were hosted in WordPress, while the product and category pages were based on AngularJS which was being replaced by React. These pages comprised about 99% of the overall site.

As is often the case with SEO, there was limited (i.e. no) direct access to the affected pages. To make things even more interesting, I had extremely few developer and engineering resources.

Another fun thing was that site’s servers were severely underpowered, meaning not only were the pages themselves slow to load, but they were slow to be served in the first place. This impacted more than just the CWV: it also negatively affected the crawl budget and indexation which wasn’t good at all for a site with so many pages.

Benchmarking – Atrocious Scores

Before starting, I measured the scores of the main product and category page templates, homepage, and other critical pages using several resources:

• Google’s Pagespeed API via Screaming Frog
• The Pagespeed web version for ad hoc measurements
• Google Search Console’s Core Web Vitals report

Here are some examples of what I found:

One of the better-performing pages had a Performance Score of 38:

Here are the results of testing another important page:

One page had a Time to Interactive of 11.2 seconds:

Another had a total blocking time of 3,660 milliseconds:

For both desktop and mobile, the results were sloooow. Like cold Molasses in January in Boston slow.

Me seeing how slow this site was

Causes of Slow Speed

How did it get so slow? There were several main reasons:

• Technical SEO had never been touched.
• The site was running on an old platform and code.
• Unused elements had never been removed.
• Like many sites, it just wasn’t built with speed in mind.

Plenty of Opportunities

Such poor results mean there were lots of opportunities to fix things.

Trim Excess API calls (like a ridiculous amount):

• The homepage had 4 Google Maps requests and 5 for Google Fonts.
• One main product page template had 25! Google Map API requests, and 6 for the live chat tool that was used.
• The other main product page template had 8 live chat requests. Who chats that much?

Estimated Time Savings: Google estimated (in milliseconds) there was a lot of time to be saved from fixing these issues:

• Eliminate render-blocking: 3,660 ms for one product page template and 6,780 ms for the homepage.
• Properly size images: 7,350 ms in savings for one product page template
• Defer offscreen images: 1,950 ms for a category page template.
• Remove unused CSS: 1,650 ms for a product page.
• Remove unused Javascript: 3,750 ms for a top category page, and 1,950 ms for a product page.
• Use next-gen image formats: a whopping 10,200 ms for a category page alone!
• Preload key requests: 1,530

Steps I Took

I took the speed crawl data and put it all into a speed roadmap, and assigned an ICE score to everything, based on:

• Potential time savings
• Potential file size savings
• My available resources to do it, eg developer time

Goals

My goal was straightforward: to get each page’s Speed Score of 90+ and improve Core Web Vitals so they get into the green.

Guiding Principles

The goal would be met by sticking to these guiding principles:
1. Minimize Page Weight, i.e. the quantity and size of file resources
2. Remove Unused and Unneeded Resources

Prioritizing My Work

I prioritized by page type and template:

• Homepage
• The three core product page templates
• Product categories

Note: There’s a lot of overlap when optimizing Web Vitals because what’s needed for one particular metric may also be needed for a different one.

1. Eliminated Render Blocking Resources

Render-blocking resources are code elements – often CSS and Javascript – that prevent a page from loading quickly because they take too long to process. Often, these resources are not crucial for the page’s immediate user experience, such as content or functionality.

Removing these eliminated the delay in displaying crucial content to users by improving the overall loading speed of the critical rendering path.

I asked my developer to reconfigure the loading process using a progressive approach by 1) separating and loading critical and non-critical resources, and 2) removing unneeded resources.

Eliminated Render Blocking CSS

1. A lot of unnecessary CSS was removed.
2. CSS that was needed (critical CSS) was then inlined directly in the HTML.
3. Non-critical CSS was loaded asynchronously.

Eliminated Render Blocking Javascript

1. Like the CSS, there was a lot of unused Javascript that was thrown away.
2. Key javascript requests (for above-the-fold) were then preloaded.
3. Non-critical Javascript like fonts, live chat, and Facebook scripts was given using <async> or <defer> attributes to load later.
4. Google Analytics was set to load in the background.
5. JQuery was moved to an external file and cached

2. Optimized Images

Images are one of the largest contributing factors to poor Core Web Vitals because they contribute so much to delays in page loading. Here’s what I did to optimize images:

• Images were reformated to WebP, Google’s preferred format.
• Lazy Loading was implemented.
• All images were resized and compressed using Imagify.
• Everything was cached and hosted with our CDN.
• CSS Imagery was used to combine images such as icons into a single file.
• A large autoplay video was converted into a gif.
• The Largest Contentful Paint image was preloaded.
• Image Meta Data was removed to reduce the size of image files
• Image width and height attributes were set.

3. Fixed Large Layout Shifts

Pagespeed Insights identified headers and breadcrumbs as the main causes of large layout shifts. This is an area I needed to rely on my developer more than other issues. Here’s what was done:

• Specified image width and height were set, as mentioned above. This is an example of overlapping between multiple Web Vitals.
• Stopped the placing of new content above existing content.
• Moved logos and site search lower on the page
• Used a placeholder to reserve the necessary space in the viewport for banner announcements.

4. Optimized Google Fonts

Font optimization is an often overlooked area that yields a lot of opportunities to improve performance. This was included in the CLS optimization sprint.

• Preloaded Fonts using WP Rocket for WordPress and rel=”preload” for the other pages.
• Limited the number of custom font variants (Google recommends 4-6 in total).
• Used only one font each for headings and one for paragraphs; a Javascript font loader was used.

5. Minified and Compressed Code

This was straightforward: HTML, CSS, and Javascript were minified and compressed.

6. Optimized Third-Party Resources

Google said to “minimize the impact of third-party resources”, so I:

• Preconnected to required origins: Added pre-connect resource hints for third-party widgets for things like chat boxes, social shares buttons, and GDPR notifications.
• Fixed multiple page redirects like resources loading as 301’s or (gasp) 302’s.
• Removing unneeded and unused code, some of which was done earlier:
  • Unused Plugins
  • Unnecessary API calls
  • Unnecessary Google Tags
  • Preloaded Third Party Javascript

7. Reduced the DOM Size

Earlier actions helped cut down on the size of the DOM, but there were specific things we could do to trim the size further.

• Since we were now using React, a windowing library was used to reduce the number of DOM nodes.
• Re-rendering was minimized by unchaining critical requests by cutting out unneeded resources, deferring, and using async (done earlier). The order of loading was also reconfigured to put all the critical assets first.
• The text was made to remain visible during font load by preloading all fonts during font optimization.

8. Minimized the Main Thread

The main thread was minimized by reducing the time spent evaluating scripts, and by minimizing style and layout calculations. This is another example of the overlap that occurs when optimizing for CWV, as this was accomplished in the CLS sprint.

9. Implemented Server Side Rendering

One of the most effective ways to speed up page load times is by eliminating the work of rendering pages from the users’ browsers, and the best option for this site was Server Side Rendering (SSR).

Server Side Rendering (SSR) is when a complete page is already visible on the server – and users upon loading – rather than being dependent on a browser to render.

There are pros and cons, however, there were advantages to this particular site.

• Better for SEO overall
• Improves speed and CWV
• Improved indexability because all of a page’s content is visible to search engines when crawling.
• Better user experience because all elements will render and not be affected if a user’s browser has issues.

Things to keep in mind:

• It takes dev resources to implement
• SSR can increase First Input Delay (FID), but eliminating long-running tasks takes care of this. Page elements such as buttons can also be delayed in being shown to users until the relevant content or full page loads.

I tested each page template to make sure all the content was loading using the URL Inspection Tool in Google Search Console URL Inspection Tool and the View Rendered Source plugin.

End Result – Improvements

After a lot of work identifying, fixing, and testing, the average PageSpeed performance scores for these critical pages increased by 92%.

Speed Scores: Before & After

Great Test Results

Here are the PageSpeed Tools test results for Product Page Template ‘A’:

Winning Core Web Vital Scores

The average scores for each Web Vital metric improved substantially for all important pages and were now in the green! Core Web Vitals improved an average of 122%!

• LCP: increased by 106%
• FID: increased by 88%
• CLS: increased by 158%
• FCP: increased by 102%
• TBT: increased by 156%

Increased Business Results

Increased performance metrics are great to see, but what about the bottom-line business results like conversion and revenue?

Well, they improved considerably:

• The conversion rate for the three product page templates increased by an amazing 25%!
• Revenue grew by 62%!

In sum, there are real-world benefits to speeding up a site’s pages by improving Core Web Vitals, both for users and the business. This was also a great chance for me to expand my web dev knowledge and really figure out what’s needed for top performance.

Do You Have a Slow Site? Let Me Help

If your site is experiencing slow PageSpeed scores and poor Core Web Vitals, you’re most likely leaving traffic – and money – on the table. Get in touch to talk about ways I can help speed up your site.

---

---

Let me know what you think