How to Fix Google PageSpeed Core Web Vitals: LCP, INP & CLS

If Google PageSpeed Insights says your website has poor Core Web Vitals, don’t start by installing five more optimization plugins. Start by finding out which metric is failing and why.

The three Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google currently recommends an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, evaluated at the 75th percentile of page visits.

That distinction matters because a website can have a PageSpeed score of 95 and still have a real Core Web Vitals problem—or have a lower laboratory score while real users are experiencing acceptable performance.

I have learned this the practical way from working with websites. Website speed problems are rarely solved by one magic setting. A slow hero image, an overloaded page builder, unnecessary JavaScript, poor hosting, badly configured caching, third-party scripts or a layout that jumps while loading can all create different problems.

So in this guide, I want to show you how I approach Core Web Vitals as a web designer: measure first, identify the bottleneck, fix the cause, test again, and then monitor the real users.

---

First: Don’t Confuse Your PageSpeed Score With Core Web Vitals

This is probably the first thing I would change if I were helping a beginner troubleshoot a website.

When you run a URL through Google PageSpeed Insights, you will see a performance score, diagnostics, opportunities and several different metrics.

It is tempting to look at the big number at the top and think:

“I need to get this from 62 to 90.”

That’s not necessarily the right goal.

PageSpeed Insights uses Lighthouse for controlled laboratory testing, while its field section can provide real-user experience data from the Chrome User Experience Report (CrUX) when enough data is available. Google specifically recommends looking at Core Web Vitals as real-world user experience metrics.

Think of it this way:

What you’re looking at	What it tells you
PageSpeed performance score	A Lighthouse assessment under a particular test environment
LCP	How quickly the main content becomes visible
INP	How responsive the page is to user interactions
CLS	How stable the page remains visually
Field data	What real users are experiencing
Lab data	What a controlled test is detecting
Search Console CWV report	How groups of URLs are performing in Google’s field data

This is why I don’t recommend blindly optimizing every red or orange item in a PageSpeed report.

Find the bottleneck first.

---

What Are the Three Core Web Vitals?

Before fixing anything, you need to know what you’re actually fixing.

1. LCP — Largest Contentful Paint

LCP measures how long it takes for the largest visible piece of content in the initial viewport to render.

That might be:

• A large hero image
• A featured image
• A large heading
• A video poster image
• A substantial block of text

Google recommends an LCP of 2.5 seconds or less for good performance at the 75th percentile. Anything above 4 seconds is considered poor.

Common causes of poor LCP

• Slow server response
• Poor hosting
• Large hero images
• Render-blocking CSS
• Too much JavaScript
• Incorrect image loading priority
• Web fonts delaying text rendering
• Redirect chains
• Heavy page builders
• Third-party scripts
• Poor caching configuration

Here’s something beginners often miss:

The biggest image on your page isn’t automatically the problem.

The browser has to go through a chain of events before that element appears.

A simplified version looks like this:

Request → Server response → HTML → CSS/JavaScript → Resource discovery → Resource download → Rendering → LCP

If the server takes 1.5 seconds before delivering the HTML, compressing your hero image from 500 KB to 300 KB may help—but it won’t solve the entire problem.

That’s why LCP troubleshooting has to look at the entire loading path. Google’s own LCP guidance recommends examining the different stages of the loading process rather than expecting one isolated fix to solve everything.

---

2. INP — Interaction to Next Paint

INP measures how quickly your page responds when a visitor interacts with it.

Think about actions such as:

• Clicking a navigation menu
• Opening an accordion
• Selecting a product option
• Typing into a search field
• Opening a popup
• Adding something to a cart
• Clicking a button
• Expanding a mobile menu

Google recommends an INP of 200 milliseconds or less for a good user experience.

A page can therefore load quickly and still feel slow.

Imagine this:

The homepage appears in two seconds.

Excellent.

You tap the hamburger menu.

Nothing happens for almost a second.

You tap again.

Still nothing.

That is a responsiveness problem.

And it is exactly why I don’t treat “website speed” as only a loading-time problem.

Common causes of poor INP

• Too much JavaScript
• Long-running JavaScript tasks
• Heavy page-builder scripts
• Excessive third-party scripts
• Complicated animations
• Large DOM structures
• Plugins loading scripts everywhere
• Poorly written event handlers
• Excessive main-thread work

Google’s guidance on INP emphasizes reducing the amount of work the browser has to perform during interactions.

---

3. CLS — Cumulative Layout Shift

CLS measures how much visible content unexpectedly moves around while the page loads or during the visitor’s experience.

You’ve probably experienced this yourself.

You are about to click a button.

Suddenly an image loads.

The page moves.

Your finger lands somewhere else.

You click the wrong thing.

That is the kind of experience CLS is designed to measure.

Google recommends a CLS of 0.1 or less.

Common causes of CLS

• Images without defined dimensions
• Ads loading without reserved space
• Embedded videos
• Web fonts changing the appearance of text
• Dynamic content
• Cookie banners
• Popups
• Late-loading elements
• Poorly configured sliders
• Content injected above existing content

Google specifically identifies images without dimensions, ads, embeds and dynamically injected content as common causes of layout shifts.

---

Core Web Vitals at a Glance

Metric	Measures	Good target	Common problem
LCP	Loading performance	≤ 2.5s	Slow hero/content
INP	Responsiveness	≤ 200ms	Heavy JavaScript
CLS	Visual stability	≤ 0.1	Content jumping
TTFB	Server response	Lower is better	Hosting/server delays

Remember that TTFB is not one of the three Core Web Vitals, but it can strongly influence how quickly the page begins its journey toward LCP.

---

My Core Web Vitals Troubleshooting Order

If I were handed a WordPress website with poor Core Web Vitals today, I would not start randomly changing settings.

I would work through the problem in this order:

Step 1: Establish the baseline

Run the page through PageSpeed Insights.

Record:

• Mobile results
• Desktop results
• LCP
• INP
• CLS
• TTFB
• Largest element
• Diagnostics
• Opportunities
• Field data, if available

Don’t change anything yet.

Take a screenshot of the original report.

This gives you something to compare against later.

Step 2: Identify the failing metric

Ask:

Is LCP failing?

Then investigate loading.

Is INP failing?

Investigate JavaScript and interaction responsiveness.

Is CLS failing?

Investigate layout movement.

This sounds obvious, but it saves enormous amounts of wasted time.

---

Step 3: Check Field Data Before Chasing Lab Data

This is one of the most important lessons in Core Web Vitals troubleshooting.

Suppose your Lighthouse test says:

LCP: 3.2 seconds

But your field data shows that real users are generally experiencing good LCP.

Don’t immediately rebuild the website.

Conversely, suppose your Lighthouse test looks excellent but Search Console shows a significant number of URLs with poor real-user Core Web Vitals.

That deserves attention.

Google’s documentation explains that Core Web Vitals are intended to represent real-world user experience, and its Search Console report can help site owners identify pages with problems.

Why can the numbers differ?

Because laboratory and field testing are measuring different things.

Your own computer may have:

• Fast broadband
• Powerful hardware
• Cached resources
• A modern browser
• Low network latency

Your visitor may be using:

• A budget Android phone
• Mobile data
• A congested network
• An older processor
• A different browser
• A different geographic location

This is especially important if your audience includes visitors from regions where mobile devices and mobile networks vary considerably.

A website that feels extremely fast to you in Lagos or New York isn’t necessarily going to feel identical to someone visiting through a slower mobile connection elsewhere.

---

Step 4: Fix LCP Before Obsessing Over the Score

If LCP is your problem, start with the largest visible element.

Open PageSpeed Insights and look at the LCP element.

Ask:

What exactly is being identified as the LCP element?

If it is a hero image, investigate that image.

If it is a large heading, investigate font loading, CSS and rendering.

If it is a background image, investigate how the background is being loaded.

This is much more useful than simply reading:

“Improve image delivery.”

You need to know which image.

---

How to Fix a Slow LCP Image

Suppose your homepage has a hero image measuring 2,400 × 1,600 pixels.

But the actual display area on a mobile phone is only approximately 390 pixels wide.

You don’t need to send a huge original image to every phone.

The browser should receive an appropriately sized image.

Example calculation

Imagine the original image is:

2,400 × 1,600 = 3.84 million pixels

A mobile version might be:

780 × 520 = 405,600 pixels

That’s roughly:

3,840,000 ÷ 405,600 ≈ 9.47

The original contains almost 9.5 times as many pixels.

That doesn’t automatically mean the file will be 9.5 times larger, because compression and image content affect file size. But it demonstrates why blindly uploading giant images is wasteful.

Better approach

Use:

• Correct image dimensions
• WebP or AVIF where appropriate
• Compression
• Responsive image delivery
• Proper caching
• Appropriate loading priority

And be careful with lazy loading.

A common mistake is lazy-loading an image that is actually the primary above-the-fold LCP element.

The browser may then wait unnecessarily to discover and load the image.

Google’s performance documentation also notes that resource priority can be important for LCP, including the use of fetch priority for important resources.

---

Don’t Lazy-Load Everything

This deserves its own warning.

Lazy loading is useful.

But “lazy-load all images” is not a complete performance strategy.

If an image is below the fold, lazy loading may make sense.

If the image is the main visual element that visitors see immediately, delaying it can work against you.

So I use this simple rule:

Below-the-fold content can usually wait. Critical above-the-fold content should not unnecessarily wait.

---

Fixing Slow Server Response and TTFB

Sometimes the problem isn’t your image.

The server itself is taking too long to respond.

Think about a restaurant.

You don’t have a problem with the chef’s cooking time if nobody has even taken your order yet.

Website performance works similarly.

If the browser is waiting too long for the first response, everything behind it is delayed.

Possible causes include:

• Slow hosting
• Poor server configuration
• Heavy database queries
• Lack of caching
• Excessive plugins
• Poorly optimized WordPress configuration
• High server load
• Inefficient themes
• External API requests

If you repeatedly optimize images but LCP remains poor, investigate the server.

This is one reason I always recommend reading a broader guide such as How to Speed Up Your WordPress Website alongside this checklist. It covers hosting, caching, plugins, images, CDN use and other WordPress performance factors.

---

How to Fix Poor INP

If LCP is about getting the page visible, INP is about making the page respond properly after the visitor starts using it.

The first place I look is JavaScript.

Ask these questions:

• How many scripts are loading?
• Which plugins are loading JavaScript?
• Are scripts being loaded on pages where they’re unnecessary?
• Are third-party scripts running?
• Is the page builder generating excessive code?
• Are animations consuming unnecessary resources?
• Are analytics, chat widgets, social feeds or advertising scripts contributing to the workload?

You don’t necessarily need to remove every script.

You need to determine which scripts are actually necessary.

---

A Practical WordPress Example

Imagine you have a small business website with:

• A page builder
• Contact form plugin
• SEO plugin
• Security plugin
• Analytics
• Facebook Pixel
• Google Tag Manager
• Live chat
• Social media feed
• Slider
• Popup plugin
• Animation library

Individually, each may seem reasonable.

Together, they can create a much heavier page.

This is why I don’t ask:

“Which plugin is bad?”

I ask:

“What is this plugin adding to this page, and does the visitor actually need it?”

That question produces better decisions.

---

Don’t Delete Plugins Just Because PageSpeed Mentions JavaScript

Another common mistake is deleting things blindly.

A plugin may contribute JavaScript but still perform an important business function.

For example, removing your contact form may improve a laboratory metric while destroying your ability to receive customer enquiries.

Performance optimization has to consider the purpose of the website.

A business website exists to generate business.

A church website needs its visitors to find information easily.

An online store needs customers to browse and purchase.

A blog needs readers to access and consume content.

A performance improvement that destroys functionality isn’t a successful optimization.

---

How to Fix CLS: Stop Your Website From Jumping

CLS is often one of the easiest Core Web Vitals problems to understand once you see it happening.

Images

Always make sure the browser can reserve the correct space for images.

Google recommends specifying image dimensions or using an appropriate aspect ratio so the browser knows how much space the image requires.

Videos and embeds

The same principle applies to:

• YouTube videos
• Google Maps
• social media embeds
• advertisements
• iframes

Reserve space before the content arrives.

Ads

Ads deserve special attention because advertising systems may load dynamically.

If an ad suddenly appears above an article and pushes everything downward, it can create layout instability.

Instead of allowing the page to collapse and expand unpredictably, reserve an appropriate area for the ad.

This becomes particularly important for publishers who want to combine advertising revenue with a good user experience.

---

Fonts Can Also Cause Layout Problems

Fonts are easy to overlook.

Suppose your page initially displays text using a fallback system font.

Then your custom web font arrives.

The text changes dimensions.

The page moves.

That movement can contribute to CLS.

When troubleshooting layout shifts, don’t only inspect images.

Also inspect:

• Web fonts
• Font-display behavior
• Navigation
• Buttons
• Headings
• Cookie notices
• Popups
• Dynamic widgets

---

What About Elementor and Other Page Builders?

Page builders can make website development much easier.

I use visual builders because they allow designers and website owners to create and maintain pages without writing every line of HTML and CSS manually.

But convenience has a trade-off.

A page builder can also make it very easy to create:

• Too many sections
• Nested containers
• Heavy animations
• Multiple widgets
• Unnecessary sliders
• Excessive spacing
• Decorative effects
• Additional scripts

The solution isn’t necessarily:

“Never use a page builder.”

Instead:

Use the page builder deliberately.

If a simple heading can do the job, don’t turn it into an animated sequence involving several widgets.

If a static image can communicate the message, don’t automatically use a video background.

If three sections can communicate the offer, don’t build fifteen.

Good design isn’t about how many effects you can add.

It’s about how effectively the page communicates.

---

My 10-Point WordPress Core Web Vitals Checklist

When troubleshooting a WordPress website, work through these areas.

1. Hosting

Check whether the hosting environment is appropriate for your traffic and website complexity.

2. Caching

Make sure page and browser caching are configured appropriately.

3. Images

Resize, compress and serve images in appropriate formats.

4. Above-the-fold content

Prioritize the content users need to see immediately.

5. JavaScript

Reduce unnecessary JavaScript and delay non-critical scripts where appropriate.

6. CSS

Remove or reduce unnecessary CSS and avoid blocking the rendering path unnecessarily.

7. Plugins

Remove plugins that are genuinely unnecessary.

Do not remove useful plugins simply because they appear in a performance report.

8. Page builder output

Reduce unnecessary widgets, animations and complex layouts.

9. Third-party scripts

Review:

• Analytics
• Advertising
• Chat
• Social media widgets
• Tracking pixels
• Embedded services

10. Continuous monitoring

Don’t optimize once and forget about the website.

Updates can change performance.

A new plugin can introduce JavaScript.

A new advertising configuration can affect CLS.

A redesign can change LCP.

A new image can increase page weight.

A website is not a static object.

---

A Simple Priority System for Fixing Performance

When there are 20 warnings in PageSpeed Insights, don’t panic.

I recommend categorizing them.

Priority	What to fix	Why
🔴 High	Failed Core Web Vital	Direct user-experience problem
🔴 High	Slow server response	Can delay everything
🔴 High	Huge LCP resource	Direct loading bottleneck
🟠 Medium	Excess JavaScript	Can affect responsiveness
🟠 Medium	Layout shifts	Damages visual stability
🟡 Medium	Large below-fold images	Helps overall efficiency
🟢 Lower	Minor Lighthouse warnings	Fix after major bottlenecks
🟢 Lower	Perfecting score from 95 to 100	Usually less important than real UX

This is where many website owners waste time.

They spend two hours trying to move a score from 96 to 100 while ignoring a major real-user problem.

---

Why a 100/100 PageSpeed Score Shouldn’t Become an Obsession

Here’s the uncomfortable truth:

A perfect PageSpeed score is not the purpose of your website.

Your website exists to serve people.

For a business, that means generating enquiries or sales.

For an author, it may mean selling books or building an email list.

For a church, it may mean helping visitors find service information, sermons and contact details.

For a publisher, it may mean helping readers discover resources.

If removing an important function gives you a perfect laboratory score but makes the website harder to use, you have optimized the wrong thing.

Google itself recommends good Core Web Vitals because they represent important aspects of user experience—not because every website must achieve an arbitrary perfect Lighthouse score.

---

How to Test Your Website Properly

Here’s the process I recommend.

Test 1: PageSpeed Insights

Run the URL through PageSpeed Insights.

Check both:

• Mobile
• Desktop

Start with mobile because that’s where performance limitations are often more visible.

---

Test 2: Search Console

If your website has enough real-user data, check the Core Web Vitals report in Google Search Console.

Look for:

• Poor URLs
• URLs needing improvement
• Good URLs
• Patterns affecting groups of pages

This is especially useful when you have dozens or hundreds of pages.

If ten pages use the same template and all have similar problems, you probably have a template-level problem, not ten separate problems.

---

The Template-Level Problem Most Beginners Miss

Imagine you have 100 blog posts.

You notice 70 of them have poor LCP.

Don’t optimize 70 articles individually.

Ask:

What do these pages have in common?

Perhaps they all use:

• The same theme
• The same sidebar
• The same featured-image template
• The same advertisement placement
• The same font
• The same header
• The same page builder template

Fixing the template can improve dozens of URLs at once.

That’s much more efficient.

---

Don’t Forget Mobile

A website can look beautiful on a desktop monitor and still provide a poor experience on a phone.

When I test a website, I pay attention to:

• Font size
• Navigation
• Tap targets
• Image size
• Popups
• Sticky headers
• Mobile menus
• Horizontal scrolling
• Content width
• Loading speed

For a business website, mobile optimization is not optional.

Someone searching for your business on a phone may be doing it while standing in a shop, sitting in traffic, waiting for a service, or comparing you with another business.

They aren’t interested in admiring your desktop design.

They want the information quickly.

If you’re still building or preparing a new website, my Website Launch Checklist includes performance, mobile testing, SEO, security and other checks that should be completed before launch.

---

A Nigerian Website Example

Let’s make this practical.

Suppose you operate a Lagos-based business website.

Your homepage contains:

• A large hero photograph
• WhatsApp button
• Google Maps
• Instagram feed
• YouTube video
• Contact form
• Animated counters
• Testimonial slider
• Popup
• Facebook Pixel
• Google Analytics
• Several fonts
• Five large images

On a fast laptop connected to a good broadband connection, the website may feel acceptable.

But imagine your customer is using a mid-range Android phone over mobile data.

Now the browser has more work:

1. Download HTML.
2. Download CSS.
3. Download JavaScript.
4. Download fonts.
5. Download hero image.
6. Initialize tracking.
7. Load social content.
8. Load maps.
9. Load widgets.
10. Execute scripts.
11. Render the page.
12. Respond to the visitor’s interaction.

The website may technically be “working.”

But working isn’t the same as being fast.

Sometimes the best optimization is not a technical trick.

It is simply asking:

Does this element need to be here?

That question has saved me more performance headaches than adding another optimization setting.

---

Calculate the Cost of a Heavy Page

Let’s use a simple example.

Suppose your page requires approximately:

• HTML: 100 KB
• CSS: 250 KB
• JavaScript: 800 KB
• Images: 2,500 KB
• Fonts: 300 KB
• Other resources: 350 KB

Total:

100 + 250 + 800 + 2,500 + 300 + 350 = 4,300 KB

That’s approximately 4.3 MB of resources before considering all the nuances of transfer compression and caching.

Now imagine reducing:

• Images from 2,500 KB → 900 KB
• JavaScript from 800 KB → 500 KB
• Fonts from 300 KB → 150 KB

New total:

100 + 250 + 500 + 900 + 150 + 350 = 2,250 KB

You have reduced the approximate resource weight by:

4,300 − 2,250 = 2,050 KB

That’s roughly a 48% reduction.

The exact performance improvement will depend on network conditions, caching, device speed, server response and how those resources affect rendering.

But the lesson is clear:

Performance optimization is often about reducing unnecessary work.

---

Should You Use a CDN?

A Content Delivery Network can help deliver static resources from infrastructure closer to users.

This can be useful when your visitors are geographically distributed.

For example, if your business is based in Nigeria but you receive substantial traffic from the United States, United Kingdom and other regions, your delivery architecture matters.

But don’t install a CDN simply because someone told you:

“Every website needs a CDN.”

First understand your audience, hosting setup and bottleneck.

A CDN can help.

It cannot magically repair:

• A terrible database query
• An enormous image
• Poor JavaScript
• A badly designed page
• A broken plugin
• A layout that keeps shifting

---

What About Caching Plugins?

Caching is one of the most useful performance techniques for WordPress.

But caching plugins are configuration tools, not magic buttons.

Depending on your setup, caching can help with:

• Page caching
• Browser caching
• CSS/JS optimization
• Image optimization
• Lazy loading
• CDN integration
• Database cleanup

The problem occurs when someone activates every optimization option at once.

You may then discover:

• Broken menus
• Missing styles
• Incorrect layouts
• JavaScript errors
• Forms that stop working
• Mobile navigation problems

My recommendation is simple:

Change one major optimization at a time.

Then test.

If something breaks, you know what caused it.

---

Don’t Optimize a Live Website Without a Backup

This sounds basic, but it matters.

Before changing:

• Theme files
• JavaScript
• CSS
• Caching configuration
• Optimization settings
• Database settings
• Plugins

Create a backup.

If you’re maintaining a WordPress website regularly, my guide on How to Maintain a Website explains why backups, updates, security, speed monitoring and routine maintenance should be treated as ongoing work rather than something you do once.

---

The Core Web Vitals Mistakes I Would Avoid

Mistake 1: Chasing the score instead of the problem

A score is a diagnostic signal.

It isn’t your business objective.

Mistake 2: Optimizing only desktop

Always test mobile.

Mistake 3: Lazy-loading the LCP element

Don’t automatically delay the content that should appear immediately.

Mistake 4: Installing too many optimization plugins

Multiple plugins can overlap and conflict.

Mistake 5: Removing functionality blindly

Performance should support your website’s purpose.

Mistake 6: Ignoring field data

Real users matter.

Mistake 7: Fixing individual pages instead of templates

If the same problem affects dozens of pages, find the shared cause.

Mistake 8: Forgetting CLS after adding ads

Reserve space for dynamic content.

Mistake 9: Ignoring JavaScript

A website can load quickly and still respond slowly.

Mistake 10: Never testing after changes

Optimization is iterative.

Measure → change → test → compare → monitor.

---

Your Practical Core Web Vitals Checklist

Before you consider the job finished, work through this list.

Measurement

• Run PageSpeed Insights
• Test mobile
• Test desktop
• Record LCP
• Record INP
• Record CLS
• Check field data
• Check Search Console

LCP

• Identify the actual LCP element
• Optimize the LCP image if applicable
• Check server response
• Review render-blocking resources
• Review font loading
• Review image priority
• Remove unnecessary above-the-fold content

INP

• Review JavaScript
• Remove unnecessary scripts
• Check third-party scripts
• Review page-builder widgets
• Reduce excessive animations
• Test menus and buttons
• Test forms and interactive elements

CLS

• Define image dimensions
• Reserve space for ads
• Reserve space for embeds
• Check fonts
• Check popups
• Check cookie banners
• Test dynamic content

WordPress

• Review hosting
• Configure caching
• Optimize images
• Review plugins
• Review theme
• Review page builder
• Check CDN configuration if appropriate
• Back up before major changes

Final test

• Run PageSpeed Insights again
• Compare against your baseline
• Test the actual website manually
• Test on mobile
• Check important forms
• Check menus
• Check buttons
• Check checkout/contact functionality
• Monitor Search Console over time

---

How Long Does It Take to Fix Core Web Vitals?

There isn’t one universal answer.

A simple website with a huge image might be fixed in an hour.

A complex WordPress site with:

• Heavy plugins
• A page builder
• Poor hosting
• Multiple third-party scripts
• Advertising
• Custom functionality
• Large media files

may require considerably more investigation.

The important thing is not to promise:

“I’ll make your website score 100 in 30 minutes.”

A responsible performance audit should first identify the cause.

Some problems are easy.

Others require architectural changes.

---

What If Your Website Still Fails After Optimization?

This is where you need to step back.

Ask whether the problem is caused by:

Hosting

The server may simply be too slow for the website.

Theme

The theme may be generating unnecessary resources.

Plugin architecture

A plugin may load functionality site-wide when it is only needed on one page.

Page builder

The page may contain too much unnecessary markup and JavaScript.

Third-party services

External scripts may be slowing down rendering or interactions.

Website design

The page may simply contain too much content above the fold.

Advertising

Ads and other dynamic elements may be affecting CLS.

Real-user conditions

Your laboratory environment may not represent your actual audience.

When the same problems keep returning after optimization, don’t keep applying patches forever.

Sometimes the correct answer is to rebuild part of the website.

---

Core Web Vitals and SEO: What Should You Actually Expect?

Core Web Vitals matter because they are part of Google’s broader page-experience considerations, and Google recommends achieving good Core Web Vitals for Search and user experience. But they are not a substitute for relevance, useful content, authority, search intent and other SEO fundamentals.

In other words:

A fast useless website is still useless.

And:

A useful website with terrible performance is making life unnecessarily difficult for its visitors.

You need both.

That is why performance should sit alongside the other foundations of technical and on-page SEO. If you’re working on the wider SEO side of your website, you can also use our SEO for Beginners guide to strengthen keyword targeting, internal linking, technical SEO and content structure.

---

My Recommended Workflow for Any Website

If you want one process to remember from this entire article, use this:

1. Measure

Don’t guess.

2. Identify

Find the failing metric.

3. Locate

Find the actual element, script, resource or template causing the problem.

4. Prioritize

Fix the highest-impact problem first.

5. Change

Make one meaningful change.

6. Test

Run the page again.

7. Verify functionality

Make sure the website still works.

8. Compare

Did the metric actually improve?

9. Check field data

Don’t stop at the laboratory report.

10. Monitor

Performance can regress after future updates.

That’s the difference between performance optimization and simply pressing buttons inside a caching plugin.

---

Don’t Build a Fast Website Nobody Wants to Use

I have come to see website performance differently over time.

When you’re starting out as a designer, it is easy to become fascinated by appearance.

You want the beautiful hero section.

The animation.

The slider.

The video.

The fancy fonts.

The floating button.

The popup.

The effects.

And there is nothing inherently wrong with beautiful design.

The problem starts when every design decision comes at the expense of the person trying to use the website.

A visitor doesn’t care how clever your implementation was.

They care that the page opens.

They care that the headline appears.

They care that the menu responds when they tap it.

They care that the page doesn’t jump while they’re reading.

They care that the contact button works.

They care that they can find what they came for.

That is ultimately what Core Web Vitals are helping us measure.

So the next time PageSpeed Insights gives you a disappointing score, don’t panic and don’t immediately install another optimization plugin.

Find the bottleneck.

Fix the cause.

Test again.

Then check what real users are experiencing.

A genuinely fast website isn’t one that merely produces an impressive number in a testing tool.

It is a website that feels fast, responds quickly, remains stable and helps the visitor accomplish what they came to do.

And that is the standard I would aim for.

---

Need Help Improving Your Website?

If you’ve run your website through PageSpeed Insights and you’re still dealing with poor Core Web Vitals, slow mobile performance, heavy WordPress pages or a website that looks good but doesn’t perform well, Creativity Publications can help.

We design and improve websites with attention to speed, mobile responsiveness, SEO, usability and conversion, rather than treating design and performance as separate problems.

If you’re building a new website, you can also learn more about website design costs for small businesses before deciding what level of website is right for your needs.

The goal isn’t simply to make your website score higher. The goal is to build a website that works better for the people you want to reach.

---

Frequently Asked Questions

What are Core Web Vitals?

Core Web Vitals are Google’s user-experience metrics covering loading performance, responsiveness and visual stability. The current metrics are LCP, INP and CLS.

What is a good LCP score?

Google recommends an LCP of 2.5 seconds or less at the 75th percentile for a good experience.

What is a good INP score?

A good INP is 200 milliseconds or less.

What is a good CLS score?

A good CLS score is 0.1 or less.

Why does PageSpeed Insights show different results on different tests?

Laboratory results can vary because the testing environment changes. Field data represents real-user experiences and can also differ by device, network and geographic conditions. Google recommends considering field data when evaluating Core Web Vitals.

Can a website have a high PageSpeed score and still fail Core Web Vitals?

Yes. The overall Lighthouse performance score and the field-based Core Web Vitals assessment are not the same thing.

Does improving Core Web Vitals guarantee higher Google rankings?

No. Core Web Vitals are part of Google’s broader page-experience considerations, but they are only one part of the overall search ecosystem. Relevance, helpful content, technical accessibility, authority and many other factors still matter.

Should I install a caching plugin to fix Core Web Vitals?

Caching can help, but it isn’t a universal solution. First identify whether your problem is caused by server response, images, JavaScript, CSS, layout shifts, plugins, third-party scripts or another bottleneck.

Why is my website fast on my computer but slow on my customer’s phone?

Your computer may have a faster processor, better connection and cached resources. Mobile visitors can have very different devices and network conditions. Always test mobile performance and, where available, examine real-user field data.