How Squarespace Actually Renders a Page
When you hand over a finished Squarespace site to a client, you're handing them something that feels instant. They type the URL, the page appears. But between that keystroke and that appearance, a sequence of events unfolds that directly affects how fast the page loads, how Google evaluates it, and whether the visitor stays or leaves. Most Squarespace designers have a vague sense of this sequence. Few understand it well enough to optimise for it.
This is what actually happens when someone visits a Squarespace site, and why each step matters for the work you do.
Step One: DNS Resolution
Before the browser can request your page, it needs to know where to find it. This means resolving the domain name to an IP address through the DNS lookup process. For a Squarespace site, the domain typically resolves to one of Squarespace's edge servers.
This step usually takes 20 to 100 milliseconds, but it can take longer if the DNS records have a high TTL that's recently expired and needs to be re-fetched, or if the visitor's ISP has a slow DNS resolver. There's not much you can do about this from within Squarespace, but it's worth knowing that DNS resolution is the first measurable event in every page load.
Step Two: TLS Handshake
Every Squarespace site runs over HTTPS, which means the browser and server need to establish a secure connection before any data transfers. This involves a TLS handshake: the browser and server exchange cryptographic keys, verify the SSL certificate, and agree on an encryption method.
Squarespace uses Let's Encrypt certificates and supports TLS 1.3, which reduces the handshake to a single round trip (compared to two round trips in TLS 1.2). On a typical connection, this adds 50 to 150 milliseconds. On a repeat visit, TLS session resumption can reduce this further.
Step Three: The HTML Document
With the secure connection established, the browser sends an HTTP GET request for the page. Squarespace's servers receive this request, determine which page to serve based on the URL, and generate the HTML document.
This is where Squarespace's architecture differs from a static site. Squarespace pages aren't pre-built HTML files sitting on a server waiting to be delivered. They're generated dynamically by Squarespace's application layer, which assembles the page content, layout structure, navigation, and metadata into an HTML document on the fly. Squarespace does cache these generated pages aggressively, so repeat requests for the same page don't trigger a full regeneration. But the first request after a content change, or the first request from a geographic region where the page isn't cached, will be slower.
The Time to First Byte (TTFB) metric measures how long this takes: from the browser sending the request to receiving the first byte of the HTML response. Squarespace's TTFB is generally between 200 and 600 milliseconds, depending on server load, caching status, and the geographic distance between the visitor and the nearest edge server.
Squarespace uses a content delivery network (CDN) to serve pages from servers geographically close to the visitor. If your client's audience is primarily in the UK, most requests will be served from European edge nodes. But Squarespace's CDN configuration isn't something you can control or customise, so your optimisation levers here are limited to ensuring the page content itself doesn't require excessive server-side processing.
Step Four: Parsing the HTML
Once the browser receives the HTML document, it begins parsing it from top to bottom, constructing the Document Object Model (DOM), which is the browser's internal representation of the page structure.
As the parser encounters references to external resources, it makes additional requests. And this is where the critical rendering path becomes important for performance, because not all resources are treated equally.
CSS files are render-blocking. When the browser encounters a <link> tag referencing a stylesheet, it stops rendering the page until that stylesheet has been downloaded and parsed. No CSS means no layout, so the browser waits. Squarespace loads several stylesheets: the base platform CSS, the template CSS, and any Site Styles customisations. These files are concatenated and minified by Squarespace's build system, but they can still be substantial, often 200KB to 400KB of CSS.
JavaScript files are parser-blocking by default. When the browser encounters a <script> tag, it stops parsing the HTML until the script has been downloaded and executed. Squarespace uses the defer and async attributes on some of its scripts, which allows the parser to continue while the script downloads. But not all scripts use these attributes, and third-party scripts (analytics, chat widgets, marketing pixels) almost certainly don't.
Images are not render-blocking. The browser notes their existence and begins downloading them in parallel, but it doesn't wait for images before rendering the rest of the page. This is why a page can appear with its layout and text visible while images are still loading.
Step Five: CSSOM and Render Tree
While the DOM is being built from the HTML, the browser is simultaneously building the CSSOM (CSS Object Model) from the downloaded stylesheets. The CSSOM represents every CSS rule and how it applies to every element in the DOM.
Once both the DOM and CSSOM are complete, the browser combines them into the render tree. The render tree contains only the elements that will actually be visible on screen (so elements with display: none are excluded), along with their computed styles.
This is the step where CSS specificity battles are resolved. Every competing rule for every element is evaluated, and the winning styles are calculated. If your custom CSS is fighting Squarespace's stylesheets (see our article on CSS specificity), this is the moment where that fight is settled. More CSS means more computation, which means a longer time to build the render tree.
Step Six: Layout
With the render tree complete, the browser performs layout (sometimes called "reflow"). This is where it calculates the exact position and size of every element on the page, based on the viewport width, the CSS box model, flexbox or grid rules, and the content dimensions.
Squarespace's Fluid Engine uses CSS Grid under the hood, which means the browser is performing grid layout calculations for each section. These calculations are generally fast on modern hardware, but they become more expensive as page complexity increases. A page with twenty sections, each containing multiple grid-positioned blocks, requires significantly more layout computation than a simple five-section page.
Layout is also where responsive design is resolved. The browser applies media queries based on the current viewport width, recalculating positions for elements that change at different breakpoints. Squarespace 7.1's responsive behaviour involves a substantial amount of layout recalculation because the platform adjusts not just element sizes but grid structures between desktop and mobile views.
Step Seven: Paint and Composite
After layout, the browser paints the pixels. This happens in layers: background colours and images first, then borders, then text, then foreground elements. Complex visual effects like box shadows, border radius, gradients, and transparency require more paint work and more GPU memory.
Modern browsers separate content into compositing layers, which can be rendered independently and then combined. Elements with CSS transforms, opacity changes, or will-change properties get their own compositing layer, which means they can be animated without triggering a repaint of the entire page. This is why CSS animations using transform and opacity are dramatically more performant than animations using properties like width, height, top, or left, which trigger layout recalculation and full repaints.
This is directly relevant to Squarespace designers adding hover effects or scroll-triggered animations via custom CSS. A hover effect that changes transform: scale(1.05) is essentially free in performance terms. A hover effect that changes width and height triggers layout and repaint on every frame, which can cause visible jank on lower-powered devices.
Step Eight: JavaScript Execution
While all of the above has been happening, JavaScript has been downloading and (where not deferred) executing. Squarespace loads a considerable amount of JavaScript: its core application scripts, analytics, video players (for background video sections), gallery lightboxes, form validation, the commerce engine (on sites with products), and various UI interaction handlers.
On a typical Squarespace page, the total JavaScript payload is between 500KB and 1.5MB, depending on the features used. This JavaScript needs to be parsed, compiled, and executed by the browser's JavaScript engine. On a fast desktop with a modern CPU, this takes a fraction of a second. On a mid-range mobile phone on a 4G connection, it can take several seconds, and during that time, the page may appear loaded but be unresponsive to taps and scrolls.
This is what the INP (Interaction to Next Paint) Core Web Vital measures: how long it takes for the page to respond to a user interaction. Heavy JavaScript execution is the primary cause of poor INP scores on Squarespace sites, and unfortunately, you have very limited control over Squarespace's own scripts. What you can control is the third-party scripts you add: every chat widget, analytics tool, marketing pixel, and custom embed adds to the JavaScript execution load.
Step Nine: Lazy Loading and Deferred Resources
Squarespace implements lazy loading for images below the fold, meaning images that aren't visible in the initial viewport aren't loaded until the visitor scrolls near them. This significantly improves initial load time by reducing the number of HTTP requests and the total data transferred on first load.
However, lazy loading creates a tension with Largest Contentful Paint (LCP), one of Google's Core Web Vitals. LCP measures when the largest visible element in the viewport finishes rendering. If your largest above-the-fold element is an image, and that image is lazy-loaded (meaning it doesn't start downloading until the browser realises it's in the viewport), LCP will be slow because the image download is delayed.
Squarespace handles this by attempting to detect above-the-fold images and loading them eagerly (without lazy loading). But this detection isn't perfect, particularly for hero images in full-bleed sections where the image's viewport position depends on the device height. If your client's hero image has a poor LCP score, this is likely the reason, and there's limited ability to override Squarespace's lazy loading behaviour without custom code.
What You Can Actually Control
Given that Squarespace manages the server infrastructure, CDN, HTML generation, CSS delivery, JavaScript framework, and lazy loading behaviour, your optimisation levers are narrower than they would be on a self-hosted platform. But they're not insignificant.
Image weight is the single largest variable you control. A 5MB hero image will dominate load time regardless of everything else. Compress images before uploading. Resize them to no larger than 2500px on the longest edge (Squarespace will serve responsive versions, but it starts from what you upload). Use JPEG for photographs and PNG only when transparency is genuinely needed. The difference between an optimised image set and an unoptimised one can easily be 10MB or more per page, which at mobile data speeds translates to seconds of additional load time.
Third-party scripts are the second largest variable. Every external script you add via Code Injection or embed blocks adds DNS lookups, TLS handshakes, downloads, and execution time. A single chat widget can add 300 to 500 milliseconds to page load. Three or four third-party integrations can push a fast Squarespace site into "slow" territory on mobile. Audit every script and ask whether it's genuinely earning its performance cost.
Page complexity matters more than most designers realise. Each section, each block, each grid cell adds to DOM size, CSS computation, and layout calculation. A ten-section page with intentional, well-structured content will outperform a thirty-section page where half the sections are hidden on mobile but still present in the DOM and still consuming resources. If content isn't needed, remove it. Don't just hide it with CSS.
Font loading is an often-overlooked factor. Each custom font file (particularly if you're uploading multiple weights and styles through the new custom font upload feature) adds to the render-blocking CSS payload. Two font families with four weights each can add 500KB or more. Use only the weights you actually need. Consider using font-display: swap in your custom CSS to prevent fonts from blocking text rendering entirely while they load.
Understanding this rendering pipeline won't change the way your sites look. But it will change the way you build them, because every design decision, from how many sections you use to how large your images are to whether you add that third-party script the client asked about, has a measurable impact on the sequence of events between URL and pixels. Knowing where the bottlenecks are is the first step to avoiding them.
Related Articles
