Performance
How do you speed up a website?
The changes that make the biggest difference to load time, in the order to try them: server response, images, JavaScript, fonts, caching and third parties.
To speed up a website, measure first, then fix the biggest cause: a slow server response, oversized images, too much JavaScript, render-blocking CSS and fonts, missing caching and compression, or heavy third-party scripts. Images and JavaScript are the most common problems. Check real-user data to confirm each change helped.
Published · Last updated
Measure before you change anything
Run PageSpeed Insights or Lighthouse on your most important templates, not only the homepage, and look at real-user Core Web Vitals in Search Console. Write down the numbers. Speed work without a baseline produces changes nobody can prove helped.
The fixes, roughly in order of impact
- Images. Serve WebP or AVIF, at the displayed size, with srcset, and lazy-load everything below the fold. Images are the largest part of most pages.
- JavaScript. Ship less of it. Remove unused libraries, split bundles by route, and defer scripts the first view does not need.
- Server response. Cache pages that are the same for everyone, use a CDN, and fix slow database queries. Nothing paints until the first byte arrives.
- Third-party scripts. Every tag manager, chat widget, A/B tool and tracking pixel costs main-thread time. Remove the ones nobody uses and load the rest after the page is interactive.
- CSS and fonts. Inline the critical CSS, avoid many served-HTML stylesheet link counts, self-host fonts, subset them, and use font-display swap.
- Compression and caching. Text responses should be compressed with Brotli or gzip, and static assets cached for a long time with versioned file names.
- Layout stability. Set width and height on images and reserve space for banners and embeds, so the page does not jump.
Check your server basics
curl -sI -H "Accept-Encoding: br, gzip" https://example.com/ | grep -iE "content-encoding|cache-control"
No content-encoding on an HTML or JavaScript response means it is sent uncompressed.
Where AI-built and single-page apps lose time
Apps generated by AI builders and many React or Vite setups render the whole page in the browser. The visitor downloads, parses and runs a large JavaScript bundle before seeing anything. Pre-rendering or server rendering the first view, splitting code by route and removing unused dependencies usually save more than any image work.
Turning on every optimization plugin at once is how sites break in subtle ways. Change one thing, measure, keep it or roll it back.
Does speed affect SEO?
Core Web Vitals are part of Google's page experience signals, one factor among many. The bigger effect is on people: slow pages lose visitors before they see anything, and slower checkouts convert worse.
What a scan can and cannot tell you
WebAuditOS measures lab loading and blocking indicators on sampled pages and server response time on fetched pages, and checks compression, cache headers, request counts, render-blocking stylesheets, page weight, image formats and third-party script counts, so you can see which cause applies to which template.
It measures one load from one location. It cannot show real visitors' experience, and it cannot profile your backend to say which query is slow.
If only one template is slow, the cause is in that template. If every page is slow, look at the server, the CDN or a script on every page.
Short answers
What slows a website down most? Usually large images and too much JavaScript.
Will a CDN make my site fast? It speeds up delivery. It does not fix a heavy page.
How fast should a page load? Aim for LCP under 2.5 seconds for most real visits.
Do plugins fix speed? Some help. Many add their own weight. Measure each one.
In the product
The checks this maps to
Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.
- perf.ttfb - Server responds quickly (TTFB)
- perf.compression - Text responses compressed
- perf.cache-headers - Cache-Control configured
- perf.stylesheets-count - Render-blocking stylesheets in check
- perf.requests - Request count in check
- seo.image.filesize-hint - Modern image formats in use
Read next
Performance
What is Largest Contentful Paint, and how do you improve it?
LCP measures when the main content of a page appears. What counts as good, what usually makes it slow, and the fixes that move the number in practice.
Performance
What is a CDN, and does your website need one?
A CDN serves your site from servers close to each visitor. What it speeds up, what it does not, how caching works, and when a small site benefits from one.