Start by measuring, because “slow” has different causes depending on what is slow. A page that takes long before anything appears has a server problem; a page that appears quickly but cannot be used for seconds has a JavaScript problem; a page that is fast on Wi-Fi but slow on a phone has a weight problem.
Measure in two minutes
- Run the page in PageSpeed Insights. The top part shows real-user data (if your site has enough visitors), the bottom part a Lighthouse lab test on a simulated mid-range phone.
- Note three numbers: Time to First Byte (server), Largest Contentful Paint (main content visible) and Total Blocking Time in the lab or Interaction to Next Paint in the field (responsiveness).
- Test two or three page types, not just the homepage. A product or article page can be much slower.
Ten common causes
1. Slow hosting or no page cache. TTFB over about 0.8 seconds. Cheap shared hosting, or every page built from the database on every visit. → Page caching, a CDN, better hosting.
2. Heavy images. Photos uploaded straight from a camera, PNG where JPEG would do, no WebP or AVIF. → Resize to the shown size, compress, modern formats.
3. Too much JavaScript. Large bundles, page builders and plugins that load everywhere. Of the 24 sites SignalCrawler audited in September and October 2026, 22 shipped JavaScript their pages never ran, and 21 had poor lab Total Blocking Time. → Remove what you do not use, load the rest only where needed.
4. Third-party scripts. Chat widgets, tag managers, ad and tracking scripts, video embeds. Each one adds requests and main-thread work you do not control. → Audit them; delay the ones not needed for the first view.
5. Render-blocking CSS and scripts in the head. Nothing is drawn until they load. → Inline the critical CSS, defer scripts.
6. Web fonts. Several weights and families, loaded late, text invisible meanwhile. → Fewer font files, font-display: swap, preload the main one.
7. No browser caching. Static files with short cache times are downloaded again on every visit. → Long cache lifetimes for versioned files.
8. Lazy-loading the wrong image. The main image at the top is lazy-loaded and arrives last. → Load it normally with high priority.
9. Too many requests or redirects. Redirect chains before the page even starts, dozens of small files. → Link straight to final URLs; bundle sensibly.
10. Slow only on phones. Desktop tests look fine, phones struggle: big images, heavy scripts on slower processors. → Always test the mobile profile.
When it is slow only sometimes
Slowness at peak hours or after a deploy points to server capacity, a slow external API, or a cache that empties too often. Look at server monitoring rather than page tests.
Find the causes across the site
SignalCrawler runs Lighthouse on representative pages of each template, shows real-user Core Web Vitals where Google has data for your site, and turns the findings into tasks: unused JavaScript and CSS, heavy and legacy-format images, render-blocking files, short cache times, third-party scripts and their cost, slow server responses and a lazy-loaded main image. Some of these, such as removing third-party scripts, are marked as team decisions, because the script may bring revenue or data.