Squarespace Too Slow in 2026? Diagnose Before Migrating

The four things that decide a Squarespace page's speed

Nearly every slow Squarespace route we have opened comes down to one of four things, and three of them are content decisions rather than technical ones. Measurement tells you which. Media weight is the most common single cause, fonts the most commonly overlooked, and injected code the one that breaks the site when you remove it carelessly.

1. Name the problem correctly

“The site is slow” describes five different problems with five different fixes. Decide which one you have before you touch anything: content that arrives late, a page that will not respond to a tap, layout that jumps under the reader, a function that hangs, or a single low score in one simulated test. The last of those is the weakest evidence on the list and the one that starts most migrations.

• ✓
  Slow initial content, measured through LCP and supporting network timing.
• ✓
  Delayed interaction, measured through INP and browser traces.
• ✓
  Unexpected movement, measured through CLS and layout-shift records.
• ✓
  A functional wait, error or failed third-party request.
• ✓
  A low Lighthouse score in one simulated test.
• ✓
  A slow editor rather than a slow site: the dashboard drags while the published page is fine.

These are not interchangeable. Google distinguishes field data, which reflects real users, from Lighthouse lab data, which reproduces a controlled environment. A page can have one without the other.

Core Web Vitals explained sets out what each of those metrics records, and why a website loads slowly runs the same diagnosis without assuming a platform.

2. Check platform and local conditions

Rule out the platform and your own machine before attributing anything to the site. A live Squarespace incident, a browser extension rewriting the page, a saturated home connection or a DNS setup that only affects the custom domain will each produce a convincing slow result that has nothing to do with your content. Five checks, all of which take a minute.

• ✓
  Review Squarespace's status page for a current platform incident.
• ✓
  Use a supported current browser without extensions that alter page behavior.
• ✓
  Compare another device and network.
• ✓
  Test the built-in Squarespace domain and custom domain when diagnosing DNS or domain behavior.
• ✓
  Record the route, date, geography and logged-in or public state.

3. Reduce page weight

Squarespace publishes four specific budgets on its page-size guidance, and they are worth having in front of you before you start deleting things. Verbatim, it says to keep each page to 5 MB or less, that 1 MB is the safest size for cellular connections, to ensure there are no more than 60 blocks per page, and to keep images below 500 KB with a width of 1500px to 2500px.

Those four are the fastest audit available on this platform because every one of them is countable without a tool: open the page, count the blocks, check the largest image. They are vendor guidance, not a guarantee of any particular LCP or Lighthouse score, and a page can sit inside all four and still be slow for a reason further down this list. But a page that breaks them has an explanation before you measure anything, and the 60-block ceiling in particular catches long single-page designs that look fine in the editor and load nothing like it. Use a network trace to confirm which content actually matters on the real route.

• ✓
  Resize and compress images for their rendered slots.
• ✓
  Avoid loading desktop-sized media on a narrow mobile viewport.
• ✓
  Reduce autoplay video, galleries and long media-heavy pages where the business value does not justify them.
• ✓
  Preserve dimensions so media and embeds do not shift the layout.
• ✓
  Prioritize the visible hero or product image and defer below-the-fold content appropriately.

Compress and resize before you upload rather than after. Squarespace generates its own derivative sizes from what you give it, so a 6000-pixel camera original is a larger starting point than the page ever needs. Squoosh and TinyPNG both do the job in the browser on a free tier. Check the result in a network trace rather than by eye: what matters is the size of the file the page actually requests at the viewport you are testing.

Two more controls are worth checking in the editor. Section and image animations add script execution and can delay the point at which content is painted, and they can be turned off in the style settings if the design does not depend on them. Every third-party block you place, whether a social feed, a newsletter widget from another tool, a review carousel or a chat launcher, opens connections to a host you do not control, and each of those can fail slowly. Inventory them and keep the ones that earn their place.

The order to attempt those changes in, and how to verify each one, is set out in our method for speeding up a website. The equivalent exercise on the other major builder is in our diagnosis of a slow Wix site.

4. Simplify fonts

Squarespace recommends using no more than two fonts as a general design rule and notes that all selected fonts must load. Review families, weights, icons and third-party font hosts. Preserve brand and readability while reducing unnecessary requests.

5. Isolate custom code and third parties

Squarespace warns that code injection, embeds, CSS and other custom code can contribute to slow loading and fall outside standard support. Save a copy and remove one item at a time in a safe test context. Include analytics, advertising, chat, scheduling, forms and consent behavior in regression tests.

6. Review redirects and navigation

Squarespace advises reviewing excessive redirect mappings. Trace redirect chains from paid, organic, email and old bookmarked URLs. Update internal and campaign links to their final destinations instead of relying on avoidable hops.

Redirects, metadata and crawlability sit alongside speed in how a page performs in search. We cover the platform controls in what Squarespace gives you to work with for SEO and the relationship itself in how site speed relates to search performance.

7. Compare representative routes

Speed work is accepted per route, not per site, because a home page and a checkout fail in different ways. Test one real example of each template you have, in the state a visitor actually meets it, and carry a non-speed guardrail alongside each one. That guardrail is what stops a faster page from shipping with a broken form or a missing conversion event.

8. Decide whether to stay or migrate

Stay on Squarespace when the platform still does what the business needs and the measured causes are ones you can change. Redesign inside it when the structure is the problem but the way your team publishes is not. Migrate only when a requirement you can name is impractical where you are. A better score on somebody else's demo site is not a requirement.

• ✓
  Stay and optimize when the platform meets feature and editorial requirements and measured issues are controllable.
• ✓
  Redesign within Squarespace when the content structure and experience need simplification but the operating model still fits.
• ✓
  Migrate when the experience, data, integration, workflow or speed control you need is not practical where you are.
• ✓
  Do not migrate solely because another platform produced a better isolated demo score.

If the evidence points to a move, Squarespace compared with a custom website covers the requirements, how a Squarespace migration is scoped and priced covers the inventory, and what a migration does to search visibility covers the risk to manage during cutover.

9. If you do move, plan the extraction early

Squarespace's own export documentation describes a WordPress-format XML file and lists what it leaves out, which as of August 2, 2026 includes store pages, portfolio and several other page types, product data and video. Confirm what it actually produces for your account and your page types before you budget the work, because that list changes. Whatever the export misses has to come out by hand or by script, and on the small migrations we have scoped that extraction has been the largest single line.

• ✓
  Inventory every live URL with its title, description, canonical, headings, images and internal links, and note which pages earn search traffic today.
• ✓
  Extract page copy, blog posts, images at full resolution, product data, forms and any code injection before anything is switched off.
• ✓
  Build the redirect map from old URL to new URL, including any URL you are deliberately retiring, and test it before cutover rather than after.
• ✓
  Check parity on the new build for titles, descriptions, canonicals, structured data and rendered main content while the old site is still live.
• ✓
  Cut over by DNS with the previous site still reachable, and keep a rollback path until the new site is verified in production.

10. Define performance acceptance

A migration scope can include a 90-plus Lighthouse delivery target for agreed representative routes, recorded mobile and desktop profiles, and three consecutive tests per route and profile. It must also preserve accessibility, SEO, analytics and function. Field data is monitored after enough real-user observations exist.

How we run that work is described on our Squarespace migration service page, the tiers are listed on the pricing page, and our project work shows what a completed scope contains.

Primary sources

• Squarespace: reducing page size
• Squarespace: troubleshooting a slow site
• Squarespace status
• Squarespace: exporting your site

Frequently asked questions