A slow website fails at least one of three Core Web Vitals at the 75th percentile of real visits: LCP above 2.5 seconds, INP above 200 milliseconds, or CLS above 0.1 (web.dev, Google, 2024).
The causes sit in four places: server response, page weight, the render path and the platform. The first three can be fixed on the current site, while template and platform limits are what a redesign actually changes.
Lab tests cannot measure INP directly, according to web.dev, so field data in PageSpeed Insights or Search Console shows which cause is real before any budget goes to new design.
Which website speed numbers count as slow?
Google’s targets are an LCP within 2.5 seconds, an INP of 200 milliseconds or less, and a CLS of 0.1 or less.
A page passes only when all three hold at the 75th percentile of page loads, with mobile and desktop assessed separately. Miss one and the page fails the assessment.
The three targets
- LCP (loading): 2.5 seconds or less
- INP (responsiveness): 200 milliseconds or less
- CLS (visual stability): 0.1 or less
Values per web.dev (Google), as of its October 2024 update.
Failing is common. The HTTP Archive Web Almanac 2025 reports Core Web Vitals pass rates of 48% on mobile and 56% on desktop.
Where TTFB fits
TTFB is not a Core Web Vital, but it opens the load sequence, ahead of FCP and LCP.
| Rating | TTFB | First suspects |
|---|---|---|
| Good | 0.8 seconds or less | Nothing to fix by default |
| Needs improvement | 0.8 to 1.8 seconds | Redirects, caching |
| Poor | Above 1.8 seconds | Hosting, backend work, distance |
web.dev calls these bands a rough guide, not a strict requirement.
A server-rendered site can post a higher TTFB and still beat a fully client-rendered one on FCP and LCP, so read the number against how the page delivers its content.
How to measure website speed before touching anything
Start with field data to see what real visitors get, then switch to lab tools to find the cause. web.dev advises using field data to decide what to fix, and lab data for debugging and for testing before deployment.
PageSpeed Insights puts both on one screen. The field section comes from the Chrome User Experience Report (CrUX) at the 75th percentile, and the lab section comes from a Lighthouse run.
- Run the URL through PageSpeed Insights and read the field section first.
- Open the Core Web Vitals report in Google Search Console to see which groups of URLs fail.
- Run Lighthouse on the failing template for lab diagnostics.
- Open the WebPageTest waterfall or the Chrome DevTools Performance panel to find the slow request or the long task.
- Re-test after each fix, and let the field window catch up before judging it.
PageSpeed Insights reports the previous 28-day collection period, so a fix shows up in field data gradually, not the next morning.
Why lab and field results disagree
- Conditions: a lab run uses one device, one network and one location, while field data covers all of your visitors.
- Cache: lab tests usually load with a cold cache, while real visitors often have resources cached.
- INP: a lab test cannot predict when users interact, so Total Blocking Time stands in as a proxy.
Back/forward cache restores count in field data, and lab tests do not account for them.
When field data is missing
Low-traffic pages often have none. CrUX only includes pages that are publicly discoverable and have enough visitors for a statistically significant dataset.
PageSpeed Insights falls back to origin-level data when a page lacks samples, and shows no real-user data at all when the origin lacks them too. A real user monitoring script is the usual way to fill that gap, and web.dev names a RUM provider or CrUX as the field sources for finding slow interactions.
Slow server response, hosting and caching
When every page is slow, including a bare text page, the delay sits in server response: hosting, uncached responses, distance from the visitor or redirects before the page even starts.
TTFB adds up redirect time, service worker startup, DNS lookup, connection and TLS negotiation, and the request time until the first byte arrives.
| Cause | TTFB part affected | Fix |
|---|---|---|
| Shared or underpowered hosting | Request time | Better host or plan |
| Redirect chains | Redirect time | Remove same-origin 301 and 302 hops |
| Distance to origin | Connection and TLS | Serve from CDN edge |
| Uncached responses | Request time | Cache-Control headers |
Hosting and TTFB
Shared hosting is generally slower, and insufficient memory causes thrashing.
- Pick a host that keeps its backend stack updated and can handle your traffic
- Break down backend work with Server-Timing headers
- If TTFB stays long on dedicated hosting, re-evaluate the host
Lab tools often test the final URL and miss redirect delays, so confirm any hosting verdict against field data.
Caching, CDN and compression
Caching: Cache-Control headers let a CDN serve from edge servers, and even short cache times help busy sites because only the first visitor waits for the origin.
CDN: Edge servers cut the distance to the visitor, and CDNs such as Cloudflare often bring fast DNS, modern TLS, HTTP/2 or HTTP/3, and compression.
Compression: CDNs cache compressed static responses, while compressing dynamic markup on the fly on your own server can slow responses.
Caching has a limit. It can hide a slow backend, and personalized content should not be cached this way, so test with the cache bypassed before declaring the server fixed.
Redirects add time too: remove same-origin 301 and 302 hops, often caused by a missing https:// or inconsistent trailing slashes, and avoid chains of cross-origin redirects.
Images, fonts and other page weight
The median mobile home page weighed 2,559 KB in July 2025, and images accounted for 911 KB of that, according to the HTTP Archive Web Almanac 2025.
The chapter’s prose cites 2,362 KB in one place, but its charts show 2,559 KB, so the chart value is the safer benchmark.
Bytes are not scored directly. They matter because they delay LCP.
Images
Size: serve the dimensions the layout actually uses, through srcset and sizes. Re-encoding a 4000 px photo to AVIF still ships a 4000 px photo.
Format: WebP and AVIF may provide better compression than JPEG or PNG, and a picture element can fall back to legacy formats for browsers that lack support.
Lazy loading: use loading=”lazy” for standard below-the-fold images, and never on the LCP image.
Plenty of sites get this wrong. The LCP element is an image on 76% of mobile pages, and 17% of mobile pages lazy-load it (HTTP Archive Web Almanac 2025).
Chrome’s LCP discovery guidance, published October 2025, says to make the LCP image discoverable in the HTML, give it fetchpriority=high, and avoid lazy loading.
Fonts
Web fonts cost bytes and cause layout shifts.
- font-display: optional uses the web font only if it is ready at first layout
- Match fallback metrics with size-adjust and the override descriptors, and preload critical fonts
Video and autoplay media
A background video can outweigh the rest of the page combined.
Keep it only if it earns its bytes. A poster image costs a fraction of that.
JavaScript, third-party scripts and render-blocking resources
A page that downloads quickly but still feels slow usually has a main thread problem: JavaScript evaluation, render-blocking files or third-party tags.
Script evaluation, meaning parsing, compiling and executing JavaScript, creates long tasks that block responses to user input.
Render-blocking files
Lighthouse flags scripts in the head without a defer attribute, and stylesheets whose media attribute does not match the device, with media=”all” counting as blocking.
- Inline critical resources, defer non-critical ones, and remove anything unused
- Mark non-critical scripts with async or defer
- Use the Coverage tab in Chrome DevTools to find unused CSS and JS
Main thread work and INP
web.dev traces poor INP to 3 places.
Input delay: work already on the main thread, such as script loading, parsing and compiling, delays event handlers from starting.
Slow event callbacks: heavy work inside handlers stretches the interaction.
Presentation delay: large DOM sizes and large amounts of HTML rendered on the client make each update expensive.
The fixes are yielding to the main thread, keeping the DOM small, and using content-visibility to skip rendering offscreen elements.
Third-party scripts
About 90% of pages use at least one third party, and the median mobile page across all sites makes 79 third-party requests (HTTP Archive Web Almanac 2025).
Ads, analytics and CDN are the most common categories, and the googletagmanager.com domain sits in the top 10 third-party domains. The chapter does not measure what they cost, so measure your own.
Start with tags that nobody reads reports from. Then check what each remaining tag adds to main thread time in the DevTools Performance panel.
Layout shifts
Layout shifts come from space the browser did not reserve.
Images and video: without width and height the browser reserves no space, so content shifts down as they load. Set the attributes or use CSS aspect-ratio.
Ads, embeds and injected banners: reserve space with min-height or aspect-ratio, and show a placeholder when no ad returns, since collapsing the reserved space also shifts the layout.
Reserve first, load later.
How your CMS, theme and plugins set the speed ceiling
The platform sets the baseline, and the theme, plugins and builders decide how far a site falls below it. The Web Almanac 2025 says WordPress performance varies more with themes, plugins and configuration than with core.
| Platform | Mobile sites with good Core Web Vitals, 2025 |
|---|---|
| Duda | 85% |
| Wix | 74% |
| WordPress | 45% |
These pass rates come from the HTTP Archive Web Almanac 2025 CMS chapter. The chapter also notes that Lighthouse scores are context, not a proxy for real-user experience.
WordPress
Page builders: around 60% of WordPress sites reportedly use one, and builders tend to add DOM complexity plus larger CSS and JavaScript.
Newer builders: conditional loading and fewer shortcodes narrow the gap without closing it.
Caching plugins: a plugin such as WP Rocket caches output and optimizes files, but it does not shrink the markup structure a theme or builder generates.
WordPress core did change one behavior. As of WordPress 6.3 (August 2023), core supports fetchpriority and applies lazy loading to fewer LCP images.
Sites that were still lazy-loading their LCP image on 6.2 saw mobile LCP improve 16% to 21%, per the Core Performance Team’s field analysis of more than 500,000 WordPress home page URLs. The author cautions that field data is noisy and cannot confirm causation for individual sites.
The same analysis found fetchpriority accuracy on the LCP image was only around 50% across scenarios. Core helps, but a theme can still get the LCP image wrong.
Shopify
On Shopify the levers are the theme and the apps.
- Shopify’s developer docs steer app builders toward theme app extensions, which do not edit theme code
- App embed blocks can load scripts on specific pages only
- The Shopify Theme Inspector for Chrome points to the lines of Liquid slowing pages
Ask each app vendor whether it uses extensions and embed blocks. Template-level and platform-level causes like these are where the redesign question starts.
Which fixes to make first
Work from the cheapest configuration change to the costliest template change: caching and CDN, then the LCP element, then third-party tags, then render-blocking files, then DOM and template work. Each step costs more developer time than the one before it.
| Fix | Effort | Metric moved | Where it stalls |
|---|---|---|---|
| Page caching and CDN | Low | TTFB, LCP | Cache misses still reach the slow origin |
| LCP image priority and size | Low | LCP | The LCP element is not the image you assumed |
| Third-party tag cleanup | Low to medium | INP, LCP | A tag another team owns and needs |
| Render-blocking CSS and JS | Medium | LCP, FCP | Missed critical CSS causes unstyled flashes |
| Template and DOM work | High | INP, CLS | The builder or theme caps the gain |
Identify the LCP element on each template before ranking anything. Nuvemshop, an ecommerce platform, started 2025 expecting image weight or server latency to be the cause, and its web.dev case study says “We were wrong.”
An image prioritization strategy then lifted its share of stores with good LCP from 57% to 96% between January 2025 and January 2026.
Ranking inside your own site works the same way.
- Search Console takes the worst metric as a URL group’s status, so Poor CLS with Good INP still shows Poor. Fix the failing metric first.
- Revenue templates (product, checkout, lead form) before archives and old posts
- Clicking Start Tracking begins a 28-day validation, and the issue counts as fixed if no URL shows it in that window. A failed validation restarts with Start new validation.
Can a redesign fix a slow website?
Partly. A redesign fixes problems that live in templates and the platform, and it carries over problems that live outside the design.
Sort every cause into one of three levels before deciding.
| Level | Typical cause | Fix route |
|---|---|---|
| Page | One oversized hero, one lazy-loaded LCP image | Edit that page |
| Template | Theme CSS and JS on every page, a heavy header slider | Change the theme or template |
| Architecture | Builder-generated markup, client-rendered framework, platform limits | Rebuild or replatform |
Problems a redesign fixes
Anything built into the template is fair game.
- Scripts and styles shipped to every page
- Markup structure produced by a builder
Those are the causes a patch cannot reach.
Problems a redesign carries over
Hosting: a new design does not change DNS, TLS or origin response time.
Tags: a Google Tag Manager container moves to the new site with everything inside it, unless someone prunes it first.
Uploads: a new template does not resize the images editors upload next month.
When fixes stop working
Fix in place when:
- The failing metric traces to one page, one asset or one script
- Field data moves after each fix round
Rebuild when:
- Field data still fails after the server, LCP, tag and render-blocking fixes
- The failing metric traces to template or builder markup, and the replacement can meet a written budget
How to stop a redesign from making the site slower
Write the performance budget before the wireframes, test every stage against it, and check field data after launch. A redesign adds weight in places no visual review shows.
Where a redesign adds weight
- Hero images and background video
- New web fonts
- Animation and sliders
- Component libraries that overlap with existing scripts
- Fresh marketing tags
A new hero can also change which element counts as LCP, so re-identify it on every template.
What a performance budget contains
Quantity-based: limits such as maximum image size, number of web fonts, script size and third-party resources.
Milestone timings: user-centric events such as First Contentful Paint.
Rule-based: scores from Lighthouse or WebPageTest.
web.dev recommends tracking a combination of quantity-based and user-centric metrics. Its guide was last updated in November 2018, and its defaults (Time to Interactive under 5 s and under 170 KB of critical-path resources) predate Core Web Vitals. Budget LCP, INP and CLS instead, and keep quantity limits per page type.
Pre-launch checks
- Record field LCP, INP and CLS per template before the build starts.
- Write the budget per page type and sign it off with the design.
- Review each new third-party script before it ships.
- Test in 3 stages: HTML templates, staging and production.
- Fail the build in Lighthouse CI by setting limits under ci.assert, or point budgetsFile at a budget.json.
- After launch, compare field data with the baseline and start Search Console validation.
Lighthouse CI runs each URL 3 times by default. Its default aggregation is optimistic, so switch to median if one good run should not pass the gate.
A documented case shows the checks working. Donoci, a retailer running 27 e-stores in 25 European countries, kept its redesign to minor technical changes with no stack switch, and INP improved afterward, by “higher tens of percentages” on some page types (Web Performance Calendar, 2024).
The same write-up recommends reserving 10 to 20% of each sprint for performance work after launch.
How to Confirm Your Website Speed Fixes Held
A website speed fix holds when field data crosses the threshold and stays there, which takes at least 28 days because PageSpeed Insights and Search Console both read a 28-day window.
The wait sets the order of work:
- Lighthouse on each fixed template the same day
- Search Console validation once the fix is live
- A field data review every 28 days
Ship one change per template per window. Stack three fixes inside the same 28 days and the field data cannot show which one worked.
The trade-off is slower iteration, which Lighthouse CI budgets offset by catching regressions on every build before field data can register them.
This cadence follows the reporting windows documented as of November 2026, so a change to CrUX reporting would change it.
Renowned for his expertise in logo design and visual branding, Bogdan has developed a multitude of logos for various clients.
His skills extend to creating posters, vector illustrations, business cards, and brochures. Additionally, Bogdan's UI kits were featured on marketplaces like Visual Hierarchy and UI8.
He also wrote in the past years on sites like Design Your Way, WebDesignerDepot, WPDean, Designmodo, Speckyboy, Slider Revolution, and more.
- Why Your Website Is Slow and What to Fix Before a Redesign - 13 November 2026
- How to Replace an Image in Canva Without Breaking the Layout - 12 November 2026
- What’s the Best Bot-Free AI Note Taker for Client Calls in 2026 - 12 November 2026
Bogdan Sandu is a seasoned designer who has been designing websites since 2008. Renowned for his expertise in logo design and visual branding, Bogdan has developed a multitude of logos for various clients. His skills extend to creating posters, vector illustrations, business cards, and brochures. Additionally, Bogdan's UI kits were featured on marketplaces like Visual Hierarchy and UI8. He also wrote in the past years on sites like Design Your Way, WebDesignerDepot, WPDean, Designmodo, Speckyboy, Slider Revolution, and more.
You Might Also Like
