Website Speed Optimization: How to Find and Fix a Slow Website
Published October 16, 2026 · Last updated October 16, 2026 · By the WebSolutions LLC team
A slow website costs you twice: visitors give up before the page appears, and the ones who stay find it harder to read, tap and buy. The good news is that most slow business websites are slow for the same handful of reasons, and most of those can be fixed without rebuilding the site. This guide explains how to measure speed properly, what usually causes the problem, and the fixes we apply first, in the order that tends to give the biggest improvement for the least effort.
Step 1: Measure before you change anything
Start with numbers, not impressions. A page can feel fast on your office connection and still be slow for a customer on a mid-range phone.
- Field data first. PageSpeed Insights shows real-user data from the Chrome UX Report when your site has enough traffic, and the Core Web Vitals report in Google Search Console groups slow URLs by template.
- Lab data to diagnose. Lighthouse, built into Chrome DevTools, runs a repeatable test and lists the specific files and elements slowing the page down.
- Know the targets. Google's Core Web Vitals define "good" as Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less and Cumulative Layout Shift (CLS) of 0.1 or less, measured at the 75th percentile of page loads (web.dev: Web Vitals). INP replaced First Input Delay as a Core Web Vital in March 2024 (web.dev announcement).
Test your homepage, your main service or product page and your contact or checkout page. These templates usually account for most visits and most enquiries.
Why is my website slow? The usual causes
- Oversized images. Photos uploaded straight from a camera or stock site, often several megabytes each, displayed at a fraction of their size.
- Too many scripts. Chat widgets, sliders, multiple analytics and advertising tags, and page builder add-ons that load on every page whether they are used or not.
- Slow server response. Overloaded shared hosting, an outdated PHP version, no page caching, or heavy database queries. web.dev suggests most sites should aim for a Time to First Byte of 0.8 seconds or less (web.dev: TTFB).
- Render-blocking CSS and fonts. Large stylesheets and several web font files that must load before anything appears on screen.
- Layout shifts. Images and embeds without set dimensions, and banners injected above content after the page starts to render.
Step 2: Fix images first
Images are the most common cause of a slow Largest Contentful Paint on business sites, and the easiest to fix.
- Resize to the size you display. A hero image shown 1200 pixels wide does not need a 5000-pixel original.
- Use modern formats. WebP and AVIF are typically much smaller than JPEG or PNG at similar visual quality, and are supported by all current major browsers.
- Serve responsive sizes. The
srcsetandsizesattributes on the img element let phones download a smaller file than desktops. - Lazy-load below the fold, not above it. Add
loading="lazy"to images further down the page, but web.dev warns not to lazy-load images likely to be visible on load, especially the LCP image (browser-level lazy loading). For the main hero image, considerfetchpriority="high"(Fetch Priority API). - Always set width and height. Explicit dimensions let the browser reserve space and prevent layout shift.
Step 3: Trim and defer JavaScript
- Audit every third-party tag. List each script, who asked for it and whether anyone still uses its data. Remove what nobody needs.
- Load only where needed. A booking widget or map only needs to load on the page that shows it, not site-wide.
- Use
deferorasyncfor scripts that do not need to run before the page is displayed. - Break up long tasks. Slow responses to taps and clicks (poor INP) usually come from heavy JavaScript running on the main thread. Fewer and lighter scripts are the most reliable fix.
Step 4: Caching and compression
- Page caching. On a CMS site, a page cache serves pre-built HTML instead of rebuilding each page from the database on every visit. This is often the single biggest server-side win.
- Browser caching. Set long
Cache-Controllifetimes for versioned static files such as CSS, JavaScript, fonts and images, so returning visitors do not download them again (web.dev: HTTP cache). - Text compression. Make sure the server sends HTML, CSS and JavaScript compressed with Brotli or gzip. Lighthouse flags this if it is missing.
- A content delivery network. A CDN stores copies of static files closer to visitors, which helps most when your audience is spread across regions.
Step 5: Improve the server
- Run a supported runtime version. Newer PHP and database versions are generally faster and receive security fixes. Test on a staging copy before switching.
- Check your hosting plan. If response times are slow even on cached pages, the server itself may be overloaded. Moving to better hosting is a common fix; plan it with our website migration checklist so nothing breaks during the move.
- Clean the database. Old revisions, expired temporary data and spam comments slow down queries on long-running CMS sites.
Step 6: CSS, fonts and layout stability
- Remove unused CSS left behind by themes and page builders, and avoid loading several icon libraries that do the same job.
- Limit web fonts to the families and weights you actually use, and use
font-display: swapso text appears while fonts load. - Reserve space for banners, cookie notices and embeds so content does not jump as they appear.
Keep it fast
Speed tends to drift as plugins, tracking tags and new images are added. Re-test your main templates every month as part of your website maintenance routine, check the Core Web Vitals report when you publish new templates, and treat any new third-party script as something that must justify its weight. Speed is also one of the checks in our technical SEO audit checklist, because a slow site can hold back otherwise strong pages.
If your site is still slow after the quick wins, our web development and hosting services can dig into the theme, server and code. Browse our FAQs or contact us with your website address.
Website Speed FAQs
Short answers to the questions we hear most about slow websites.
Why is my website slow to load?
The most common causes are oversized images, too many third-party scripts, slow hosting or missing page caching, render-blocking CSS and fonts, and heavy themes or page builders. Lighthouse and PageSpeed Insights list the specific files responsible.
Why is my website slow on mobile but fine on desktop?
Phones usually have slower processors and less reliable connections, so heavy JavaScript and large images hurt much more. Test with PageSpeed Insights on the mobile setting and fix images and scripts first.
What is a good page load time?
Google measures loading with Largest Contentful Paint, and a good score is 2.5 seconds or less for at least 75 percent of page visits. Responsiveness (INP) should be 200 milliseconds or less and layout shift (CLS) 0.1 or less.
Does website speed affect SEO?
Yes. Core Web Vitals are part of the page experience signals Google uses, although relevant, helpful content matters more. Speed also affects whether visitors stay long enough to read and contact you.
Will a caching plugin fix a slow WordPress site?
Page caching often helps a lot with server response time, but it does not fix oversized images, heavy scripts or layout shifts. Treat it as one step alongside image optimisation and script clean-up.