Skip to content
50% OFF $299 $599
Lock in
§ 2.4.3 ARTICLE

Site speed · mobile

Squarespace mobile speed

Mobile PageSpeed Insights scores trail desktop by 20-40 points on most Squarespace 7.1 sites. Two structural reasons: PSI's mobile test throttles CPU to roughly a mid-range phone and the network to 3G-like3, and Squarespace serves the same DOM on both viewports — so widgets that desktop tolerates, mobile chokes on. Google indexes the mobile version of your site1, so the mobile score is the one that matters for ranking.

Five fixes close most of the gap: responsive image sizing, defer non-critical scripts, audit mobile-rendered HTML, fix tap-target spacing, and remove desktop-only widgets that mobile still loads. Each is a Squarespace-native intervention — no platform switch required.

Why mobile trails desktop on Squarespace

Two structural reasons. PageSpeed Insights' mobile test simulates a throttled CPU equivalent to a mid-range Android phone and a network throttled to 3G-like speeds — far slower than the typical desktop test. Even on the same source HTML, mobile renders slower because the simulated hardware is slower. The second reason is structural to Squarespace: the platform serves the same DOM on mobile and desktop, so every script loaded on desktop is also loaded on mobile, where the cost is much higher.

The gap is usually 20-40 PSI points. A homepage that scores 92 desktop typically scores 55-70 mobile. The desktop score reflects what the page can do; the mobile score reflects what the page actually does for most visitors. Google's mobile-first indexing1 means the mobile version is what gets crawled and indexed, so the mobile score is the one with ranking impact.

The realistic mobile gap

20-40 pts

typical gap between desktop and mobile PSI scores on an unoptimised Squarespace 7.1 homepage.

Google PSI · 2026-Q1
Same DOM

Squarespace serves identical HTML to mobile and desktop — widgets that desktop tolerates, mobile chokes on.

Squarespace Help · 2026-Q1
Mobile

Google's primary indexing crawl mode. The mobile version of your site is what gets indexed.

Google Search Central · 2026-Q1

Mobile-first indexing — why this matters most

Google's primary crawl mode is mobile. The mobile version of your Squarespace site is what gets crawled, indexed, and ranked. If the mobile version is slow, the ranking signal is degraded — even if the desktop version is fast. The mobile-first switch happened across Search in 2020-2021 and applies to every site by default. Squarespace 7.1's responsive design means the same content is served, but the rendering experience on mobile is what counts.

A subtle implication: if you have widgets that only render on desktop (a sidebar, a complex navigation), Googlebot's mobile crawl does not see them. Make sure any content critical to ranking — H1, primary copy, structured data — renders on mobile. Squarespace 7.1's default templates handle this correctly; custom CSS that hides content on mobile via display: none can accidentally hide ranking signals from Googlebot.

Five mobile-specific fixes

The five fixes that move a Squarespace 7.1 site from 55-70 mobile PSI into the 75-90 range. (1) Resize hero images so the 750w mobile variant ships small. (2) Defer or remove non-critical scripts via Code Injection. (3) Audit mobile-rendered HTML in Chrome DevTools — find what is actually loading. (4) Fix tap-target spacing and font sizes that fail mobile usability audits. (5) Remove or conditionally load desktop-only widgets like complex carousels.

The order matters. Hero image is the LCP element on most pages, and LCP is one of three Core Web Vitals — fixing it first moves the needle most. Script deferral is next because INP is the second Core Web Vital. Tap targets and usability fixes are last because they affect the overall PSI score but not the Core Web Vitals directly.

01. Responsive image sizing

Squarespace's srcset attribute serves a 750w variant to mobile viewports by default. Open Chrome DevTools, switch to mobile emulation, reload the page, and check the hero image's actual URL in the Network tab. The query param at the end — ?format=750w or similar — tells you which variant the mobile viewport got. If the variant is still over 200KB, the source upload is too large. Reduce source dimensions and re-upload.

A typical mobile-optimised hero variant lands at 60-120KB after Squarespace's auto-WebP4. If your mobile variant is 300KB+, the source is probably 4,000+ pixels wide and uncompressed. Resize to 1920px before upload (per the LCP leaf) and the mobile variant gets recomputed at the smaller base.

02. Tap targets and font size

PSI's mobile audit flags tap targets smaller than 48x48 pixels and text smaller than 12px as usability issues. On Squarespace 7.1, the defaults are usually fine, but custom CSS can break them. Open PSI's mobile report > Usability section, and any failing element is named directly. Fix in Custom CSS or in the Style editor — increase the font-size and add padding to the element to reach the 48px tap-target minimum.

CSS Custom CSS — common mobile tap-target fixes 
  .header-nav-item {
padding: 12px 16px;
min-height: 48px;
}
 @media (max-width: 640px) {
p, li {
font-size: 16px;
line-height: 1.55;
  }
}

03. Hidden mobile bloat

The single most under-audited mobile problem on Squarespace 7.1 sites is widgets that render on mobile even though the user cannot see them. A complex desktop hero animation that is set to display: none on mobile via CSS still loads the JavaScript that powers it. Live chat widgets and embedded carousels are the most common offenders. Each adds main-thread work that taxes INP on the mobile viewport. Fix by removing the widget from pages where it does not add value, or by conditionally loading it with a media-query check in JavaScript.

Measure mobile specifically

After applying the fixes, re-run PageSpeed Insights on the mobile tab specifically. Lab Data updates instantly — the Lighthouse simulated test should show LCP, INP, and CLS improvements within seconds of saving your changes. Field Data updates over the 28-day CrUX rolling window. For real-user validation, test on a mid-range phone — an iPhone 12 or Pixel 6 over a real 4G connection — and time the load yourself. PSI's lab numbers are conservative; real-world experience is usually faster than the lab predicts.

A useful sanity check: open the URL in Chrome on your phone and use the built-in Chrome DevTools (remote debugging from a paired Mac/PC). The real-device Lighthouse run uses your actual hardware and your actual network, which is more representative than PSI's simulation. The number will differ from PSI's number — both are valid, but the real-device number is closer to what your users actually experience.

Keep reading · § 2.4