To improve Squarespace page speed, reduce the work your visitors' browsers must do before the page becomes useful. Start with the main image or text that appears late, then investigate oversized media, crowded layouts, fonts and third-party integrations. The right change depends on the request or rendering work causing the delay.
These 11 practical changes focus on things a Squarespace site owner can control. You can make a gallery lighter, replace an unnecessary player or remove an abandoned tracking script. You do not need to rewrite the platform's core files to begin.
Measure a public page first, change one plausible cause, then check both speed and functionality. A faster-looking homepage is not a successful fix if the booking form or product options stop working.
Find the bottleneck on the public page
Open the published URL while logged out of Squarespace, or use a private window. Test the page visitors actually enter, not the editing interface. Start with a valuable landing page and one example of each different layout, such as a gallery, product page and blog archive.
Run PageSpeed Insights for mobile and desktop separately. Its real-user section and simulated Lighthouse run describe different evidence. Google's PSI documentation explains that field data covers the previous 28-day collection period. Check whether the report describes this URL or the whole origin. If there is insufficient field data, record it as unavailable.
Use the diagnostics to choose a change:
| What you observe | What to inspect next | Likely owner-controlled action |
|---|---|---|
| The main image or heading appears late | The reported LCP element and its loading timeline | Simplify the hero, its asset or its font |
| A large amount of image data transfers | Network requests sorted by size | Resize uploads, verify format or reduce gallery content |
| Taps on navigation or forms respond slowly | Interactions and long tasks in a performance recording | Investigate optional scripts or excessive layout work |
| The page jumps as content arrives | The images, embeds or fonts behind the shift | Reserve layout space or simplify the responsible component |
| The first document response is slow | Redirects and the document request timing | Remove avoidable navigation hops; distinguish platform delays |
In the browser's Network panel, reload with the same cache setting and sort requests by size. Record the largest relevant asset and its URL. Keep transferred bytes separate from an uncompressed resource-size figure; the two numbers can differ.
Our PageSpeed Insights guide explains those report distinctions in more detail. A low score is a starting point for investigation, not evidence that every warning can be fixed in the Squarespace editor.
1. Simplify the first screen around its main content
Find the element identified as Largest Contentful Paint before redesigning the hero. It might be a photograph, a background image or a large block of text. Those cases need different follow-up work.
If a carousel, reveal effect or layered presentation keeps the important content from appearing promptly, try a simpler first screen: a clear heading, one relevant image and the main action. Move secondary slides or promotional material below that initial message. This changes what must become ready first; compressing a file alone cannot remove every rendering delay.
Google's LCP guidance separates resource discovery, downloading and the delay before the element is displayed. Use that distinction when reviewing the timeline. Do not add a blanket lazy-loading script that postpones the very image visitors need immediately.
For example, a photography homepage could open with one representative wedding image and a portfolio link instead of several competing galleries. Treat the simpler design as a hypothesis. Retest the same URL and confirm that the intended heading or image becomes visible sooner without hiding the photographer's main message.
2. Resize and compress images before uploading
Keep the original photograph, then create a web version that suits its actual placement. A wide banner needs more detail than a small testimonial portrait. Avoid uploading a full camera export for a small display, but do not enlarge a small source just to reach a particular pixel count.
Squarespace's image formatting guide recommends uploads of 500 KB or less for loading performance and creates responsive image versions. That recommendation is different from the maximum upload size, and it does not mean every image must have identical dimensions.
Use this replacement workflow:
- Identify a large image request on the slow page.
- Resize and compress a copy of the source while retaining acceptable detail.
- Replace the image in the corresponding block or background.
- Check its crop, sharpness, meaningful alt text and click destination on the published page.
- Reload and compare the actual downloaded image response with the previous one.
Do not judge success only by the file on your computer. The page can serve a responsive rendition, or another block may still reference an older asset. Match the request URL to the visible image before deciding the replacement worked.
3. Keep Squarespace's WebP delivery enabled
Check the Image Settings panel before spending time manually converting every photograph. Squarespace's current page-size guidance says it automatically displays images in WebP unless that option has been disabled.
If it is disabled, review why, enable it where appropriate and inspect a published image request. Check the response's media type, transferred size and appearance. A URL filename or the extension of your uploaded original is not enough to establish the format delivered to a visitor.
WebP delivery and upload compression solve different parts of the task. Keep your source files reasonably sized even when the platform generates another format. Likewise, changing a filename from .jpg to .webp does not convert the image.
Use a photograph with texture, a transparent graphic and an important product image when checking the result. Keep the setting only after confirming that those images still look correct; do not promise the same percentage saving for every asset.
4. Replace decorative GIFs with still images
A looping graphic may transfer much more data than a single still frame. If the motion adds decoration rather than information, replace it with a well-chosen static image or an existing native text-and-shape treatment.
Start with animated media that appears on several pages, such as a decorative banner. Compare the original request with the replacement, then check that the new asset communicates the same message. Hiding the GIF behind another element does not establish that its request has stopped.
For a product demonstration where movement matters, keep a clear still preview and give visitors a deliberate way to open the demonstration. Do not turn an informative demo into an unexplained static frame merely to reduce bytes.
This is an asset decision, separate from the first-screen layout change above. Apply it to the animated file identified in the page's requests, rather than assuming every transition or visual effect is the cause of a slow page.
5. Turn large galleries into curated previews
Use a landing-page gallery to help visitors choose what to explore. Keep the larger collection on a relevant gallery page, with a clear link from the preview.
For a wedding photographer, that could mean a small selection on the homepage, separate wedding and engagement portfolios, and individual stories for visitors who want the full set. The benefit comes from removing unnecessary work from the first page, not from making the remaining photographs inaccessible.
Squarespace recommends limiting a gallery to 50 images. Treat that as an upper recommendation, not a target to fill or proof of a fast page. A smaller gallery can still be heavy when each image is large or an external widget supplies the presentation.
Compare the published page's image requests before and after the change. Scroll through the preview and follow its links. Check that visitors can still reach every important collection and that the next page does not simply recreate the same overloaded experience.
6. Remove blocks that do not serve the page's task
Review a slow page as a sequence of visitor decisions. Repeated testimonials, duplicate calls to action, empty decorative blocks and unrelated sections can make a simple page unnecessarily complicated.
Squarespace recommends no more than 60 blocks per page in its page-size guide. That is not a Google ranking threshold. More importantly, Google's INP optimization guidance explains that a large DOM can increase rendering work. The number and behavior of elements matter alongside the files they download.
Keep the content needed to understand and complete the page's main task. Move a genuinely different topic to a useful page and link to it. For example, a service landing page can summarize the service and lead to a separate detailed process page without repeating the full company history below the booking form.
Delete or rebuild redundant blocks in the editor rather than merely hiding them with custom CSS. Hiding content does not demonstrate that its resources or markup were removed. Then inspect the public result, navigate with a keyboard and confirm that the form or main action remains easy to find.
7. Show excerpts on the blog landing page
A blog archive should help readers choose a post. It rarely needs to display the full text and media from several long articles before someone chooses one.
Use Squarespace's blog excerpts and verify that the archive layout displays them. On version 7.1, the documented editing flow is:
- Open Pages, choose the blog page and open Blog Content.
- Open a post's settings from its menu.
- Add the summary in the Excerpt field on the Content tab and save.
- Check the published blog landing page and its layout settings.
Version 7.0 uses different controls, and excerpt display depends on the template. Adding summary text alone does not prove the archive stopped showing full posts. Follow the matching version and display instructions if the excerpt does not appear.
Keep each individual article complete. On the archive, confirm that titles, preview images and Read More links open the right post. Compare its media requests with the previous archive; the intended change is a lighter listing, not shorter articles everywhere.
8. Replace optional video players with click-through previews
An embedded player can request scripts and other resources before anyone watches the video. For a nonessential homepage video, a small preview image linked to the video or a dedicated viewing page can avoid loading that player on the landing page.
Add a clear caption such as “Watch the studio tour,” and make the image or adjacent text a working link. Visitors should understand where the link goes and how to access the video. Keep the preview reasonably sized, with an appropriate aspect ratio so its arrival does not push surrounding content around.
For a player that must open inside the page, an interaction-based loader is another option when implemented and checked properly. Chrome's facade guidance explains that mechanism and its functionality tradeoffs. A custom thumbnail by itself does not prove the player has been deferred.
Reload with Network recording before clicking the preview. Check whether the expected player requests are absent, then follow the link or start playback. This is particularly useful when a page has several optional videos; embedding them through another service does not automatically make them cost-free.
9. Reduce the fonts and styles actually used
Inspect font requests before replacing your typography. A branded heading font may be worth keeping, while an unused custom family or several decorative styles add little to the page.
On Squarespace 7.1, review Site styles > Fonts and the heading, paragraph, button and miscellaneous categories. Use a coherent font pack or a smaller set of deliberately chosen styles. The current font guide also explains how built-in font packs can avoid Adobe Fonts loading. Version 7.0 has different font controls.
Do not assume a font pack means no web-font downloads. Likewise, five weight settings do not necessarily mean five files: variable fonts and the styles actually used affect the requests.
Google's font guidance connects delayed font loading with delayed text rendering and potential layout shifts. After simplifying, check the downloaded faces, the first heading, buttons and navigation. Test accented characters or other scripts your site uses. Keep the new typography only if it remains legible, on-brand and visually stable; smaller files alone are not the whole outcome.
10. Remove or narrow unnecessary third-party code
List the integrations you have added: chat, booking widgets, review feeds, analytics, advertising tags and presentation plugins. For each, record its purpose, where it is installed and who owns it. Look for abandoned tools, duplicate installation through two different methods, and a page-specific widget loaded across the entire site.
| Integration | Useful question before changing it |
|---|---|
| Booking widget | Is it needed on every page, or only the booking page? |
| Analytics or advertising tag | Was the same tag installed directly and through another integration? |
| Social or review feed | Does live content add enough value to justify its initial-page requests? |
| Old presentation plugin | Is its effect still used anywhere? |
Squarespace's code injection documentation distinguishes global header/footer injection from page-specific code. Availability depends on the plan and site context. Where supported, put optional page-specific work only where it is needed, following the integration's instructions.
Save the original configuration before editing. Remove one understood duplicate or unused integration, then retest its affected pages. Moving a script into the footer does not automatically make it asynchronous, and blindly adding defer can break dependencies.
Check forms, bookings, product options, consent choices and the events your business relies on. Keep required consent controls. Do not remove Squarespace's own bundles just because a report labels some JavaScript unused; separate owner-installed code from platform-managed assets before acting.
11. Link directly to final URLs instead of redirect chains
Check the links people use to reach the slow page, including menus, homepage buttons and campaign destinations you control. When a link points to an old address that redirects again, update the link to the final intended URL.
For example, a fictional route chain might be /old-services → /services → /consulting. A current homepage button can point straight to /consulting, while the old address keeps an appropriate redirect for existing bookmarks and external links.
Squarespace's URL mappings guide explains its permanent and temporary redirect rules. Preserve necessary migration mappings. Do not delete old-URL protection, rename working pages or replace every temporary redirect with a permanent one merely to reduce a report's redirect count.
Inspect a fresh navigation or the Network log with requests preserved. Verify each status and destination, check that the final page exists and confirm that relevant campaign parameters still arrive. This change shortens an avoidable part of the journey; it does not eliminate the platform's own server response time or make unrelated images faster.
Verify improvements without breaking the site
After each meaningful change, repeat the same public-page check with the same device profile, cache conditions and testing method. Use several comparable runs when one result looks unusual. Compare the metric or request you intended to change, then inspect navigation, media, forms and any sales or booking flow affected by that change.
Keep a record you can use again:
| Field | What to record |
|---|---|
| Page and context | Full URL, template, date, device and lab/field source |
| Bottleneck | LCP element, large request, slow interaction or layout shift |
| Change | Exact block, image, font, link or integration edited |
| Before and after | Comparable measurements or saved request details, without mixing URL and origin data |
| Functional check | What still works, what changed and any reason to restore the original |
| Follow-up | When to review later visitor data and who owns unresolved platform work |
Do not expect historical field data to reset immediately after an edit. Revisit it as the reporting window includes more visits to the updated page. Improving one lab run does not establish that every visitor's experience improved, and Total Blocking Time is not a replacement for real-user INP.
For recurring checks, Screpy's Core Web Vitals documentation describes lab-based monitoring of selected project URLs. Screpy is the publisher of this guide. Use those observations to investigate changes over time, alongside suitable real-user evidence; they do not provide visitor-wide INP field data. The page speed monitoring workflow explains how to retain a useful baseline.
If the remaining delay belongs to platform-managed assets or delivery, document the URL, timestamp, device and evidence for Squarespace support. Avoid importing server-cache settings, WordPress plugins or undocumented bundle-removal scripts into a hosted-platform problem.
This is a documentation-based guide, checked against current Squarespace and Google guidance, rather than a benchmark of a specific customer's site. Google's page experience guidance makes the SEO limit clear: good Core Web Vitals do not guarantee top rankings. Improve the pages people use and verify that their tasks remain easy to complete.