How to Speed Up a Website: 7 Ways and Core Web Vitals

Short answer: measure first, then fix the largest bottleneck: the LCP resource, server response, JavaScript, or layout stability. No single Lighthouse score describes every visit, so validate improvements separately in lab tests and field data.

Site speed affects user experience and is one of the signals associated with page experience. It is not a guarantee of rankings or conversions. Bounce and revenue studies describe relationships in specific samples, so use them as context rather than a promise for every website.

Core Web Vitals help Google evaluate page experience, but meeting their thresholds does not guarantee high rankings. If a site is slow, users may leave sooner and technical results become less predictable. Below are 7 practical ways to speed up a website and a method for measuring the effect.

1. Image optimization — the fastest win

Images typically account for 50–65% of a page’s weight — and they are also the element easiest to optimize with an immediate effect. Unoptimized images not only slow down loading but also generate higher CO₂ emissions (more data = more energy).

What to do:

Format: Switch from JPEG/PNG to WebP or AVIF. The difference in file size is 25–50% at the same visual quality.
Compression: TinyPNG, Squoosh.app, or ShortPixel — compress without visible loss of quality. You can also use our free WebP converter.
Responsive dimensions: The srcset attribute allows you to serve different image sizes depending on the device. A phone doesn’t need a 3000px graphic.

Example: Switching to WebP reduces image size by an average of 30%, which shortens loading time by 1–2 seconds on a typical product page.

2. Caching — speed up for returning visitors

Cache allows the browser to remember static files (CSS, JS, images) so it doesn’t have to download them on every visit. The result? The site loads instantly upon return visits.

What to do:

Cache-Control headers: Set this in .htaccess or your server configuration. CSS/JS files can be cached for up to a year (you will change the file name upon update anyway).
WordPress plugins: WP Rocket, LiteSpeed Cache, or W3 Total Cache — setup takes a few minutes, the effect is immediate.
Server-side cache: Opcache, Redis, or Varnish — for more advanced setups that eliminate repetitive database queries.
Cache policy: use a long max-age and immutable for versioned CSS, JS, and image files; keep HTML on a shorter cache so visitors receive current content.

A properly configured cache can reduce loading time by 50–70% for returning users (Pingdom data).

Render-blocking resources: remove the first-screen delay

Render-blocking resources are CSS files and scripts that delay rendering before the browser can show the main content. PageSpeed often reports this as “Eliminate render-blocking resources” or “Render-blocking resources”.

Check these items in order:

move non-critical scripts to defer or load them after interaction;
inline critical CSS and load the remaining CSS separately;
remove unused CSS and JavaScript instead of only compressing them;
do not defer CSS needed for the hero or the main LCP image.

Not every Lighthouse recommendation should be applied automatically. Changing load order can improve a lab score while hurting functionality, INP, or LCP, so run the CometWeb performance auditor and retest the page after every change.

3. CDN — serve content from the nearest server

A Content Delivery Network (CDN) distributes copies of your site to servers located around the world. A user in London downloads data from a server in Europe, and a customer in New York — from a server in America. The result: shorter loading times regardless of location.

Cloudflare — the free plan is sufficient for most sites. Setup takes a few minutes, the effect is immediate.
Amazon CloudFront / Bunny CDN — for more advanced needs, with more control over configuration and transfer pricing.

A CDN is especially valuable if your site has an international audience — it cuts loading times by up to 40–50% for geographically distant users.

Excessive DOM and enormous network payloads

An excessive DOM means too many HTML elements, while an enormous network payload means too much data downloaded for the first view. Both increase browser work, but they need different fixes.

for an excessive DOM, simplify nesting, remove hidden duplicate components, and limit lists rendered immediately;
for an enormous network payload, compress images, reduce fonts and libraries, and defer below-the-fold content;
measure response sizes in the Network panel and check whether Cloudflare or the server returns Brotli compression;
do not treat lazy loading as a complete fix when the largest payload is hero CSS, JavaScript, or the main image.

These recommendations describe the cost of one render, not the complete quality of a site. After reducing DOM size or payload, confirm that key links, headings, and structured data remain present in the rendered HTML.

4. Lazy loading — load elements only when needed

Lazy loading ensures that images and other heavy page elements are loaded only when the user scrolls down to them.

How to implement:

Add the loading="lazy" attribute to <img> tags in your HTML.
Enable this feature in WordPress plugins, e.g., WP Rocket or Lazy Load by WP Rocket.

With lazy loading, initial page load times can be sped up by 20–30%. One caveat: do not lazy-load your main above-the-fold image (hero) — that is usually your LCP element, and delaying it will hurt your score.

5. Code minification and compression

HTML, CSS, and JavaScript code can contain unnecessary spaces, comments, and repetitions that increase file weight.

Solutions:

Minify code using tools like CSSNano and UglifyJS, or use our code minification tool.
Apply GZIP compression to reduce the size of files sent from the server.

Example: Sites that applied HTML minification saved an average of 20% in loading time.

6. Core Web Vitals — the metrics Google measures

Core Web Vitals are three specific metrics Google looks at when evaluating the quality of the user experience on your site:

LCP (Largest Contentful Paint) — the loading time of the largest visible element (image, heading). Goal: under 2.5 seconds.
INP (Interaction to Next Paint) — how quickly the page responds to interactions (clicks, typing). Goal: under 200 ms. INP replaced the previous FID metric on March 12, 2024.
CLS (Cumulative Layout Shift) — visual stability, i.e., whether page elements “jump” during loading. Goal: under 0.1.

Key context for these numbers: the thresholds apply to the 75th percentile of real visits. A page is “good” for a metric when at least 75% of visits fall within the threshold, and a full pass requires all three metrics to be good. The latest global CrUX snapshot available for this update covers June 2026 and was published on July 14, 2026. It does not replace data for your domain:

67.7% of origins have good LCP in the global CrUX snapshot CrUX, June 2026

81.4% of origins have good CLS CrUX, June 2026

85.9% of origins have good INP CrUX, June 2026

55.3% of origins pass all Core Web Vitals at the same time CrUX, June 2026

This is a global aggregate, not a CometWeb or site-specific result. CrUX is updated monthly and uses real Chrome user visits; a low-traffic URL can show N/D.

How to improve:

LCP: Optimize the main image (hero image), set preload for critical resources, speed up server response (TTFB).
INP: Minimize heavy JavaScript, break up long tasks into smaller ones, avoid blocking the main browser thread.
CLS: Always specify dimensions for images and video frames (width and height), avoid dynamically injected elements above content.

Lab data vs CrUX — why the numbers differ

PageSpeed Insights shows you two different sets of numbers, and both are correct — they simply answer different questions:

Source	What it measures	What it is for	Limitation
Lighthouse / PageSpeed (lab)	A controlled single-run test: fixed device, network, and location	Diagnosing causes — what exactly slows the page down	Score varies between runs; does not describe real users
CrUX (field)	Real visits by Chrome users, 28-day window, 75th percentile	Assessing actual user experience and your standing in Google	Refreshes with a ~4-week delay; requires enough traffic

Practical rule: diagnose with lab data, confirm the trend with field data. A perfect Lighthouse 100 does not guarantee good CrUX — and vice versa.

N/D does not mean zero. When PageSpeed shows “N/D” for field data, it means there were not enough visits to measure (low traffic or a new URL) — not a score of 0 or 100. In that case, diagnose with lab data and revisit CrUX once the site collects traffic.

7. Website speed test — diagnostic tools

A website speed test shows what slows down a specific URL under defined device and network conditions. Optimization without measurement is shooting in the dark. The tools below will show you exactly what is slowing down your site:

Google PageSpeed Insights — detailed Core Web Vitals results with specific recommendations. Measures both lab data and real user data (CrUX).
CometWeb performance auditor — a quick URL-based check for performance and HTTP signals.
GTmetrix — allows testing from different locations and comparing results over time. Great for tracking optimization progress.
WebPageTest — the most detailed tests: waterfall chart, filmstrip, device comparison. A tool for those who want to understand every millisecond.
CometWeb Insight — a broader audit combining performance, SEO, accessibility, and ecology in one prioritized report.

What to check after shipping a fix

A fix does not end at deployment. A short retest list:

Record the test conditions. Lab scores depend on device, network, and page variant — retest in the same configuration as the pre-fix measurement.
Retest the lab immediately. The same PageSpeed or auditor run should show the change right away. If it doesn’t, the fix missed the root cause.
Give field data time. CrUX works in a 28-day window, so the full effect shows after roughly 4 weeks. No change the day after deployment does not mean failure.
Check the other metrics. Optimizing one metric can hurt another — lazy-loading the hero image reduces page weight but worsens LCP.
Set an acceptance condition. For example: “LCP under 2.5 s in lab and no CLS regression” — a concrete condition closes a task better than a vague “the site feels faster”.

Summary

Site speed is best improved as a diagnostic loop: measure, fix one issue, retest, then evaluate the trend. You don’t have to implement all 7 steps at once. Start with a diagnosis, identify the biggest issues, and fix them one by one. For technical SEO, also check canonical URLs, sitemaps, and robots.txt, because speed cannot repair conflicting indexing signals.

Want to expand your knowledge of technical SEO? Read: Technical SEO — The Complete Guide.

Sources

Chrome UX Report: release notes — global CrUX snapshot for June 2026, published July 14, 2026;
web.dev: lab and field data differences — the scope of Lighthouse and field data;
web.dev: Core Web Vitals — LCP, INP, and CLS thresholds and the 75th percentile methodology;
web.dev: INP replaces FID — metric change effective March 12, 2024;
Chrome UX Report (CrUX) — field data methodology and the 28-day window.

Bounce and conversion statistics describe relationships in specific industry studies — they are not guaranteed outcomes for a specific site. CrUX statistics are global aggregates and do not describe CometWeb. This article was updated on August 13, 2026 with June 2026 CrUX data, the lab vs field distinction, and the post-deployment retest list.