Making a small business website fast and stable on a phone
A short, source-based guide to LCP, INP and CLS and the fixes to ask your developer to try.
Start by recording a baseline
Before changing anything, record what your site does now. Working with your developer, capture your LCP, INP and CLS figures as a baseline, then select the one measured bottleneck the numbers point to. Try a fix only where the baseline shows a real weakness.
LCP: when the main content appears [1]
LCP is the moment the largest image, text block or video on the page that is visible in the viewport has finished rendering. A good score is 2.5 seconds or less, read at the 75th percentile of page loads, tracked separately for mobile and desktop. Field data reflects actual user visits; lab checks use fixed, repeatable conditions, so the two can disagree. If your LCP is already under 2.5 seconds, this metric is not the problem.
INP: how fast the page answers a tap [2]
INP summarizes how responsive the page feels over a whole visit, generally the longest interaction delay with the worst outliers left out, across clicks, taps and keyboard input. A good score is 200 milliseconds or less at the 75th percentile. Long tasks on the main thread, often large blocks of JavaScript, can delay the feedback after a tap. If your site runs few scripts, there may be nothing to change; if it is heavy on widgets, this is where to start.
CLS: how much the page jumps around [3]
CLS is a dimensionless number that scores how much visible content moves on its own across the page's whole lifecycle, scored from the largest burst of shifts. A good score is 0.1 or less at the 75th percentile. Giving images their width and height reserves space before the image arrives, which keeps the page from sliding. Fonts, embedded video and content added after load are other causes, so check which ones apply rather than assuming one fix covers all.
Find the LCP bottleneck before changing anything [4]
The first step in fixing LCP is to identify the element that is actually the LCP element and what is delaying it; it is sometimes a paragraph of text rather than an image. If it is a key image, making it easy for the browser to find early in the page helps, and lazy-loading it works against it. Preload, preconnect and priority hints each address a different kind of delay, so apply them selectively, only where the delay shows up, not as automatic steps.
Serve appropriately sized images [5]
Responsive images give the browser several candidates to pick from, so an appropriately sized candidate can avoid an unnecessary download. srcset lists the available sizes, and sizes gives hints about the display size you intend, so the browser chooses using its own display conditions, such as screen density. The picture element adds art direction for different layouts. Smaller display sizes do not mean every device gets one small fixed image; the browser handles the choice.
Cache static assets, not every response [6]
Caching helps repeat visitors skip re-downloading files that rarely change, like your site's images, scripts and styles. Cache-Control is the header that controls how long a response stays fresh and when it must be revalidated. Keep personalized or user-specific content out of shared caches; the private directive does this. no-cache forces a check before reuse while no-store blocks storage. Cache static assets where updates are managed; do not treat every response as shared across visitors.
Choosing a bottleneck and reviewing results
Work with your developer to change just the single measured bottleneck from your baseline. One change can move more than one metric, so watch them together. Then review the real-user results against the baseline and see which figure your next change should target.