Website speed audit: what slows your pages down and how to fix it

What a website speed audit is and when it makes sense

A website speed audit reviews how fast your pages load, how quickly they respond to clicks and whether content shifts while loading. The result is a list of specific causes and fixes, not a single number.

It makes sense when Search Console flags weak Core Web Vitals, when the site feels slow on mobile, or when it slowed down after new scripts (tracking, chat, reviews). You can measure speed for free, for example in Search Console, a free Google service; an audit explains what the numbers mean for your site.

Core Web Vitals: LCP, INP and CLS

Core Web Vitals are three metrics Google uses to describe page experience:

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	how fast the largest element appears, often the main image	up to 2.5 s	over 4 s
INP (Interaction to Next Paint)	how fast the page responds to a click or tap	up to 200 ms	over 500 ms
CLS (Cumulative Layout Shift)	how much content shifts unexpectedly while loading	up to 0.1	over 0.25

Values in between “need improvement”; the thresholds are set out on web.dev. Google assesses the 75th percentile of visits, separately for mobile and desktop: a page passes when at least 3 out of 4 visits get a good value. FID is no longer a Core Web Vital; INP replaced it on 12 March 2024. Details are on web.dev.

Why PageSpeed Insights shows different numbers from Search Console

PageSpeed Insights shows two kinds of data:

• Field data from the Chrome User Experience Report (CrUX): real visits by Chrome users over the last 28 days. The Search Console report uses the same source.
• Lab data from Lighthouse: one simulated page load, on mobile with a mid-range phone and a throttled network, from a Google data centre.

According to web.dev, a lab run uses predefined device and network settings, usually an empty cache, and does not capture scrolling or tapping. Real people use different phones and return to pages, so the numbers differ. Search Console also groups similar URLs, and the worst metric sets the group status, so a group result can differ from a single page in PageSpeed Insights.

Two things worth knowing:

• Lighthouse does not measure INP during a page load. Nobody clicks during a page load, so it reports TBT (Total Blocking Time), the time long tasks, typically JavaScript, block the browser’s main thread. According to web.dev, it is a useful proxy, not INP.
• The 0–100 score is not a Core Web Vitals assessment. It is a weighted average of lab metrics, and it can vary between runs.

The differences are explained in detail on web.dev.

Who the audit suits and who it does not

It suits website and shop owners who want to know why the site is slow before rewriting anything, typically shops on Shoptet or WooCommerce with many add-ons and scripts.

It does not suit you if:

• you want to know where people hesitate or why they abandon checkout. That is what a website UX audit covers;
• the site is still being built. Speed is cheaper to handle while building the business website;
• you expect a promise of a specific score or ranking. Nobody can honestly give one.

How the audit works

1. Scope. The whole site, or selected page types: home, category, product, cart. Each has its own template and problems.
2. Field data. If the site has it, CrUX and Search Console data are reviewed. They show where real visitors have problems.
3. Lab analysis. Lighthouse and Chrome developer tools show why: which element is the LCP, what blocks rendering, which scripts load the browser, what shifts content.
4. Recommendations. A fix for each finding and who can make it: a template change, a setting, or the platform or hosting side.
5. Optional implementation. webrocks can also carry out the fixes. Field data improves gradually, because according to the PageSpeed Insights documentation CrUX covers the last 28 days.

The most common causes of a slow website

The guidance on web.dev keeps returning to the same causes:

• Images. A main image at an oversized resolution, in an old format instead of WebP or AVIF, lazy-loaded or discovered only through JavaScript. The right size and fetchpriority="high" on one or two key images help, see the LCP guide.
• Elements without reserved space. Images without width and height, ads, embedded videos or late-inserted bars push content around and worsen CLS, see the CLS guide.
• Web fonts. A slow font delays text and swapping it shifts the layout. WOFF2, subsetting, font-display and a similar fallback font help, see the font guidance.
• Third-party JavaScript. Tracking code, chat windows, review widgets or maps can slow down loading and responsiveness. Defer them (async, defer), lazy-load them and above all remove what is unused, see the third-party script guide. For tracking code, review what you really need in Google Tag Manager and GA4.
• Long JavaScript tasks. Long-running code blocks the response to a click. Split it up and defer what can wait, see the INP guide.
• Slow server. According to the LCP guide, time to first byte (TTFB) is part of LCP. Caching, a CDN and fewer redirects help, but often it is the hosting.

What you get

• The state of Core Web Vitals from field data, if available, separately for mobile and desktop.
• Findings for each metric: the cause, affected pages and how to fix it.
• The order of fixes by impact, and who can make each one.
• Optionally the fixes and a check measurement.

What to watch out for

• Do not chase a score of 100. A score of 100 does not mean passing Core Web Vitals, and a lower score does not mean real visitors have a problem, because lab and field data differ.
• Do not overestimate the effect on Google. Google says Core Web Vitals are used by its ranking systems, but there is no single signal, and good results in tools do not ensure top positions. Relevant content can rank on a slower site, see the Google documentation.
• Small sites often have no field data. According to the CrUX methodology, CrUX only includes pages that are publicly discoverable and visited enough; Google does not disclose the exact minimum. Then lab data, or your own visitor measurement, is what remains.
• CrUX does not see iPhones. According to the CrUX methodology, data comes only from Chrome on desktop and Android. Neither Safari nor Chrome on iOS contributes.
• Every new script has a cost. A chat or pixel is easy to add; the slowdown shows later.

How much a speed audit costs

The price list shows a website or online shop audit per brief and an indicative hourly rate from 500 CZK/hr. The price depends on the scope and complexity of the project. Implementing fixes is optional.

More page types, many third-party scripts and implementing fixes raise the price. A clearly defined part of the site, such as just the product page or cart, and access to Search Console lower it.

For an audit or fixes, describe your site and the problem through the contact form. You will get a reply within 24 hours.

Frequently asked questions

What are Core Web Vitals?

Three Google metrics for user experience: LCP (main content display), INP (response to interaction) and CLS (layout stability). Good values are LCP up to 2.5 s, INP up to 200 ms and CLS up to 0.1, for at least 75% of visits.

How can I check website speed for free?

Use PageSpeed Insights: field data at the top, if the site has it, the Lighthouse lab test below. In the free Search Console, check the Core Web Vitals report.

Is the 0–100 PageSpeed Insights score a ranking factor?

Google does not say so. Lighthouse calculates the score from a single lab run, whereas Google’s search documentation describes Core Web Vitals as metrics of real-world user experience.

Does the audit include implementing the fixes?

Optionally, yes. The audit delivers findings with recommendations that anyone can follow. If you want, webrocks also carries out the fixes in the template, CSS and JavaScript.

Can an online shop on Shoptet or WooCommerce be made faster?

Partly: images, fonts, custom CSS and JavaScript and third-party scripts can be changed at template level. On Shoptet, changes mainly go through the template, see Shoptet customisation. On WooCommerce, hosting and plugins also play a role, see WooCommerce customisation. How much can be gained only shows from a review of the specific shop.