Why Is My Website Slow? A Step-by-Step Fix List
“My website is slow” can mean a dozen different things. The server might take two seconds before it sends anything. The page might arrive quickly and then spend seconds downloading oversized photos. Or everything might load and the page still freezes when someone taps a button, because the phone is busy running scripts.
Each of those has a different fix, and the fix for one does nothing for the others. A faster server won’t shrink a 5 MB hero image, and compressing images won’t help a page that waits on its database. So instead of trying every tip at once, this article works through the usual causes in the order they happen during a page load. For each one: how to tell it is your problem, and what to do about it.
Step 0: Measure before you change anything
Start with a speed test of the slow page on mobile, and note three things: the Time to First Byte (TTFB, how long until the server starts answering), the Largest Contentful Paint (LCP, when the main content appears) and the Total Blocking Time (TBT, how long scripts keep the page from responding). Also note the total page size and the number of requests.
These numbers point you to the right step below:
- High TTFB (well over a second): start with the server, step 1.
- Fine TTFB but slow LCP: look at images (step 2) and anything blocking the first render.
- High TBT, or the page feels stuck after it appears: JavaScript and plugins (step 3) and third-party scripts (step 4).
- Large total size (several megabytes): images and scripts, steps 2 to 4.
Run the test two or three times and use the middle result, so one unlucky run doesn’t send you in the wrong direction. You can scan your site for free to get these figures in one report, or use any Lighthouse-based tool.
Step 1: The server is slow to answer
How to tell. TTFB is high on every page, including simple ones. web.dev treats roughly 0.8 seconds or less as a good TTFB. If yours is regularly above that, every other metric starts late, because the browser can’t do anything until the HTML begins to arrive.
Common causes:
- No page caching. A content management system (CMS) such as WordPress builds each page from the database on every visit unless something stores the finished page. Without a page cache, each visitor waits for that work.
- Slow database queries, often from a plugin that runs heavy queries on every page, or a database that has grown with years of revisions, logs and expired data.
- Undersized or overcrowded hosting. Cheap shared plans put many sites on one server; when a neighbour is busy, so is yours.
- Distance. A server in one country serving visitors on another continent adds delay to every round trip.
- Redirect chains.
http://tohttps://towwwto the final URL can add several hops before the real page even starts.
What to do. Turn on page caching first: through your host, a caching plugin, or your platform’s built-in setting. It is usually the single biggest server-side improvement for a CMS site. Then check the redirect chain and link directly to the final URL. Our Time to First Byte guide covers the details, and web.dev’s TTFB optimization article goes further for developers.
Step 2: The images are too big
How to tell. The page size is large, LCP is slow even though TTFB is fine, and the speed test lists suggestions about image sizes or formats. Images are the most common cause of heavy pages on small-business sites.
Common causes:
- Photos uploaded straight from a camera or phone, thousands of pixels wide, displayed in a box a few hundred pixels wide.
- Old formats only. JPEG and PNG still work, but WebP and AVIF are usually much smaller at the same visual quality.
- The main image at the top of the page set to load lazily, so the browser waits before fetching it.
- Sliders that load every slide on page load.
What to do. Resize images to roughly the largest size they are shown at, and let your platform or an image plugin generate several sizes so phones get smaller files. Serve WebP or AVIF where your setup supports it. Lazy-load images further down the page, but not the first large image. Our image delivery guide explains formats and sizing, and the post on the LCP image covers the top image in detail.
Step 3: Too much JavaScript, plugins and page builders
How to tell. TBT is high, the page looks loaded but doesn’t react to taps for a while, and the test lists “reduce unused JavaScript” or “minimize main-thread work”. On a CMS, the number of installed plugins or add-ons often tracks the problem.
Common causes:
- Plugin build-up. Each plugin can add its own CSS and JavaScript, often to every page, even where it isn’t used. A contact-form script on the blog, a slider library on the checkout: small each, heavy together.
- Page builders. Visual builders make design easy, but many produce deeply nested HTML and load a large shared bundle of styles and scripts. The more widgets a page uses, the more the phone has to process.
- Feature-rich themes that bundle sliders, animations and icon sets you never switched on.
- Animations and effects that run scripts on every scroll.
What to do. List your plugins and remove the ones you don’t use or can replace with a few lines of settings. For the ones you keep, check whether they offer an option to load only on the pages that need them; some performance plugins can also disable scripts per page. When choosing a theme or builder, test a demo page on mobile before committing. Our JavaScript cost guide explains why phones feel scripts much more than laptops do.
Step 4: Third-party scripts
How to tell. The test shows many requests to other domains, and a “reduce the impact of third-party code” item. Removing a tag in a test copy makes a noticeable difference.
Common causes: chat widgets, several analytics and advertising tags, social media embeds, video players, heatmap and A/B testing tools, review widgets, cookie banners. Each one downloads code from someone else’s server, and that code often loads more code. You don’t control its size or speed.
What to do. Make an inventory: what each script is, who asked for it, and whether anyone still uses its data. Remove the forgotten ones. Load the rest after the main content where possible, and replace heavy embeds with a lightweight preview that loads the real player or map only when clicked. Our third-party code guide and the post on setting a third-party script budget show how to keep this under control as marketing needs grow.
Step 5: Fonts, compression and caching
These rarely make a page slow on their own, but they add up, and they are usually quick to fix.
- Web fonts. Several font families, each in several weights, can add hundreds of kilobytes and delay text from appearing. Use one or two families, only the weights you need, and modern WOFF2 files.
- No text compression. HTML, CSS and JavaScript compress very well with gzip or Brotli. Most hosts turn this on by default, but not all; a speed test lists it if it is missing.
- No browser caching. Without cache headers, returning visitors download your logo, styles and scripts again on every visit. Long cache lifetimes for files that rarely change fix that.
Each of these is usually a setting in your host’s control panel, a caching plugin, or a CDN, not a code change.
Step 6: No CDN, or hosting that has run out of room
A content delivery network (CDN) keeps copies of your files on servers around the world and serves each visitor from a nearby one. It helps most when your visitors are spread across regions, and many CDNs also handle compression, caching and modern protocols such as HTTP/2 and HTTP/3 for you. Our CDN and hosting guide explains what to expect from one.
When to change hosting. Consider it when TTFB stays high after page caching is on and the slow plugins are gone, when your host can’t provide a current version of your platform’s language (for example PHP for WordPress), or when the site slows down at busy times of day regardless of what you change. Moving to a better plan with the same host is sometimes enough. Compare on measurable things: server location near your visitors, the server-side caching on offer, current software versions, backups and support response. A trial and a TTFB test from the new server tell you more than any advertised speed claim.
A fix list to work through
- Measure the slow page on mobile three times; note TTFB, LCP, TBT and page size.
- Turn on page caching and remove redirect hops.
- Resize and convert large images; don’t lazy-load the top image.
- Remove unused plugins, theme features and builder widgets.
- Audit third-party scripts; remove, delay or replace with click-to-load previews.
- Trim fonts; confirm compression and browser caching are on.
- Add a CDN if visitors are far from your server; upgrade hosting if TTFB is still high.
- Measure again the same way, and keep the notes for next time.
Work from the top and stop when the page is fast on a phone. Most sites find their main problem in the first three steps.