Performance guide · reviewed 26 Sep 2026
Why Your Website Is Slow—and How to Find the Cause
A slow experience can come from server response, render-blocking assets, the largest visible element, JavaScript work, layout movement, third-party code or a combination. Measure before installing another optimisation plugin.
Lab tests reproduce problems; field data shows what real eligible visits experienced. Use both.
Quick answer
A website is often slow because the server sends HTML late, the largest above-the-fold image or text is discovered late, CSS or fonts block rendering, JavaScript occupies the main thread, media lacks dimensions, or third-party tags add work.
Use real-user Core Web Vitals where available, reproduce the problem in DevTools or Lighthouse, identify the responsible resource or task, change one cause and measure again.
Separate real-user evidence from a lab run
The two answer related but different questions.
PageSpeed Insights may show Chrome User Experience Report field data when enough eligible traffic exists, plus a Lighthouse lab run. Field data reflects a rolling population of real visits; a lab result is one simulated environment useful for diagnosis and regression tests. Test representative product, article, service and checkout pages—not only the homepage.
Read the three current Core Web Vitals correctly
They cover loading, interaction and visual stability.
Google’s current “good” thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, assessed at the 75th percentile separately for mobile and desktop. These are diagnostic experience thresholds, not a promise of conversion or ranking gains.
Trace the slow phase to its owner
The waterfall and performance trace are more useful than a generic score.
- Late HTML: hosting, application work, database calls, cache misses or redirect chains.
- Late LCP resource: hero media discovered through CSS or JavaScript, missing priority, large transfer or slow origin.
- Render delay: blocking CSS, fonts, synchronous scripts or client-side rendering.
- Poor interaction: long JavaScript tasks, large DOM updates or heavy third-party code.
- Layout shift: media or embeds without reserved size, injected banners, font swaps or late content.
Fix the measured bottleneck
Optimisation is not a universal list of plugins.
Resize and encode images for their rendered use, provide intrinsic dimensions, make the LCP resource discoverable early, remove unused code, split long tasks, reduce third-party tags, cache appropriate content, review database and server work, and load fonts deliberately. A CDN can reduce distance for cacheable resources, but it cannot repair slow application code or an overloaded origin by itself.
Retest without claiming a fabricated percentage
A change can move one metric while harming another.
Save the URL, device, network, cache state, test tool and date. Compare repeat lab runs, then watch field data or your own real-user monitoring after deployment. Verify important interactions and visual stability, not only load time. Performance varies with devices, networks, geography and user behaviour.
Official performance documentation used here
Metric definitions and tools can evolve.
Questions
Website speed questions
Is a Lighthouse score the same as real-user performance?
Does hosting affect website speed?
Will a CDN automatically make the site fast?
Should I install a cache or optimisation plugin?
Does a fast site guarantee better rankings or sales?
Next step
Send the slow URL, device and symptom.
Ashish can reproduce the problem and scope the measured cause instead of selling a generic speed package.