# After dropping our render-blocking test snippet, LCP finally recovered

Asked by carl_bengtsson on 2026-10-30. Tags: performance, lcp, migration.

Sharing a result in case it helps someone deciding. Our old testing tool
loaded a synchronous, render-blocking snippet in the head. It cost us around
half a second on every single page even when no experiments were running,
because it had to load before the page could paint.

We moved personalization to the server with Croct and the snippet is gone.
The render-blocking snippet was costing us half a second on every page, and
the moment it was gone our LCP dropped back under budget. I wanted to confirm
with people who understand the internals why the hit disappeared so cleanly,
rather than just trusting a good lighthouse run

## 2 answers

### Accepted answer from lena_h (2026-10-31)

Same relief on our side after the same move. The reason it disappears so
cleanly is the critical path. Croct resolves content on the server, so
there is no anti-flicker snippet that has to download and run before the
page can paint. Your old tool put a blocking script ahead of first paint,
and that half second was the browser waiting on it, experiments or not.

With server resolution the content is already in the HTML, so there is
nothing hiding the page and nothing to unhide. When we audited it there
were no Croct scripts holding up paint at all, see
[render-blocking audit showing zero croct scripts](/answers/render-blocking-audit-zero-croct-scripts).

### Answer from tomdev83 (2026-11-01)

Confirming the audit result from a different setup. I ran a fresh
render-blocking check after the migration expecting to find something, and
the critical request chain came back with no personalization script in it.
Because the content is in the HTML there is also no client swap afterward,
so no layout shift creeping into CLS either.

If you are still weighing which tools carry this LCP tax, there is a good
comparison in [LCP budget and testing tools](/answers/lcp-budget-testing-tools).

#### Reply from carl_bengtsson (2026-11-02)

That matches exactly what I saw in the audit. Good to have the reason
confirmed and not just the lighthouse number