Speed shapes how people experience your website.
It also shapes how search engines judge your pages.
When a mobile page takes too long, people leave. Google’s own benchmark research notes that 53% of visits get abandoned if a mobile site takes longer than 3 seconds to load. (thinkwithgoogle.com)
Google also evaluates real user experience through Core Web Vitals.
These metrics feed into Google’s broader “page experience” signals and help you spot performance issues that hurt users at scale. (Google for Developers)
You already know speed matters.
You now need a clear plan to fix it, measure it, and keep it stable.
The three Core Web Vitals, in plain language
LCP: how fast your main content shows
LCP tracks how long it takes for the biggest visible piece of content to render.
Usually this is a hero image, banner, or main headline block.
Target:
- Good LCP: 2.5 seconds or less (75th percentile) (web.dev)
Why it matters:
- people decide fast if your page looks “ready”
- slow LCP makes your site feel broken, even when it is not
INP: how fast your site reacts to real interactions
INP measures responsiveness across the page lifecycle.
It looks at how quickly the page updates after a user action.
Target:
- Good INP: 200 ms or less (75th percentile) (web.dev)
Why it matters:
- slow interactions feel like lag
- lag kills form submissions, add-to-cart actions, and navigation
CLS: how stable your layout stays while loading
CLS tracks visual movement that happens when content shifts around.
Target:
- Good CLS: 0.1 or less (75th percentile) (web.dev)
Why it matters:
- people misclick
- forms become frustrating
- trust drops fast when the page jumps
PageSpeed Insights: what it does well, and how to use it correctly
PageSpeed Insights pulls in lab data and field data.
Field data comes from real users when enough data exists.
Google’s docs explain that PSI includes Core Web Vitals and can report at page or origin level. (Google for Developers)
Use PSI for:
- quick diagnosis
- high-level priority
- spotting repeated patterns across templates
Do not use PSI for:
- arguing over tiny score changes
- treating a score as a KPI
Your KPI is user outcomes:
- more leads
- more sales
- lower bounce on key pages
- better engagement on important content
The speed issues that hit South African sites hardest
South African businesses often see the same problems:
- heavy pages built for desktop, viewed on mobile
- image-heavy hero sections without optimisation
- too many third-party scripts (chat, trackers, widgets)
- shared hosting limits with no caching strategy
- plugin overload on WordPress sites
- slow Time to First Byte due to server setup and caching gaps
The fix is rarely “one thing”.
It is usually:
- a small set of high-impact changes
- applied across templates
- measured and maintained
A practical 7-step speed plan you can run
Step 1: Separate diagnosis from fixes
Run tests that give you different viewpoints:
- PageSpeed Insights for Core Web Vitals direction (Google for Developers)
- Lighthouse (in Chrome DevTools) for lab debugging
- Search Console Core Web Vitals report for grouped URL issues (Google Help)
What to do:
- pick 5 key templates (home, category, product/service, blog, contact)
- test 3 representative URLs per template
- list the repeated issues, not one-off warnings
Why it matters:
- template fixes scale
- one-off fixes waste time
Step 2: Fix LCP first on your money pages
LCP improvements usually come from:
- better images
- faster server responses
- fewer render-blocking resources
High-impact fixes:
- Convert large images to modern formats where possible
- WebP often helps
- AVIF can be smaller in some cases
- Compress hero images properly
- Serve correctly sized images for mobile
- Avoid loading a 2500px desktop banner on a 390px screen
- Preload your LCP resource if it is a hero image or key font
Why it matters:
- LCP sets the first impression
- first impression drives bounce behaviour
Step 3: Improve INP by cutting main-thread work
INP suffers when JavaScript blocks the browser.
Typical causes:
- massive JS bundles
- unused scripts
- heavy animation libraries
- tag manager clutter
- third-party widgets
High-impact fixes:
- remove scripts you do not need
- delay non-critical scripts until after user interaction
- split JS bundles (if you are on a modern framework)
- limit sliders, heavy carousels, and giant UI libraries
- reduce the number of tracking tags and load them smarter
Why it matters:
- users cannot complete actions
- paid traffic wastes budget when the page lags
Step 4: Stabilise CLS by locking layout space
CLS often comes from:
- images without width and height
- ad slots that load late
- banners injected above content
- web fonts that swap and shift the layout
High-impact fixes:
- set width and height for images and video embeds
- reserve space for dynamic content (ads, promo bars, cookie banners)
- keep popups from pushing content down
- manage font loading to reduce layout movement
Why it matters:
- stability affects usability
- usability affects conversion
Step 5: Fix caching and delivery before you change code
Many sites try to code their way out of hosting problems.
Do the basics first:
- enable full-page caching where appropriate
- enable browser caching for static assets
- use a CDN for images, CSS, JS, and fonts
- reduce server response time with proper caching rules
Why it matters:
- better delivery speeds up every page, not one page
- it reduces the load on your origin server
Step 6: Reduce bloat in themes, plugins, and page builders
This is a common issue on WordPress.
You often see:
- multiple plugins doing the same job
- heavy page builder output on every page
- unused CSS and JS loaded sitewide
High-impact fixes:
- remove unused plugins
- replace “do everything” plugins with lean alternatives
- only load scripts on pages that need them
- clean up old shortcodes and legacy widgets
Why it matters:
- every plugin adds risk and weight
- weight hurts speed and stability
Step 7: Maintain performance with a simple monthly routine
Speed work fails when it becomes a once-off project.
Run a monthly routine:
- check Search Console Core Web Vitals groups (Google Help)
- retest your top landing pages in PSI (Google for Developers)
- review third-party scripts and remove anything unused
- test forms and checkout flows on mid-range Android devices
- log performance changes after releases
Why it matters:
- sites get slower over time
- small regressions compound
Modern tech choices that can help, if they fit your stack
HTTP/3 and modern delivery
Many CDNs support HTTP/3 and QUIC.
This can reduce latency in some conditions.
It will not fix bloated pages.
Treat it as a delivery layer improvement, not a magic fix.
Frameworks like Next.js
Server-side rendering and static generation can reduce perceived load time.
It can also backfire if you ship large JS bundles.
If you choose a framework:
- enforce bundle limits
- keep third-party scripts lean
- test real-user performance, not only lab scores
Speed and conversion: what you should expect
Speed improvements often lift business outcomes.
The exact uplift depends on:
- your audience
- device mix
- page type
- checkout complexity
- traffic source
Cloudflare highlights examples where performance improvements correlated with conversion lifts for known brands. (Cloudflare)
What you should do:
- run an A/B test where possible
- improve one template
- measure conversion rate, form completion, and bounce on that template
- roll out changes across the site only after you see impact
Legacy practices to stop relying on
- AMP as a default speed plan
- You can hit strong CWV without AMP for most sites
- Plugin stacking as a substitute for engineering
- Chasing scores instead of fixing user friction
- Loading every tracking tool “just in case”
Useful tools you should keep in your workflow
- PageSpeed Insights for quick checks (Google for Developers)
- Search Console Core Web Vitals report for real-user grouped issues (Google Help)
- Chrome DevTools Lighthouse for debugging
- WebPageTest for waterfall analysis and filmstrip views
FAQ section
What are the Core Web Vitals in 2026?
They are LCP, INP, and CLS. INP replaced FID in March 2024. (Google for Developers)
What is a good LCP, INP, and CLS score?
Google’s guidance sets “good” thresholds at LCP 2.5s, INP 200ms, and CLS 0.1, measured at the 75th percentile. (web.dev)
Why does PageSpeed Insights show different results to Lighthouse?
PSI can include real-user field data when available, while Lighthouse is lab-based. PSI explains how CWV data is used and aggregated. (Google for Developers)
What is the fastest way to improve LCP?
Start with your hero media and server delivery: compress and resize images, use modern formats, improve caching, and reduce render-blocking resources.
How often should you run performance audits?
Quarterly is a solid baseline, plus after major releases. Search Console’s CWV report helps you track real-user changes over time. (Google Help)