Website Performance Guide
Website performance: diagnose the bottleneck before optimizing
An evidence-led SiteBoost guide to separating real user-facing performance problems from noisy measurements and low-impact micro-optimizations.
Start with the experience you are trying to improve
A performance score is a diagnostic summary, not the final goal. Begin with what a visitor experiences: slow initial rendering, delayed interaction, unstable layout, heavy media, or a page that becomes sluggish after scripts run. Different symptoms point to different causes, so optimizing blindly can consume time without improving the page people actually use.
Choose representative URLs before testing. A homepage, an editorial page and a feature-heavy application page may have completely different bottlenecks. Comparing unrelated page types can hide template-wide problems and make a normal variation look like a regression.
Measure consistently before and after a change
Performance varies with device capability, network conditions, cache state, server load and third-party services. Record the URL, approximate test conditions and time, then repeat measurements. One unusually fast or slow run is weak evidence.
When you deploy a fix, compare the same page type under similar conditions. Keep the change small enough that you can explain why the measurement moved. If five unrelated optimizations ship together, it becomes harder to know which one helped or introduced a new problem.
Find repeated costs before polishing one URL
Shared layout code, oversized hero images, font loading, analytics, chat widgets and other third-party scripts can affect many pages. A repeated bottleneck is often a better target than an isolated asset on a low-traffic page. Review what the browser must download and execute on every template.
Images deserve special attention because they can combine transfer size with layout cost. Serve dimensions appropriate to their rendered use, avoid shipping unnecessarily huge originals, and reserve layout space where possible. For decorative assets, question whether the visual value justifies the cost.
Treat JavaScript and third-party code as a budget
Interactive software needs JavaScript, but every script competes for network and main-thread time. Load functionality where it is actually needed rather than making every public page pay for application-only features. Third-party scripts should have a clear purpose and should be reviewed periodically because their behavior can change independently of your own code.
This matters especially on content pages. A guide should remain readable even if an optional analytics or advertising script is delayed. The publisher content should be the focal point rather than an interface that exists mainly to trigger another action.
Connect performance to SEO and usability
Fast delivery cannot compensate for an accidentally blocked page, incorrect canonical signal or content that fails to answer its topic. Likewise, a technically indexable page can still frustrate visitors if controls shift or interaction stalls. Review performance alongside crawlability, content quality and mobile usability rather than treating it as an isolated number.
Prioritize issues by reach and user impact. A small improvement repeated across every important template can be more valuable than a dramatic improvement on a page few people use.
Verify the live deployment
After a change ships, open the production URL and repeat the relevant checks. Confirm that the intended asset, script or template actually changed and that important functionality still works. Keep a short dated record of the change and result so future regressions have a baseline.
Do not promise a ranking outcome from a performance score. Performance is one part of a healthy web experience; search visibility also depends on discovery, relevance, content and many signals outside a single audit.