How to check your website's speed and make it faster

To check your website's performance, run your key pages through Google PageSpeed Insights, then open the Core Web Vitals report in Google Search Console to see the whole site. Focus on the field data from real visitors, not just the 0 to 100 score. To make the site faster, work in order: fix slow hosting and server response first, then add caching and a CDN, shrink and properly load images, cut unneeded scripts and plugins, and stop elements from jumping around as the page loads. Most small business sites can get much faster without a rebuild.
We already explained what the metrics mean in Core Web Vitals for small business websites, in plain English. This post is the hands-on version: which tools to use, how to read them and what to fix first.
The numbers that matter
Here are the current targets, from Google's web.dev guide to the Core Web Vitals thresholds and its TTFB article.
| Metric | What it tells you | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How fast the main content shows up | 2.5 s or less | Over 4 s |
| Interaction to Next Paint (INP) | How fast the page reacts to taps and clicks | 200 ms or less | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much the page jumps while loading | 0.1 or less | Over 0.25 |
| Time to First Byte (TTFB) | How fast your server starts responding | 0.8 s or less | Over 1.8 s |
Anything between "good" and "poor" needs improvement. Google rates each metric at the 75th percentile of page views, so at least three out of four visits need to hit the good mark. TTFB is not a Core Web Vital, but a slow server delays everything after it, so it is the first place to look when LCP is slow.
Two more numbers are worth watching. Total page weight is the size of everything the page downloads: HTML, CSS, JavaScript, images, fonts and video. Request count is how many separate files it loads. Neither has an official threshold, but heavy pages with lots of requests are slow on phones almost every time.
How to check your site's performance
PageSpeed Insights: field data vs lab data
PageSpeed Insights shows two kinds of results, and mixing them up causes most of the confusion we see.
- Field data sits at the top. It comes from the Chrome User Experience Report (CrUX), which collects anonymized data from real Chrome users over the previous 28 days. This is what Google Search uses.
- Lab data sits below it, along with the 0 to 100 score. It comes from Lighthouse, which loads your page once on a simulated mid-tier phone with a throttled mobile connection.
According to Google's PageSpeed Insights documentation, lab data reflects a single device and a fixed set of network conditions, while field data covers a much wider mix of real visitors. Google's article on why lab and field data differ adds more reasons: lab tests start with an empty cache while repeat visitors often have files saved, lab tests cannot measure real taps (so INP only appears in field data), and lab tests mostly catch layout shifts during load, not ones that happen while someone scrolls.
The practical rule: use field data to decide what to fix, and use lab data to figure out why. If your page does not have enough traffic for field data, PageSpeed Insights falls back to data for your whole domain. If the domain has too little traffic as well, the lab results are your best guide.
Search Console's Core Web Vitals report
PageSpeed Insights tests one URL at a time. The Core Web Vitals report in Search Console shows your whole site, split into mobile and desktop. It groups similar pages together and gives each group the status of its worst metric. When you fix something, click "Start Tracking" to begin a 28-day validation period. That does not ask Google to recrawl anything; it just starts the clock. If you have not set up Search Console yet, see our glossary entry on Google Search Console.
Chrome DevTools: Lighthouse and the Performance panel
Open your site in Chrome, right-click, choose Inspect, and you get two useful tabs:
- Lighthouse runs the same lab test as PageSpeed Insights, but on your own computer. It is handy for testing pages that are not public yet, like a staging site.
- Performance records exactly what happens as a page loads or as you click around. You can turn on CPU and network throttling to act like a slower phone. It shows long tasks (JavaScript that freezes the page), which element counts as LCP and what caused each layout shift. It is the best tool for tracking down INP problems.
WebPageTest and GTmetrix
WebPageTest and GTmetrix both run lab tests from real browsers in different locations. Their main strength is the waterfall chart, a timeline of every file the page loads, in order. A waterfall makes problems easy to spot: a slow first response from the server, a huge image, or a chat widget that loads before your content. WebPageTest also lets you choose a test location near your customers and compare a first visit to a repeat visit.
Uptime monitoring
A fast site that goes down twice a week is still a slow site to your customers. An uptime monitoring service checks your site every few minutes and alerts you by email or text when it stops responding. Many of them also chart response time, which helps you catch a host that is getting slower over time.
Test on a real phone
Lab tools simulate a phone. Nothing replaces holding one. Grab a mid-range Android phone (not the newest flagship), turn off Wi-Fi and load your home page and your most important service page on cellular data. Tap the menu, open a form, scroll. If anything feels sluggish or jumps, your visitors feel it too. Do this after every major change.
How to make your website faster, in order
This is the order we work in on client sites. The early steps usually fix the biggest problems.
1. Fix hosting and server response (TTFB)
If your TTFB is over 0.8 seconds, start here. Common causes are crowded shared hosting, an old PHP version, no page caching, slow database queries and a server far from your visitors. Better hosting is often the biggest single improvement on a WordPress site. Our guides to choosing web hosting and the best WordPress hosting walk through the options.
2. Turn on caching and a CDN
Caching saves a ready-made copy of each page so the server does not rebuild it for every visitor. A CDN stores copies of your files on servers around the world, so visitors download them from somewhere close. Set long browser cache times for images, CSS and JavaScript that rarely change. Many managed hosts and platforms include both; on others, a service like Cloudflare adds them.
3. Optimize images
Images are the heaviest part of most small business pages.
- Use modern formats. WebP and AVIF are much smaller than JPEG or PNG at the same quality.
- Size images for where they display. A 4,000-pixel photo shown 1,200 pixels wide is wasted weight. Use responsive images (srcset) so phones get smaller files.
- Lazy-load images below the fold, never the main one. Google's research on the effects of too much lazy loading found that lazy-loading images at the top of the page can slow LCP. Load the hero image right away.
- Give the LCP image priority. Add
fetchpriority="high"to the hero image. Google's Fetch Priority guide reports that it improved LCP from 2.6 seconds to 1.9 seconds in a test on Google Flights. Use it on one image only, not every image.
4. Load fonts carefully
Every font family and weight is another file. Stick to one or two families and only the weights you use. Host fonts on your own domain if you can, use the WOFF2 format, and set font-display: swap so text shows right away. Preload the one font used in your main heading.
5. Trim JavaScript and third-party scripts
This is usually the fix for poor INP. Make a list of every third-party script on the site: analytics, Google Tag Manager tags, ad pixels, chat widgets, heatmaps, session recorders, review badges and popups. For each one, ask who uses it and when they last looked at it. Remove the rest. For what stays:
- Delay chat widgets until someone scrolls or clicks a "Chat" button.
- Run heatmaps for a few weeks at a time, not forever.
- Clean out old Tag Manager tags from past campaigns.
- Load scripts with
deferorasyncso they do not block the page.
6. Cut page builder and plugin bloat on WordPress
Heavy page builders and stacks of plugins add CSS and JavaScript to every page, even pages that do not use them. Delete plugins you no longer need, replace several single-purpose plugins with one, and avoid sliders. If the builder itself is the problem, a lighter theme or the block editor for new pages helps. Our comparison of Elementor, Divi and Astra covers the tradeoffs.
7. Clean up CSS
Large stylesheets block the page from showing until they download. Remove unused CSS, minify what is left and inline the small amount of CSS needed for the top of the page. Many caching plugins and build tools handle this, but test after turning it on, because aggressive CSS removal can break layouts.
8. Stop layout shift
Give every image, video and embed a width and height (or an aspect ratio) so the browser saves space for it. Make cookie banners and announcement bars overlay the page instead of pushing it down. Reserve space for ads and embedded maps. Use font-display and matching fallback fonts so text does not jump when the web font arrives.
Problems, symptoms and fixes
| Problem | How you'll spot it | Fix |
|---|---|---|
| Slow server | TTFB over 0.8 s; long first bar in the waterfall | Better hosting, page caching, current PHP |
| Heavy hero image | LCP element is an image; large file in waterfall | Resize, convert to WebP or AVIF, add fetchpriority="high" |
| Lazy-loaded hero | Lighthouse flags the LCP image as lazily loaded | Remove lazy loading from above-the-fold images |
| Too many scripts | Poor INP; long tasks in the Performance panel | Remove unused tags, delay chat and heatmaps |
| Plugin or builder bloat | Dozens of CSS and JS files on every page | Delete plugins, lighter theme, fewer builder elements |
| Font delays | Text appears late or changes size | Fewer weights, WOFF2, font-display: swap, preload |
| Layout shift | CLS over 0.1; page jumps on a real phone | Set image sizes, overlay banners, reserve ad space |
| No CDN or caching | Slow for visitors far from the server; repeat visits not faster | Add a CDN and long cache times |
Platform-specific tips
- WordPress: Good hosting and a caching plugin do most of the work. Keep plugins lean, update PHP, and check that your theme is not lazy-loading the hero image. An image optimization plugin can convert uploads to WebP.
- Shopify: Hosting and the CDN are handled for you, so focus on apps and theme. Every app you install can add scripts, and some leave code behind after you uninstall them. Pick a fast, current theme. More in our guide to Shopify for growing brands.
- Wix and Squarespace: You cannot change the server, so control what you can: compress images before uploading, limit embeds, animations and third-party widgets, and keep pages focused.
- Custom Next.js or static sites: Use the framework's image component (which handles sizing, modern formats and priority), its font tools and static generation where possible. Watch your JavaScript bundle size, because shipping too much client-side code hurts INP. We explain why we build this way in React and Next.js for business websites.
Quick-win checklist
- Test your home page and top service page in PageSpeed Insights on mobile
- Check Search Console's Core Web Vitals report for poor URL groups
- Compress and resize every image over about 200 KB
- Remove lazy loading from the hero image and add fetchpriority="high"
- Delete inactive plugins, apps and unused tracking tags
- Delay chat widgets and heatmaps until they are needed
- Turn on page caching and a CDN
- Set width and height on all images and embeds
- Cut fonts to two families and only the weights you use
- Load your site on a mid-range phone over cellular data
- Set up uptime monitoring with alerts
When to call a developer
Do the checklist first. Call a developer when:
- Field data still fails after the quick wins.
- TTFB stays high even with caching, which points to slow code, database queries or hosting.
- The Performance panel shows long JavaScript tasks you cannot trace to a plugin or script you can remove.
- Your theme or page builder is the root problem and fixing it means rebuilding templates.
- You are planning a redesign anyway, which is the cheapest time to build for speed.
If you want a second set of eyes, our SEO and AEO work includes performance audits with a prioritized fix list. Get in touch and tell us which pages matter most.
Questions people ask
What is the best free tool to check website speed?
Why does my PageSpeed score change every time I test?
What is a good page load time?
Will a faster website rank higher on Google?
When should I hire a developer to fix site speed?
Planning a website?
Get a platform recommendation and a fixed quote within one business day.



