Every few months a client is told that their site is slow because it is too visual, and that the fix is to remove images. That is almost never the actual problem.
LCP is usually an architecture problem
Largest Contentful Paint measures when the biggest thing in the viewport finishes rendering. On a client-rendered site, that clock does not start until the browser has downloaded the JavaScript bundle, executed it, requested the data and painted the result.
No amount of image compression fixes a four-second gap before anything can render at all. Rendering the page on the server does, because the first response already contains the content.
Layout shift is a discipline, not a trade-off
Cumulative Layout Shift is almost entirely self-inflicted: images without dimensions, fonts that swap and reflow, banners injected above content after paint.
Reserve the space. Set width and height on every image so the box exists before the bytes arrive. Give web fonts a metrically similar fallback so the swap does not move a paragraph. None of this constrains the design.
Measure the page people land on
Lab scores on a homepage are the least useful number available. The pages that earn organic traffic are deep pages — a listing, an article, a product — and they are usually the heaviest and the least tested.
Pull the field data for the templates that actually receive search traffic, and fix the worst template rather than the average.
INP is the harsher one
Interaction to Next Paint replaced First Input Delay, and it is a much less forgiving metric. FID measured how long the browser took to start handling an interaction; INP measures how long until the screen actually updates, across every interaction in the session.
Which means it catches the thing FID politely ignored: a heavy JavaScript-driven interface where a tap on a filter blocks the main thread for half a second while a client-side re-render happens. The fix is rarely micro-optimisation — it is shipping less JavaScript, breaking up long tasks, and moving work that does not need the browser onto the server.
Fonts are usually the cheapest win
Web fonts are a reliable source of both slow paint and layout shift, and they are also the easiest thing on this list to fix properly.
Self-host rather than calling a third-party stylesheet, so the browser does not spend a round trip discovering the font file. Preload only the faces that appear above the fold. Subset the files — and for a bilingual site that matters twice over, because an unsubsetted Arabic face carrying every glyph is a large download for a page that uses a fraction of them. Then give each face a fallback with adjusted metrics, so the swap when the real font arrives does not move a single line of text.
Speed is not free of design input
None of the above constrains how a page looks, but two decisions genuinely are design decisions, and pretending otherwise is how they get made badly by default.
The first is what the hero is. A full-width video is a slow largest element by definition; a typographic hero with one optimised image is not, and the difference on a mid-range phone is measured in seconds. The second is how much of the page needs to be interactive. A component that could be static markup and was built as a client-side widget costs every visitor the JavaScript, whether or not they touch it. Those are worth deciding on purpose, early, with the numbers on the table.
The honest caveat
Vitals are one input among many, and a fast page about nothing will not outrank a slow page that answers the question. Fix performance because it raises conversion on the traffic you already have. Treat the ranking benefit as a bonus.