WHY YOUR SITE IS SLOW

If you open DevTools, change three plugins, and redeploy without looking at field data, you are guessing with extra steps. Slow is a visitor experience. Prove it with numbers from real users before you touch code.

Start with Chrome UX Report field data in PageSpeed Insights or Search Console Core Web Vitals. You want the 75th percentile for Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift on mobile. Lab scores from Lighthouse are useful for debugging a single page load. They are not the metric Google uses for ranking or the metric your buyers feel on a train Wi-Fi connection.

What to capture in the first ten minutes

URL of the slow page. Device class (phone first). Whether the problem is first visit or repeat visit. Whether logged-in pages differ from the public homepage. TTFB if you can see it. The LCP element name from the diagnostics panel. That short list usually points at the right lane before anyone debates frameworks.

Key takeaway: Field data decides whether the site is slow. Lab data helps you find the lever. Never reverse that order.

If the page is slow before any content appears, it is usually the server: high time to first byte, an uncached database query, PHP or Node rendering on every request, or a host that is simply underpowered. If content appears then janks, stalls, or shifts, it is the front end: images, scripts, fonts, and layout.

A useful split: TTFB under about 0.8 seconds means the origin is mostly out of the critical path. Above 1.2 seconds on a marketed page, fix hosting, cache, or server render cost before you obsess over image codecs. For large sites the diagnosis gets its own playbook in the Core Web Vitals checklist and the LCP, INP, CLS fix guide on this site.

Key takeaway: Name the lane first. Server work and front-end work need different people and different tools.

In order of how often they are the real problem on commercial sites I see:

1. Oversized hero media

A 2MB PNG or an uncropped CMS upload as the LCP element. Fix: right-size, modern format (WebP or AVIF), width and height attributes, preload the actual LCP URL, serve from a CDN. One good hero fix often beats ten micro-tweaks.

2. JavaScript you do not need on first paint

Tag managers, chat widgets, A/B tools, unused framework hydration, and "just in case" client components. Fix: defer or remove third parties, ship less JS on marketing routes, keep interactivity islands small.

3. Hosting and cache misses

Shared hosts, cold WordPress without page cache, Next.js SSR on every public URL, or ISR patterns that rebuild the world on every deploy. Fix: managed hosting or edge cache for WordPress, static or ISR with a sane revalidate policy for app frameworks.

4. Render-blocking fonts and CSS

Five weights of a display font, imported from a third-party CSS file, blocking text. Fix: subset, self-host, font-display swap or optional, critical CSS for above-the-fold.

5. Unbounded third parties

Pixels that inject more pixels. Fix: load after interaction or on idle, kill anything that does not earn its place in a conversion test.

6. Layout shift from late content

Ads, embeds, and images without reserved space. Fix: aspect-ratio boxes, reserved slots, avoid injecting UI above existing content.

Key takeaway: Most "the framework is slow" complaints are one of these six with a framework costume on.

Do not optimise everything at once. Open the LCP entry in your field or lab diagnostics, find the element that is the LCP (usually the hero image or headline), and make that one thing fast: right-sized, preloaded, served from a CDN. Re-measure. Then cut JavaScript that runs on the critical path. Re-measure again.

A practical order for a marketing site: LCP element, then third-party JS, then font loading, then cache and TTFB, then CLS cleanup, then micro-optimisations. Stopping after the first two often gets a commercial site into a passing CWV band.

WordPress note: a plugin diet and a real page cache on managed hosting beat a theme rewrite more often than agencies admit. Next.js and Astro note: do not SSR the brochure. Static or cached HTML for public pages; reserve server work for authenticated product surfaces. Details live in the Next.js vs Astro vs WordPress guide.

Key takeaway: One measured LCP win beats a week of speculative refactors.

WordPress

Page builders shipping every widget CSS on every page. Uncached WooCommerce templates. Heavy related-posts queries. Autoloaded options tables that grew for years. Fix path: cache HTML at the edge, cut plugins, lazy-load below-fold builder sections, fix the database autoload bloat.

Next.js

Client components wrapping whole pages. Waterfalls of sequential awaits. Images through the wrong loader. ISR or SSR on pages that never personalise. Fix path: Server Components by default, static where possible, audit the JS bundle per route.

Astro and other static stacks

Usually fast unless you reintroduce a SPA island the size of a product app, or hotlink giant CMS media. Fix path: keep islands tiny, process images in the pipeline, do not paste WordPress habits into a static site.

Key takeaway: Match the fix to the stack. Replatforming is rarely the first performance move.

Targets, measured on real visitors at the 75th percentile on mobile: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. Keep time to first byte under about 0.8 seconds so the server stays out of the critical path.

Hit those and the site is not slow in any way a visitor or Google will punish, no matter what a synthetic vanity score says. Anything faster is polish. Ship the product instead of chasing 100s.

If you want the checklist form of this work, use the Core Web Vitals checklist. If you need per-metric surgery, use the LCP, INP, and CLS fix guide. If the business case is a rebuild, start from the performance pillar rather than a redesign deck.

Key takeaway: Passing field CWV is the finish line for "is it slow?", not a perfect Lighthouse screenshot.

DIY is enough when the LCP element is obvious, third parties are few, and you control hosting. Bring in help when field data stays red after two honest fix cycles, when the stack is a hybrid nobody on the team owns, or when revenue pages cannot take another week of speculative changes.

A useful brief for an outsider: the three URLs that matter, the field screenshots, the LCP element names, the host and CDN, and the list of tags you are not allowed to remove. That package turns a vague "site is slow" into a one-sprint job.

If the conversation turns into a full redesign, pause. Performance work and redesign work mix badly unless the redesign has an explicit CWV budget. Fix the current templates first when the business still depends on them.

Key takeaway: Two failed fix cycles or no clear owner is the line between DIY and a paid performance pass.