Mobile LCP — what actually moves the needle

When a page loads slowly on mobile, the first assumption is almost always the images. Then they get compressed, lazy loading goes on, and the metric does not move. That happens because in a lot of cases the image was never the problem.

LCP measures when the largest element in the visible part of the page is painted. On mobile that is almost always the main heading or the hero image. The question is not how much it weighs, but what has to happen before it appears at all.

The reveal animation is the LCP

The most common thing holding LCP back is an effect. A heading that starts transparent and fades in is a heading that does not exist until the JavaScript has arrived, run, and started the animation. The browser cannot report an element nobody can see, so the metric waits for that whole chain.

At Sipur B'Tmuna the hero was built without that effect at all: it is rendered on the server, arrives inside the HTML, and has no hide-then-reveal stage. It also needs no client-side JavaScript — not to be interactive, and not to be visible.

The only interactive part there is the rotating text at the end of the sentence, and that is a small separate component. That separation is what matters: not "the page is interactive" but "two things on the page are interactive and the rest is not".

And then, yes, the images

Once the hero stops waiting for JavaScript, images really do become the next factor. There the build was specific: every image was prepared in advance at four widths (480, 900, 1400 and 2000 pixels) in WebP, and the browser picks the one that suits its screen.

The reason that was done ahead of time rather than on demand is cost. Automatic optimisation services bill per image, and on a site serving one geographic region that is a recurring monthly charge for work you can do once at build time. In that case an operating-cost decision set the architecture, and that is entirely fine, as long as it is a decision rather than an accident.

Fonts

A font loaded from an external service is a request to another domain before the text can be shown. On this site the fonts are downloaded at build time and served from the same origin as everything else, so there is no request to a font service during loading at all.

A small detail in the same area: this site has an intro screen, and a screen like that can cause a flash if the decision whether to show it is made after the first paint. Here it is made before, and that is the same family of problem — not weight, but order.

Platform constraints decide more than they look like they do

An example from the same project that does not touch LCP directly but shows the same principle: its authorisation layer was kept free of the database library, because it loads in an environment that cannot run it. That was not a stylistic choice — it was what the environment allowed.

The principle is the same: a lot of performance is settled in decisions that look architectural rather than performance-related. Where the code runs, what needs JavaScript, and what is produced ahead of time.

What to check, in this order

Before compressing anything: which element is being measured, and the measurement tool will tell you; whether it is hidden until an animation starts; whether it needs JavaScript to appear; and only then, how much it weighs and in what format. In that order, you usually stop after the second question.

Animation is an accessibility question too, not only a performance one — what we built to meet Israeli Standard 5568.

A landing page built around how fast it loads