A slow website is easier to fix after you know which part is slow. Start in the browser: the Network panel shows what loads, the Performance panel shows what blocks the main thread, and the first screen shows what visitors notice before they scroll.
This series keeps those checks separate. Use the hub as a map, then open the page that matches the problem you see.
Start with evidence
Do not begin by installing a cache plugin, compressing every image, or removing half the site. Those changes can hide the real cause when you apply them blind.
Open the page in a fresh browser session, disable cache in DevTools, and reload. Sort the Network table by size and time. Then record a Performance trace and look for long JavaScript blocks, layout shifts, and late first-screen content.
The first pass should answer one question: what is the browser waiting on?
The five checks
1. Diagnose the slow page
The diagnosis page explains the first inspection pass: Network, Performance, Coverage, mobile throttling, and the difference between a heavy download and a busy main thread.
Read part 1: Diagnose a slow website in the browser
2. Fix oversized images
Images create many of the largest requests on a page. A 4032px photo displayed at 600px still costs the browser the full file download and decode. The image page covers dimensions, formats, compression, lazy loading, and responsive image sizes.
Read part 2: Website images too large
3. Reduce JavaScript and third-party scripts
JavaScript can delay rendering and interaction even after the page appears. Analytics tags, chat widgets, testing scripts, and theme bundles all compete for the same main thread.
Read part 3: Third-party scripts slowing a website
4. Improve the first screen
Visitors judge speed before the full page finishes loading. The loading page focuses on the first visible content, layout stability, font behavior, preloading, lazy loading, and background work.
Read part 4: Loading strategy for the first screen
5. Set browser and server caching
Caching keeps repeated work from happening on every visit. Browser cache rules help returning visitors, while server and CDN cache rules can reduce the cost of the first HTML response.
Match the symptom to the fix
Use the first symptom to choose the next page:
- Large image files at the top of Network: start with images.
- Long yellow blocks in Performance: start with scripts.
- Empty or shifting first screen: start with loading.
- Repeat visits feel like first visits: start with caching.
- You are not sure what you are seeing: start with diagnosis.
The fix is not always one change. A slow homepage can have a 3 MB hero image, a render-blocking analytics tag, and no long-term cache headers on static files. Work through the visible bottlenecks first, then measure again.
What not to fix first
Avoid changing hosting, themes, frameworks, or plugins before the browser points to a cause. Those are expensive changes. A waterfall full of oversized JPEGs needs image work, not a new stack. A long task from a chat widget needs a script decision, not another compression pass.
Fix the page in layers: downloads, main-thread work, first-screen rendering, then cache reuse. That order keeps each change tied to a visible browser signal.
