Squarespace operates the hosting and core platform, so most site owners should focus on the content and integrations they control. Large pages, oversized media, too many fonts, video embeds, third-party widgets, and custom code can still create slow or unstable experiences.
This guide separates changes available in Squarespace from infrastructure advice that belongs to self-hosted sites.
Measure representative pages
Begin with the live custom-domain URL in a private browser window. Test the home page and the heaviest real templates: a gallery, product, portfolio, event, or long landing page. A light home page does not describe the experience of a media-heavy page.
Use PageSpeed Insights for field and lab context, then open the browser Network and Performance panels. Record:
- transferred bytes and request count;
- the largest image, font, video, and script responses;
- LCP, CLS, FCP, and main-thread work;
- whether field data is URL-level or origin-level;
- mobile and desktop results separately.
Squarespace notes that generic testing tools can report issues that owners cannot directly change in a managed CMS. Treat each audit as a lead to investigate, not a command to install another optimizer. The PageSpeed score guide explains why a stable real-user experience matters more than chasing one perfect lab run.
Reduce page weight and complexity
Squarespace's page-size guidance recommends keeping pages at 5 MB or less, while also noting that smaller pages are safer for cellular connections. That is a platform recommendation, not a guarantee that every page below the limit will be fast.
Use the Network panel to sort responses by size. Then reduce the page deliberately:
- split a page that covers several independent topics;
- use blog excerpts rather than full articles on an index page;
- remove duplicate or decorative sections that do not help the visitor;
- limit gallery items and distribute large portfolios across useful pages;
- replace a wall of embeds with lightweight links or preview images;
- remove hidden blocks that still produce downloadable resources.
Do not split content merely to create more page views. Each new page should have a clear purpose and navigation path.
Prepare images before upload
Squarespace generates responsive image variants, but the source asset still matters. Its current image formatting guidance recommends web-ready dimensions and files of 500 KB or less where possible, and explains that uploaded site images are displayed as WebP unless that option is disabled.
For each image:
- Crop it to the aspect ratio used by the design.
- Resize it for its largest real display size rather than exporting a camera original.
- Compress it while checking visible quality.
- Use WebP where it suits the content and workflow.
- Add useful alternative text when the image conveys information.
- Keep the original file outside Squarespace as a source asset.
Prioritize the image that becomes LCP. A large background image, slideshow, or banner can delay meaningful rendering. Avoid autoplaying a carousel solely to display one important message. On product and gallery pages, remove near-duplicate images and keep the sequence useful.
Do not lazy-load or hide the likely LCP content through unsupported custom code. Squarespace controls parts of its image delivery, so verify the rendered production HTML before copying generic code snippets.
Control video and embedded content
Video players, maps, scheduling tools, social feeds, forms, and reviews can introduce extra origins, JavaScript, iframes, and layout movement. Test a page before and after adding each embed.
For nonessential media below the fold, consider a poster image and a clear link or click-to-load interaction. Spread several videos across relevant pages when that improves the information structure. Reserve space for the final iframe so its arrival does not move surrounding content.
Background video deserves extra scrutiny on mobile. Ask whether motion is essential to comprehension, whether a static image could serve small screens, and whether the media respects reduced-motion preferences. Check bandwidth and battery cost, not only visual polish.
Simplify fonts and visual effects
Squarespace's slow-site guidance recommends limiting the number of fonts. Every family, weight, and style can add a request and delay text rendering.
Use a small typography system:
- one or two font families;
- only the weights used by visible components;
- a system fallback that is reasonably close in shape;
- restrained letter effects and animations;
- no duplicate font loaded by both the platform and custom code.
Visual effects can also create main-thread and rendering work. Remove scroll effects, parallax, animations, or repeated transitions that do not help the task. Test on an actual mid-range phone, where animation cost is easier to notice than on a development machine.
Audit custom code and third parties
Code injection, custom CSS, tag managers, consent tools, chat, analytics, affiliate scripts, and marketing pixels are part of the production performance budget. Squarespace recommends temporarily removing custom code while diagnosing a slow site. Save it safely and change one dependency at a time.
For each script, document:
- its owner and business purpose;
- which pages require it;
- when it loads and whether consent applies;
- its network and main-thread cost;
- how to test its critical behavior;
- how to roll it back.
Do not add async, defer, or a delay wrapper without understanding dependencies. A script that loads faster but breaks forms, consent, commerce, or analytics integrity is not an optimization. Remove stale campaign tags and integrations that no longer have an owner.
Diagnose each Core Web Vital
LCP
Identify the actual LCP element in PageSpeed Insights or DevTools. If it is an image, reduce its transfer size and avoid hiding it behind a slideshow or animation. If it is text, inspect font loading and render-blocking custom resources. Platform response time and connection conditions also contribute, but content changes cannot fix a platform incident.
CLS
Reserve space for images, video, embeds, cookie banners, announcement bars, and commerce widgets. Avoid inserting content above what the visitor is already reading. Use the CLS repair guide to distinguish load-time shifts from shifts caused by later interaction.
INP
Test navigation, menus, accordions, product controls, forms, and embedded widgets. Long tasks from custom and third-party scripts can delay feedback. Remove unused scripts first, reduce complex effects, and ask vendors for supported loading options.
Core Web Vitals use field data when available. PageSpeed's Lighthouse run is useful for diagnosis, but it cannot reproduce every visitor, device, network, consent state, or interaction.
Publish with a regression checklist
Before publishing a large redesign, duplicate the site or use the available preview workflow and test important pages and forms. After publishing, compare the same URLs and wait for field trends rather than declaring success from one run.
Verify that:
- high-traffic pages remain within a deliberate page-weight budget;
- hero and product images are cropped, compressed, and appropriately sized;
- galleries, videos, and embeds are limited to what the page needs;
- fonts and weights are intentional;
- custom code has an owner and a rollback path;
- dynamic widgets have reserved space;
- forms, commerce, consent, analytics, and accessibility still work;
- mobile and desktop field trends are monitored separately.
You can compare published site measurements on IndieTools Speed. Use those records to spot change, then return to the exact Squarespace page and resource responsible for the regression.
