Start with Core Web Vitals, not a single score
Core Web Vitals provide a useful framework for understanding how a page behaves for visitors. Largest Contentful Paint, or LCP, looks at how quickly the main content becomes visible. Interaction to Next Paint, or INP, relates to how quickly a page responds after someone interacts with it. Cumulative Layout Shift, or CLS, measures unexpected movement while content loads.
A performance tool can identify possible problems, but the report is only the starting point. I look at the page structure behind the result: the hero image, fonts, scripts, third-party tools, server response, and elements that change size. That helps separate a meaningful improvement from a cosmetic score adjustment that does not make the site easier to use.
- Identify the slowest page templates and highest-value landing pages
- Review mobile behavior separately from desktop behavior
- Prioritize issues that affect visibility, interaction, and stability
Optimize images without making the site look worse
Images are often one of the clearest opportunities on a business website. An image may be much larger than the space where it appears, saved in an inefficient format, or loaded immediately even though it sits far below the first screen. I can review dimensions, compression, responsive variants, and loading behavior so the browser receives an appropriately sized file.
Optimization should preserve the purpose of the image. A product photo, service-area image, team portrait, and decorative background do not all need the same treatment. I also check image dimensions and placeholders to reduce layout movement, while keeping useful alternative text where the image conveys information rather than decoration.
- Resize oversized uploads before delivery
- Use modern formats when browser support and image quality make sense
- Defer below-the-fold images while protecting important above-the-fold content
- Keep image dimensions defined to reduce layout shifts
Improve delivery with hosting and caching
A well-built page can still feel slow if the server takes too long to begin responding or if visitors repeatedly download the same files. Hosting capacity, server configuration, database work, geographic distance, and traffic patterns can all affect delivery. I review the current environment before recommending a change, because moving hosts is not automatically the right answer.
Caching can reduce repeated work by allowing suitable pages and assets to be reused. Browser caching, page caching, object caching, and content delivery services solve different problems and should be configured deliberately. I also check cache invalidation, logged-in behavior, forms, carts, and other dynamic features so a speed change does not serve stale or incorrect content.
- Review server response time and resource limits
- Set sensible cache behavior for static assets
- Test forms, checkout, scheduling, and personalized areas after caching changes
- Consider hosting migration only when the current environment is a real constraint
Reduce front-end work that visitors never need
Modern websites often depend on plugins, analytics, chat tools, maps, pop-ups, video embeds, and marketing scripts. Each may be useful, but every script can add download, parsing, execution, or network work. I trace what loads on each page and look for duplicate, unused, or unnecessarily early resources rather than removing tools blindly.
CSS and JavaScript can also delay visible content or slow interaction on lower-powered phones. Practical improvements may include loading nonessential tools later, removing unused assets from specific templates, reducing plugin overlap, and improving how fonts are requested. The goal is a page that supports the business task with less browser work—not a stripped-down site that loses important functionality.
- Inventory third-party scripts and their page-level purpose
- Load nonessential tools after primary content where appropriate
- Remove unused plugin assets from pages that do not need them
- Check interaction behavior after every script change
Measure, fix, and verify in the right order
Speed work is most useful when it follows a repeatable cycle. I establish a baseline, identify the largest bottlenecks, make controlled changes, and test the affected pages again. I review both lab-style diagnostics and practical behavior across representative pages, because a homepage, service page, blog post, and checkout flow can have very different performance profiles.
Not every issue deserves equal time. A small improvement to a page that receives important traffic may be more valuable than a large improvement to an unused template. After changes, I document what was adjusted and what still needs attention. That gives you a maintainable performance roadmap instead of a one-time collection of unexplained tweaks.
- Create a before-and-after record for key templates
- Test navigation, forms, media, and conversion paths
- Recheck performance after plugin, content, or hosting changes
- Schedule periodic reviews when the site changes frequently