Website performance discussions often collapse into a single number. Someone runs PageSpeed Insights, sees a score in the seventies and assumes the site needs to be rebuilt. Or a site reaches 100 and everyone assumes performance is finished.
The score is useful, but it is a proxy. The real goal is a website that loads quickly, remains visually stable and responds without making the visitor wait.
Start with the experience, not the score.
A slow website is easy to feel. The main heading appears late. The layout jumps when the font loads. A large image blocks the first meaningful content. A menu button takes a moment to respond. Those delays damage the experience before the visitor knows anything about Lighthouse metrics.
For a small business, performance matters because the website is often part of a trust decision. A referral clicks through from a text message. A prospect searches on a phone. A potential customer compares several companies. The site should not introduce friction before the business has made its case.
Large images are usually the easiest place to win.
Photography is often essential to a strong design, but unoptimized images are one of the most common sources of unnecessary weight.
The solution is not to avoid large imagery. It is to serve the right file at the right size. Modern formats, responsive sources, sensible dimensions and careful lazy loading can preserve visual quality without asking every visitor to download a huge desktop asset.
Hero images deserve particular attention because they affect the opening experience. Images further down the page can usually wait until the visitor approaches them.
Fonts can create both delay and instability.
Typography is central to art direction, so performance advice that simply says “use a system font” is not always useful.
Custom fonts can work well when they are loaded deliberately. Limit unnecessary weights. Preload only what is genuinely critical. Use sensible fallback metrics so the layout does not shift dramatically while the font loads. Avoid loading an entire type family when the design uses two weights.
Performance optimization should protect the design, not flatten it.
JavaScript should justify its cost.
Modern sites can accumulate scripts quickly: analytics, chat widgets, scheduling tools, personalization, animation libraries, marketing pixels and embedded forms.
Some are valuable. Some exist because a tool was added months ago and never removed.
Every script has a cost in download, parsing and execution. The useful audit question is whether the business still benefits from it. A CRM form on the contact page may be worthwhile. Loading the same CRM script on every article may not be.
This is one reason I prefer page-specific integrations when possible. The contact page can carry the scripts it needs without making the homepage or blog pay the same performance cost.
Motion and performance can coexist.
Animation is not automatically a performance problem. Poorly implemented animation is.
Transforms and opacity changes are generally easier for the browser to handle than repeatedly changing layout properties. Continuous effects should be restrained on mobile devices. Reduced-motion preferences should be respected. Large animation libraries should not be loaded if the site only needs a few simple transitions.
The goal is not to remove character. It is to make sure the motion remains smooth enough that it feels intentional.
Core Web Vitals are useful because they describe real problems.
Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift are more meaningful than a generic “speed” label because they correspond to visible user experience.
Is the main content arriving quickly? Does the interface respond when someone interacts? Does the page stay stable while loading?
Those questions are worth optimizing whether or not a business follows every metric closely.
Third-party tools deserve special scrutiny.
A website can have excellent code and still become slow because of external dependencies. Reviews, chat, maps, scheduling widgets, videos and ad scripts can introduce unpredictable performance.
Sometimes the best solution is to defer the tool until interaction. A map can load after the visitor requests it. A video can use a lightweight poster until play. A newsletter can submit through a server route instead of loading a large vendor embed globally.
Those decisions preserve the functionality without making every visitor pay for it immediately.
A 90+ score is a useful target, not a business strategy.
I like high performance scores because they force discipline. A 90+ target encourages careful images, restrained JavaScript and better loading behavior.
But I would not sacrifice a valuable business feature solely to chase a perfect score. The right question is whether the feature earns its cost and whether it can be implemented more efficiently.
Performance belongs inside design and development decisions from the beginning. It is much easier to build a fast site deliberately than to bolt optimization onto an overloaded one at the end.