Why Your Squarespace Site Fails LCP, and the One CSS Rule That Fixes It

You've compressed the images. You've cut the fonts to two. PageSpeed Insights still says your Largest Contentful Paint is 3.8 seconds and the mobile score is orange.

The usual advice doesn't fix this because the usual advice is about bytes. On Squarespace 7.1 the problem is usually about timing, and it comes from a design setting most people never touch.

What LCP measures, briefly

Largest Contentful Paint is the moment the biggest visible element on the screen, usually your hero image or headline, finishes rendering. Google wants it under 2.5 seconds. It's one of three Core Web Vitals and the one Squarespace sites fail most often.

The thing to know: the browser only counts an element as "painted" once it's actually visible. An element that is on the page but at opacity zero doesn't count yet. When it fades to visible, the clock reads that moment.

What Squarespace does

Squarespace 7.1 ships with site-wide animations. In Site Styles under Animations you can choose Fade, Slide, Scale, Clip and a few others, and you can set a speed. Many templates have this on by default, and most designers leave it on because it looks good.

Under the hood, Squarespace adds a class such as preFade to blocks and sections on load. That class sets them to opacity zero. Then a script adds fadeIn, and a CSS animation brings them to opacity one over a few hundred milliseconds, staggered down the page.

Your hero image was downloaded and decoded early. It was sitting there, ready. But it was invisible, so the browser didn't register it as painted. It counted the moment the fade finished. On a slow mobile connection with the animation script loading late, that can be a full second or more after the image was actually ready.

That's the gap between what you optimised and what Google measured.

The fix

The clean route first: in the Squarespace editor, go to Site Styles, then Animations, and set the animation to None. Save. Re-test in PageSpeed Insights. On the sites we've measured this alone moves LCP by somewhere between half a second and two seconds, depending on the connection and how late the script arrives.

If you want to keep animations elsewhere, or if the classes are still applied after turning the setting off (it happens on some templates and on sites that had animations at some point), add this to Design, then Custom CSS:

/* Force Squarespace pre-animation classes visible so LCP registers on paint */
.preFade,
.preSlide,
.preScale,
.preClip,
.preFlex,
.preFade.fadeIn,
.preSlide.slideIn,
.preScale.scaleIn,
.preClip.clipIn {
  opacity: 1 !important;
  transform: none !important;
  clip-path: none !important;
  animation: none !important;
  transition: none !important;
}

Yes, that's a lot of !important. Squarespace's own rules are specific and injected late, and this is one of the few places where winning by force is the right call. Notes:

• Put it in Custom CSS, not in header code injection, so it loads with the site's stylesheet.

• Target only the hero if you want to keep the staggered reveal further down. Wrap the selectors in #sections > section:first-child and you'll keep the effect on everything below the fold, where LCP doesn't care.

• Re-test in an incognito window. Squarespace caches aggressively and your browser will show you the old build for a while.

What to fix next

Once the animation is out of the way, the remaining LCP problems are the ordinary ones. In the order we work through them:

Hero image size. Squarespace serves responsive sizes automatically, but it starts from your upload. Upload at 2500 pixels wide, under 500 KB, as JPEG or WebP. A 6 MB PNG straight out of Figma will be resized, but the resize happens on Squarespace's side and the largest variant is still heavy.

Background videos in the hero. They're the single most expensive thing you can put above the fold. If you must, keep it under 3 MB, under 10 seconds, and give it a poster image so LCP has something to register before the video arrives.

Fonts. Two families, three weights total. Every extra weight is another file blocking text render. Google Fonts loads through Squarespace with display=swap, which is fine; Adobe Fonts via Typekit is slower and worth avoiding unless the brand demands it.

Third-party scripts in the header. Chat widgets, heat maps, tag managers with twenty tags, cookie tools. Each one you put in the header runs before your page renders. Move everything that isn't essential to the footer injection, and ask whether you need it at all. We audit this on every site we take over, and there's usually one script nobody remembers adding.

Block count. Squarespace's own guidance is under 60 blocks per page. Fluid Engine pages with 120 blocks in a grid are slow because every block is a positioned element that the layout engine has to place twice, once for desktop and once for mobile.

Sections with too many images. A gallery of 40 full-bleed images is fine as a gallery block with lazy loading. The same 40 images as separate image blocks in separate sections all load eagerly.

What you can't fix

Squarespace loads a large JavaScript bundle on every page, and you can't defer or split it. A stock 7.1 site with nothing on it will score somewhere in the 70s to low 90s on mobile. That ceiling is real. If your business needs 95 plus on mobile for every page, you're on the wrong platform and we'll tell you which one to use.

For everyone else, the ceiling is not the problem. The problem is the two seconds of fade-in that Google waited through, and now you know why.

Measuring properly

Use PageSpeed Insights, not just Lighthouse in your browser, because it shows field data from real Chrome users alongside the lab test. The field data is what counts for ranking. It updates over 28 days, so after a fix, wait a month before deciding whether it worked.

Test the pages that matter: home, your top three landing pages, and whatever gets the most Google traffic. Not just the home page.

If you'd like us to run the audit and apply the fixes, that's usually two to four hours of work on a site we didn't build, and it's included in every site we do build.

Questions we get

Will turning off animations make the site look worse? Slightly less polished on first load, and nobody but the designer notices. If you want the effect below the fold, keep it there and exempt the first section with the selector trick above.

My score didn't change after the fix. Why? Three common reasons: you tested the lab score in your own browser with a warm cache; the field data in PageSpeed Insights takes up to 28 days to reflect changes; or the LCP element isn't what you think. Open the PageSpeed report, find "Largest Contentful Paint element", and check what it names. It's sometimes a background image in a section, a video poster, or a heading in a large web font.

Does this apply to Squarespace 7.0? Partly. 7.0 templates had their own animation systems, some with the same pre-animation classes and some without. The image, font and script advice applies regardless.

Is a mobile score of 75 bad? It's average for Squarespace and not a ranking penalty on its own. Core Web Vitals are pass/fail thresholds, not scores: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Aim to pass those in field data and stop worrying about the score.

Can you guarantee a score? No, and be careful of anyone who does. We can guarantee that the fixes in this article are applied and that the LCP element renders as early as the platform allows.

Does Squarespace's own image CDN help? Yes. It serves resized, compressed variants per device. It cannot help with an upload that's already 6 MB; it starts from what you gave it.