Fast means three things
Speed is not one number. It is how your site feels while it loads and while people use it Source 1 .
- The main content appears quickly Source 2 .
- Interactions respond quickly Source 3 .
- The layout stays stable Source 4 .
What people experience
People do not think in milliseconds. They think in trust and frustration Source 7 .
- Slow means I cannot see what this is yet.
- Laggy means I clicked and nothing happened.
- Jumpy means the page moved and I clicked the wrong thing Source 4 .
The measures that match reality
Use metrics that reflect user experience on real devices. Focus on the pages that bring traffic and the pages that create conversions Source 6 .
Loading speed
- LCP shows when the main content appears Source 2 .
- Server response time influences how quickly the first bytes arrive.
- Page weight and request count predict how hard the page is to load on mobile.
Interaction responsiveness
- INP shows how quickly the site responds after clicks, taps, and typing Source 3 .
- Long JavaScript tasks make INP worse and make the site feel unreliable Source 3 .
Visual stability
- CLS shows whether the page shifts while loading Source 4 .
- Layout shift causes misclicks and resets reading position Source 4 .
What fast looks like in practice
Fast is a user experience standard, not a brag. These are signs your site is fast in the ways that matter Source 1 .
- On a mid-range phone, the page becomes useful quickly.
- You start reading without waiting for the page to settle Source 4 .
- Buttons respond without delay and forms do not feel sticky Source 3 .
- Scrolling stays smooth.
What keeps sites slow
Large media and sloppy uploads
- Oversized images.
- Background video on landing pages.
- Heavy galleries without responsive sizes.
- Missing media dimensions causing layout shift Source 4 .
Too much third-party code
- Tracking stacks.
- Chat widgets and pop-ups.
- Multiple tag managers and conversion scripts.
- Cookie tools that inject large bundles and block the main thread Source 9 .
Heavy front end bundles
- Large JavaScript bundles shipped to every page.
- UI libraries loaded site-wide for small features.
- Hydration costs on pages that do not need it.
- Unused CSS and unused JavaScript.
Weak delivery
- Poor caching and repeated downloads.
- No CDN for static assets.
- Redirect chains that add delay.
- Slow server response for dynamic pages.
A simple approach that keeps sites fast
Prioritise the main message
- Load the content that explains the offer first Source 2 .
- Delay anything decorative or optional.
- Avoid loading heavy widgets above the fold Source 9 .
Ship less JavaScript
- Use progressive enhancement for interactive features.
- Use islands only where interaction is needed.
- Remove libraries that exist for convenience only.
Control third parties
- Set a cap on third-party scripts Source 9 .
- Review quarterly and remove low value scripts Source 9 .
- Load scripts only on pages that need them.
Set budgets
Budgets stop performance drifting after launch Source 8 .
- A page weight budget per template Source 8 .
- A request count budget per template.
- A maximum number of third-party scripts Source 9 .
- A media policy for uploads.
Where to measure first
Measure in the places that earn money. Use lab tools such as Lighthouse to diagnose causes and test improvements Source 5 .
- Your top entry pages from search and social.
- Your top service pages and landing pages.
- Your main conversion pages, contact, donate, book, checkout.
Next step
If you want a fast site without constant effort, start with budgets and remove weight before adding new features Source 8 . A small set of rules, applied consistently, beats occasional large clean-ups. If you need help improving your site's speed, performance services can identify and fix the issues slowing your site down. For specific guidance on images and video, see image and video performance. For more on why score chasing fails and what works instead, see performance myths and quick fixes.
Sources
- [1] web.dev. Web Vitals. Back to article
- [2] web.dev. Largest Contentful Paint (LCP). Back to article
- [3] web.dev. Interaction to Next Paint (INP). Back to article
- [4] web.dev. Cumulative Layout Shift (CLS). Back to article
- [5] Google. Lighthouse performance scoring. Back to article
- [6] Google. Chrome UX Report. Back to article
- [7] web.dev. Why does speed matter?. Back to article
- [8] web.dev. Performance budgets 101. Back to article
- [9] web.dev. Load Third-Party JavaScript. Back to article