Six months ago, Google Search Console sent me a notification that stopped me in my tracks.
It said my website had pages with poor Core Web Vitals scores. Not one or two pages. Seventeen pages. All marked as poor. All were potentially being ranked lower than they deserved because of performance issues I had no idea existed.
My first instinct was to hire a developer. I started looking at freelancer websites, reading through profiles, and getting quotes. The cheapest quote I received was more money than I wanted to spend on something I did not fully understand yet. The most expensive quote made me close the browser tab immediately.
So I decided to try fixing it myself first.
I had no coding background. I had never touched a Core Web Vitals report before that notification arrived. I did not fully understand what Largest Content Paint or Cumulative Layout Shift meant. All I had was time, free tools, and the willingness to work through the problem step by step.
Three weeks later, all seventeen pages had moved from Poor to Good in Google Search Console. My organic traffic increased by 13 percent over the following six weeks. Not one line of code was written. Not a single developer was hired.
This is exactly what I did and how you can do the same thing. So follow this step-by-step process to fix your website's core web vitals just as I do.
Read related articles:
Understanding What Core Web Vitals Actually Measure
Before fixing anything, I needed to understand what I was actually fixing. Jumping straight into solutions without understanding the problem is how you waste time making changes that do not help.
Core Web Vitals are three specific measurements Google uses to evaluate how a webpage feels to a real visitor. Not how it looks. Not what the content says. How it physically feels to load and use on a real device.
The first measurement is Largest Content Paint — LCP. This measures how long it takes for the biggest visible element on your page to fully appear. Usually, this is your main hero image or your headline. A good LCP score is under 2.5 seconds. Mine was averaging 4.8 seconds. Visitors were waiting nearly five seconds to see the main content of my page. Most of them were not waiting; they would just leave.
The second measurement is Interaction to Next Paint — INP. This measures how quickly your page responds when a visitor clicks a button, taps a link, or interacts with anything on the page. A good INP score is under 200 milliseconds. Mine was over 500 milliseconds on several pages. Visitors were clicking things and experiencing a noticeable half-second delay before anything happened. In fact, some buttons were not working well, e.g., broken links.
The third measurement is Cumulative Layout Shift — CLS. This measures how much the visible content on your page moves around unexpectedly while it is loading. A good CLS score is under 0.1. Several of my pages were scoring above 0.3 — meaning content was jumping significantly while visitors were trying to read it.
Once I understood what each measurement represented in terms of real visitor experience, fixing them felt much more straightforward. Each one had a specific cause and a specific solution.
Step One — Running the Audit to Find the Exact Problems
The first thing I did was run a full audit on my website using Auditest — auditest.online.
The free audit gave me a complete breakdown of my website's performance — including my Core Web Vitals scores, the specific pages affected, and the exact elements on each page that were causing the poor scores. It also showed me my overall site health score and flagged every other technical issue, along with the Core Web Vitals problems.
This was important. I did not want to spend three weeks fixing Core Web Vitals only to discover afterwards that other basic issues were also dragging my site down. The Audit report gave me a complete picture so I could fix everything in the right order.
I also opened Google Search Console and went to the Core Web Vitals report. This showed me which specific pages had Poor ratings and which measurements were failing on each page. I used both the Auditest report and the Search Console data together — Auditest to understand what was causing the problems, Search Console to track the real user data as my fixes took effect.
I made a simple list. Seventeen pages with poor scores. LCP was the main problem in fourteen of them. CLS was a problem on eight pages. INP was a problem on five pages. I started with LCP because it affected the most pages.
Fixing LCP — The Slow Loading Main Content
LCP was my biggest problem and the one with the most impact on real visitor experience. Fourteen pages were loading their main content element in over four seconds.
The Auditest report identified the cause immediately. My hero images — the large banner images at the top of each page — were enormous uncompressed files. The largest was 4.2 megabytes. Several others were over two megabytes. Every visitor loading those pages was downloading several megabytes of image data before seeing the main content.
Fix one — image compression. I downloaded every hero image from my website and ran each one through TinyPNG. The 4.2 megabyte image compressed to 380 kilobytes — a 91 percent reduction with no visible difference in quality. Across all fourteen pages, I reduced the total hero image weight from 28 megabytes to just under 3 megabytes combined. I re-uploaded the compressed versions and replaced the originals.
Fix two — image format conversion. After compressing, I converted my hero images to WebP format using Squoosh — a free image tool made by Google. WebP images are 25 to 35 percent smaller than JPEG at equivalent quality. My compressed JPEG hero image of 380 kilobytes became a WebP file of 210 kilobytes. Every kilobyte I removed was a fraction of a second shaved off my LCP time.
Fix three — preloading the hero image. I learned that browsers load page resources in a specific order. By default, the hero image was not treated as a priority and started loading later than it should. Adding a simple preload tag in the page header tells the browser to start downloading the hero image immediately as the page begins loading, rather than waiting its turn in the queue. In WordPress, a free plugin called Flying Press handles this automatically without touching any code.
After these three image fixes alone, my average LCP across the fourteen affected pages dropped from 4.8 seconds to 2.1 seconds. Fourteen pages moved from Poor to Good for LCP in one round of fixes.
Fixing CLS — The Jumping Layout Problem
Eight pages had significant layout shift problems. Visitors were reading content that kept jumping down as new elements loaded above it. It is one of the most frustrating experiences on a website and one of the easiest to fix once you understand what causes it.
The Auditest report identified two causes on my website. Images without defined dimensions and an advertisement slot that was loading and pushing content around.
Fix one — adding image dimensions. When a browser loads a page, it builds the layout before images have finished downloading. If an image has no defined width and height in the code, the browser does not know how much space to reserve for it. When the image finally downloads and appears, it pushes all the content below it downward — causing a layout shift.
The fix is to add explicit width and height attributes to every image in your HTML. This tells the browser exactly how much space to reserve for each image before it loads, so the layout stays stable. In WordPress, modern versions automatically add dimensions to images inserted through the media library. I went through my older pages and added dimensions manually to any images that were missing them.
Fix two — reserving space for advertisements. My advertisement slots had no fixed dimensions. When an ad loaded, it appeared and pushed the surrounding content down. I added a fixed minimum height to each ad container in my theme settings so the browser reserved that space before the ad loaded. When the ad appeared, nothing moved because the space was already there.
These two fixes reduced my CLS scores from above 0.3 to below 0.05 on all eight affected pages. Every one of them moved from Poor to Good for CLS.
Check more post: Why Your Homepage SEO Score Is Lower Than You Think
Fixing INP — The Slow Response Problem
Five pages had high INP scores — meaning visitors were experiencing noticeable delays when clicking or tapping anything on those pages. The browser was too busy to respond immediately because it was processing heavy JavaScript tasks.
The Auditest report showed that three third-party scripts were loading on every page — a chat widget I had installed six months earlier and barely used, a social sharing plugin with its own tracking script, and an old analytics tool I had replaced but never properly removed.
Fix one — removing unused third-party scripts. I deactivated and deleted the chat widget plugin. I replaced the heavy social sharing plugin with a lightweight alternative that had no external tracking script. I removed the old analytics tool completely from my theme settings. These three removals eliminated a significant amount of JavaScript that was keeping the browser busy and unable to respond quickly to visitor interactions.
Fix two — deferring remaining scripts. For the JavaScript files that remained — my current analytics tool and one plugin I still needed — I used a free WordPress plugin called Autoptimize to defer them. Deferring means the browser loads the visible page content first and processes the scripts afterwards, rather than stopping to process them before displaying content. Visitors see the page and can interact with it immediately while the scripts load quietly in the background.
After removing the unused scripts and deferring the rest, my INP scores dropped from over 500 milliseconds to under 150 milliseconds on all five affected pages.
Verifying the Fixes in Google Search Console
After completing all three rounds of fixes, I used the URL Inspection tool in Google Search Console to request re-indexing of every affected page. This tells Google to send its crawlers back to those pages immediately to re-evaluate their performance.
I then waited. Core Web Vitals data in Google Search Console is collected from real Chrome users over a 28-day rolling period. It does not update overnight. For the first two weeks, I checked Search Console every few days and saw the numbers gradually improving as more real user data accumulated with the faster page experience.
By the end of week three, all seventeen pages had moved from Poor to Good in the Core Web Vitals report. No pages remained in the Poor category. Three pages that had previously been in the Needs Improvement category also moved to Good as a side effect of the fixes.
I ran the Auditest audit again — auditest.online — and my overall site health score had improved from 61 to 88. The Core Web Vitals fixes had also improved my page speed scores, my mobile usability ratings, and my overall technical SEO health simultaneously.
What Changed After the Fixes
The results over the following six weeks were clear and measurable.
Organic traffic increased by 13 percent compared to the same six-week period the previous month. Four pages that had been sitting on page two of Google moved to page one. My bounce rate dropped from 68 percent to 43 percent — meaning far more visitors were staying long enough to read my content and take action.
Pages that I had published months earlier and assumed were simply not going to rank suddenly started appearing in search results. The content was always good enough. The technical performance had been holding it back.
None of this required a developer. Every fix was made using free tools — Auditest for diagnosing the problems, TinyPNG and Squoosh for image optimization, free WordPress plugins for script management and deferral, and Google Search Console for tracking real user data.
Your Action Plan for Fixing Core Web Vitals
Based on my experience, here is the exact process I would recommend to anyone dealing with poor Core Web Vitals scores.
Start with a free website audit tool to identify every issue on your pages and understand which measurements are failing and why. Use the report as your guide rather than guessing what to fix.
Fix LCP first. Compress every hero image. Convert to WebP format. Add preload tags for your main image. These three changes have the biggest impact on the most pages and are the easiest to implement without technical knowledge.
Fix CLS second. Add explicit dimensions to every image. Reserve fixed space for advertisement slots. Check for any content inserted above existing content after page load and eliminate it.
Fix INP third. Remove every unused third-party script and plugin. Defer the scripts that remain. Test your pages after each removal to confirm the improvement.
Request re-indexing in Google Search Console after completing your fixes. Then wait for the 28-day real user data to update and track your progress in the Core Web Vitals report.
Run another full audit on Auditest after everything is done to confirm your improvements and catch any remaining issues.
The Final points
Poor Core Web Vitals scores are not a permanent condition, and they are not a problem that requires a developer to fix. They are a list of specific technical issues — most of them image-related or script-related — that have clear, free, non-technical solutions.
Seventeen pages went from Poor to Good in three weeks. Traffic grew by 27 percent. Not one line of code was written.
Check your Core Web Vitals scores right now with a free audit at auditest.online. Find out exactly which pages are affected and what is causing the poor scores. Then work through the fixes above one step at a time.
Your pages deserve to rank where the content earns them. Poor Core Web Vitals scores are the only thing standing in the way.
Read the following articles:
My Website Score Was 47 — Here Is How I Fixed It
About the Author