A site owner can often improve page speed by preparing better images, removing unnecessary features and checking caching settings. Bring in technical help when the delay comes from shared templates, server behavior or JavaScript interactions, or when a change could disrupt checkout, indexing or essential functionality. The useful starting point is a repeatable problem on a real page, not a disappointing score in isolation.
Find the slow part before choosing the fix
A page can appear quickly and still respond poorly when someone opens its menu. Another page may feel responsive but move its content just as a visitor tries to tap a button. Both need attention, but compressing an image will not necessarily solve either problem.
Core Web Vitals separate important parts of that experience. Largest Contentful Paint, or LCP, describes when the largest eligible visible content element is rendered. Interaction to Next Paint, or INP, measures responsiveness across interactions. Cumulative Layout Shift, or CLS, measures unexpected visual movement.
The good thresholds are LCP at or below 2.5 s, INP at or below 200 ms, and CLS at or below 0.1, assessed at the 75th percentile. These are experience benchmarks, not a promise of search rankings. Good performance belongs alongside useful content, accessible navigation and a technically sound website.
Start with a page that matters to visitors: a product, service, article or contact page. Describe what happens in ordinary language. Does the main image arrive late? Does a filter hesitate? Does a banner push the text down? That description gives the measurement a purpose.
Read PageSpeed Insights and Search Console together
PageSpeed Insights combines field information, when available, with a controlled lab test. Field data reflects eligible real-user experiences across different conditions. Lab data examines a particular test environment and is useful for reproducing problems and investigating possible causes.
The results can disagree without either being broken. Your visitors may use different devices, connections and interaction patterns from the test. Field data also represents a reporting period, while a lab run reflects the page at the time of testing. An improvement can appear in a lab test before it becomes visible in the field report.
Check whether the field results describe the individual URL or the wider origin. An origin-level result is useful context, but it does not establish that every page behaves identically. Missing field data is not a clean bill of health either; the available sample may be insufficient.
Search Console's Core Web Vitals report helps identify affected groups of similar URLs. Use it to spot patterns, then inspect representative pages. A shared product template calls for a different intervention from an isolated oversized image in an article.
Do not mistake a Lighthouse performance score for the field assessment. A standard navigation test also does not reproduce every interaction a visitor performs. Open menus, expand accordions, submit forms and use filters on an actual device. Record where the experience stalls.
Decide what you can safely change
Ownership matters as much as difficulty. A small setting can affect the whole website, while a carefully scoped image replacement may touch only a page. Before making changes, confirm how to restore the previous version and test important journeys.
| What you observe | Sensible owner action | When to involve a specialist |
|---|---|---|
| A large editorial image loads late | Upload an appropriately sized, compressed version | The theme delays discovery or loading of the main image |
| A page includes unused widgets | Identify which features still serve a purpose | Scripts are shared or removal affects dependencies |
| Public pages seem slow to arrive | Check existing cache settings and hosting support | Slow responses persist or personalized pages are involved |
| Content jumps during loading | Check image dimensions and embed settings | The movement comes from templates, fonts or injected components |
| Menus and filters hesitate | Record the interaction and affected device | JavaScript or rendering work blocks responsiveness |
Treat this as a boundary for investigation. It is not evidence that a particular plugin, host or theme is at fault. Change a limited part, observe the result, and keep a record of what changed.
Make images lighter without delaying the important one
Upload images that suit their intended display size. A photograph prepared for print can carry unnecessary weight when used in a small content area. Compress it, inspect the result for visible damage, and use an appropriate modern format where the publishing workflow supports it.
Responsive image handling matters too. The browser should be able to select a suitable image for its display conditions. Your CMS may already generate variants, but a theme or page builder can prevent those variants from being used effectively.
Below-the-fold images can often load later. The prominent image visible on arrival should not automatically receive the same treatment. Lazy-loading the likely LCP image can delay the content that visitors came to see. If the theme controls that behavior, ask for a targeted adjustment.
Keep dimensions or an appropriate aspect ratio reserved for media. Replacing a large file with a smaller one will not prevent layout movement if the browser still does not know how much space to leave for it.
Audit plugins, scripts and fonts by purpose
List the features that add code to the page: analytics, chat, embedded video, advertising, social widgets and page-builder modules. For each, identify its owner and purpose. An abandoned campaign tag should not remain simply because nobody remembers who installed it.
Plugin count alone is a poor diagnosis. A lightweight feature may add little overhead, while a necessary plugin can load substantial code on pages where it is unused. Ask what executes, where it executes and whether it needs to run immediately.
Test removals on a staging copy when possible. A form, consent control or checkout integration may depend on code that appears unimportant in a speed report. Delaying scripts can improve loading in some circumstances while breaking the interaction that makes the page useful.
Fonts deserve the same scrutiny. Unused families and weights add complexity. Simplifying the typography can help, but changing font-loading behavior may alter line breaks and move content. Check headings, navigation and buttons after the change, including translated pages and right-to-left layouts.
Check caching without serving the wrong page
Caching can avoid repeated work, but different caches solve different problems. Browser caching reuses downloaded resources. Page caching can reuse generated public HTML. A content delivery network may cache static assets without caching the whole page.
First establish what your existing system already does. Adding another optimization layer without understanding the current setup can create conflicting settings or make troubleshooting harder. Ask the host or developer which responses are cached and how updates are purged.
Personalized pages need special handling. Account areas, carts and other user-specific responses must not be served from an inappropriate shared cache. After changing settings, verify that content updates appear correctly and that signed-in and signed-out visitors receive the intended experience.
Recognize problems that need technical diagnosis
A slow initial server response may involve application work, database queries, cache misses or hosting constraints. It does not automatically mean that buying a different hosting plan will solve the issue. A developer can inspect the request path and identify where the time goes.
JavaScript-heavy templates need similar care. A page may download quickly yet leave the browser busy with execution and rendering. The right fix could involve reducing work, loading a feature only where needed or changing how an interaction is implemented. Blanket script delays are not a substitute for understanding dependencies.
Layout shifts can originate in shared components: advertising slots, banners, embedded content and font swaps. Fixing the template may help many pages. Editing each article individually may leave the underlying cause untouched.
Redesigns and migrations add another layer of risk. A faster new layout can still introduce broken redirects, incorrect canonicals or accidental indexing restrictions. Keep performance checks and technical SEO checks connected, with a clear rollback route before launch.
Give a specialist evidence and a bounded brief
A useful request says what users cannot comfortably do, where it happens and what must keep working. Include affected URLs, screenshots or saved reports, device context and the steps needed to reproduce an interaction. Note recent theme, plugin, hosting or content changes without assuming they caused the problem.
Use this checklist before handing over the work:
- [ ] Identify important pages and the actions visitors take on them.
- [ ] Save baseline reports and label field and lab results separately.
- [ ] Describe the visible delay, hesitation or movement.
- [ ] List essential integrations and business functions.
- [ ] Confirm backups, staging access and a rollback process.
- [ ] Agree on the proposed change, testing scope and acceptance criteria.
- [ ] Assign responsibility for checking results after release.
Ask for an explanation of the suspected cause and why the proposed work addresses it. Acceptance should include working forms and navigation, stable content and comparable performance checks, not only a screenshot with a better score.
Where Jonathan Santo fits
The homepage for Jonathan Santo's technical SEO and website improvement work describes work on existing websites, including site structure, content, indexing, speed and Core Web Vitals. Those areas overlap with the point at which a performance issue becomes a wider website diagnosis. Discuss the specific problem, implementation responsibilities and validation process before agreeing on a scope; the service description itself does not establish an outcome for your site.
Verify the improvement where visitors feel it
Repeat comparable lab checks after the change, then test the affected journeys yourself. Allow field reporting to reflect subsequent visits before judging its trend. Keep the baseline and implementation notes so another person can understand what was changed and why.
If loading improves but a filter still stalls, the remaining work is responsiveness. If the page feels faster but content jumps, layout stability still needs attention. A useful handover leaves you with a working improvement, an explanation and a maintenance habit that prevents the same problem returning.
Partner content. This article is about Jonathan Santo and is separate from WebVitalsDev's editorial coverage.
