Your speed report is a diagnosis, not a grade to feel bad about. The number that matters most is LCP (how fast your main content appears), and the fastest way to move it is usually images and hosting speed, not a full redesign. Start there before you touch fonts, plugins, or theme settings.
If you don't already have a report, run one first. Content Studio can test your site's speed and break down what's slow in plain English; see reading your speed score and fixing what's slow for how to run it and read the results.
The three numbers that matter
PageSpeed and GTmetrix both report Core Web Vitals. Ignore the rest of the wall of numbers until these three are healthy:
- LCP (Largest Contentful Paint): how long until the biggest visible element (usually a hero image or headline) finishes rendering. Good is under 2.5 seconds. This is the one Google weighs most in search rankings.
- CLS (Cumulative Layout Shift): how much your page jumps around while loading. Caused by images without set dimensions, fonts swapping in late, or ads/embeds injecting space. Good is under 0.1.
- TTFB (Time To First Byte): how long the server takes to respond before your browser has anything to render. This one is the closest thing to a pure hosting number, everything after TTFB is largely your page's own weight.
INP (Interaction to Next Paint) is the fourth Core Web Vital and measures responsiveness to clicks and taps. It matters more on interactive apps than typical brochure or blog sites, don't chase it before fixing LCP and CLS.
What's hosting, what's theme, what's images
Reports don't label causes by category, so here's the split:
Hosting-side (server response)
TTFB over 600ms usually points at the server: a slow database query, no caching layer, or a plan under real load. On our stack, LiteSpeed and LSCache handle static caching automatically, and WordPress installs get the LiteSpeed Cache plugin plus Redis object cache pre-configured, which cuts database round trips for dynamic pages. If TTFB is still high after a fresh cache warm-up, the cause is usually a slow plugin or query, not the server itself. Check PHP version too: older versions are slower per-request. You can switch a domain's PHP version from the PHP tile in the portal, current is faster.
Theme and plugin-side (render-blocking resources)
If your report flags "render-blocking resources," "unused CSS," or "unused JavaScript," that's almost always the theme or plugins loading more than the page needs. Each plugin you add is more CSS and JS shipped to every visitor, even ones who never touch that plugin's feature. Audit plugins you don't actively use and deactivate them. A bloated theme with lots of builder shortcodes (page builders especially) tends to carry this weight permanently.
Image-side (the most common LCP fix)
If your LCP element is an image, and it usually is, the fix is almost always one of these:
- Serve a properly sized image. A 4000px photo displayed at 800px wastes bandwidth and decode time.
- Use a modern format: WebP or AVIF instead of JPEG/PNG. Most image tools now export these.
- Compress before upload. Uncompressed photos straight off a phone or camera are often 5 to 10 times larger than they need to be.
- Set explicit
widthandheightattributes (or CSSaspect-ratio) so the browser reserves space before the image loads. This is also the main CLS fix for images. - Avoid lazy-loading the hero image itself. Lazy-loading below-the-fold images helps, but applying it to the LCP element delays the one thing the report is measuring.
Reading the waterfall
GTmetrix's waterfall view and PageSpeed's "diagnostics" section both show a timeline of every request. Look for:
- A single request that takes far longer than the rest, that's your bottleneck, not the total request count.
- Large gaps of white space between requests, that's often a render-blocking script forcing the browser to wait.
- Third-party scripts (chat widgets, ad tags, analytics) stacked near the top, these load early and can delay everything after them even though they're not part of your actual content.
When to escalate to support
If TTFB stays high after clearing cache, updating PHP, and ruling out a runaway plugin, or if you're not sure whether a slowdown is server-side or code-side, open a ticket from Support → New ticket in the portal. Real humans review server-side metrics you can't see from a PageSpeed report, like actual query time and resource usage, and can tell you definitively whether the bottleneck is infrastructure or your site's own code.