Landing page load time: how many seconds before you lose your visitors?

You polished the headline, the form, the testimonials — and the conversion rate is still low. Before touching the copy, measure something else: how long the page takes to appear. A visitor who clicks an ad or a Google result arrives with fresh intent and very little patience; if the page takes too long to respond, that intent dissolves before they even see your promise. Speed isn't a technical footnote to copywriting — it's the first line of your sales pitch.

What the studies say about speed and conversion

Two studies, run at very different scales, converge on the same conclusion: the relationship between speed and conversion isn't linear — it collapses past a certain threshold.

• Google (mobile study, Think with Google / SOASTA): bounce probability increases by 32% as load time goes from 1 to 3 seconds, and by 90% at 5 seconds. On mobile, 53% of visitors simply leave a site that takes longer than 3 seconds to load.
• Portent analysed more than 100 million page views across around twenty B2B and B2C sites: pages that load in 1 second convert at an average of 39%, versus 1.9% at 2.4 seconds and only 0.6% at 5.7 seconds — a gap of more than 60x between the two ends of the sample.

The exact figures vary by study and by industry, but the pattern is consistent: every second gained under the 3-second mark pays off proportionally more than the last, and every second lost beyond it costs proportionally more than the last. It's not a curve you can smooth over with good storytelling — a visitor who already closed the tab will never read your headline.

The threshold that actually matters: 3 seconds, not 5

Remember two numbers rather than a full dashboard. Under 1 second: the zone where the page feels instant, where the attention captured by an ad or a Google search arrives intact at your promise. 3 seconds: the hard ceiling — beyond it, more than half of mobile visitors have already left before the page even settles. Between the two, every tenth of a second gained translates into visitors who stay long enough to read your headline. Treating "under 1 second" as the goal and 3 seconds as the line never to cross gives you a clear target, including one you can hand to a developer.

Why so many landing pages are slow

Slowness rarely comes from one big problem: it accumulates, script by script, plugin by plugin.

• Sliders and carousels on the homepage: several full-width images loaded at once, often uncompressed.
• Multiple web fonts pulled from a third-party server, each adding a request and a delay before the text renders.
• Stacked third-party scripts: a Meta pixel, a Google Ads pixel, a chat widget, a heatmap tool, an exit popup — each adds its own network call, sometimes several hundred milliseconds on its own.
• Generic themes and page builders (Elementor, Divi and similar) that load the CSS and JavaScript for dozens of unused features on top of what the page actually displays.
• Unoptimised images: photos exported straight from a camera or a stock library, never resized or converted to a modern format.
• Cheap shared hosting, which responds slowly whenever it shares resources with other sites at the wrong moment.

This is also one of the clearest points in our Next.js vs WordPress for a landing page comparison: a slow WordPress site is almost never a fatality of the CMS itself, but the direct consequence of stacked plugins and a generic theme — a structural problem no one-off tweak fixes for good.

How to measure your page's real speed

Don't trust your own impression when opening the page on your office computer over fibre: that isn't the condition most of your visitors are in. Three checks are enough:

1. PageSpeed Insights (Google's free tool): gives a score and the three Core Web Vitals that matter — LCP (how fast the largest visible element appears), INP (responsiveness to interaction) and CLS (visual stability while loading). The mobile report matters more than the desktop one.
2. GTmetrix or WebPageTest: let you simulate a 4G connection instead of office wifi, and see precisely which resource (image, script, font) is blocking the render.
3. A manual test on 4G, phone in airplane mode then mobile data turned back on: nothing replaces the real experience of an impatient visitor.

The levers that actually make a difference

Roughly in order of impact, from the most rewarding to the most marginal:

1. Images: compress them, resize to the size actually displayed, convert to WebP or AVIF, and defer loading (loading="lazy") for anything below the first screen. This is almost always the fastest win to get.
2. Fonts: stick to one or two families, self-host them instead of calling a third-party server on every visit, and use font-display: swap so text renders immediately in a fallback font while loading.
3. Third-party scripts: audit every tracker and widget. A poorly loaded live chat or ad pixel can add one to two seconds on its own; load them deferred (async/defer) and drop the ones whose data nobody looks at anymore.
4. Static generation: a page pre-built and served from a CDN generally responds much faster than one assembled on the fly by a CMS and its plugins on every visit.
5. Hosting: for a page whose job is to convert, entry-level shared hosting is rarely the right trade-off against the cost of the traffic feeding it.

What not to sacrifice for a few extra milliseconds

Chasing speed can easily go too far: stripping a page of its testimonials, product photos or trust badges shaves off a few milliseconds and loses far more in persuasive power. The goal isn't the lightest possible page, but the fastest page given what it needs to convince — see the 9 sections of a landing page that converts for what should stay. Optimise the weight of images and scripts, not the content that sells.

The shortcut: start from an already fast foundation

The biggest speed win doesn't come from fine-tuning after the fact, but from the technical foundation you choose in the first place. LanderKit templates are pre-generated Next.js pages (no CMS, no plugins, no server call on every visit), with images already optimised and no superfluous script — the most common baseline for clearing 90 on PageSpeed Insights without touching a thing. This matters especially on a single-product ecommerce page like our ecommerce product template, where every visitor who abandons during load is a lost cart — you can test its real-world speed on the live demo. The same logic applies to a high-volume waitlist page like our SaaS waitlist template, where speed directly determines how many signups you collect before launch.

Speed is just one lever of a converting landing page, but it's the one that gates all the others: a perfect form or an irresistible CTA are worthless if half your visitors already left before seeing them. For the full picture, read our guide on 12 concrete levers to increase your landing page conversion rate.

Core Web Vitals CLS: why the elements that move on your landing page are costing you clicks

A button that shifts a couple of centimeters right as the visitor is about to click it, a cookie banner that pushes the whole page down, a headline that changes size once the font finishes loading: this has had an official Google score since 2020, CLS (Cumulative Layout Shift). Here's exactly what it measures, the 0.1 threshold that matters, and how to stabilize a landing page without sacrificing the design.

CLS adds up, over a page's entire lifespan, the magnitude of every unexpected visual shift of an element that was already visible on screen — not the first appearance of content rendering into empty space, but the displacement of an element that already held a stable position. Each shift is weighted by two factors: the fraction of the screen affected by the movement, and the distance the shifting elements travel. A button that drops two centimeters counts for more in the score than a slight few-pixel adjustment on a secondary element. It's the third of Google's three Core Web Vitals, alongside LCP (render speed) and INP (click responsiveness), each of which we cover in a separate article.

The most common causes on a landing page

• Images and videos with no defined dimensions — without a width/height attribute or a CSS aspect-ratio, the browser reserves no space and pushes the following content down the moment the file finishes loading.
• Web fonts that change the text size — a system-font fallback followed by the final font loading in (FOUT) can change the text's width and therefore a block's height, especially on headlines.
• A cookie consent banner injected at the top of the page — if it pushes content down instead of rendering as an overlay, it shifts everything already visible, often right as the visitor starts reading; see our article on the cookie banner.
• Popups and notifications injected after the fact — a welcome popup, a real-time purchase notification, or a live chat widget that opens a few seconds after loading and pushes content down instead of overlaying it.
• Third-party ads and embeds with no reserved slot — an ad iframe or embedded video that only reveals its final size once it has loaded.
• Content dynamically inserted above an existing element — a form error message, a stock alert, or a discount badge added right above the buy button instead of into an already-reserved spot.

Landing page hero image: photo, illustration or screenshot?

The hero image occupies half of your landing page's most valuable screen — the one 100% of visitors see. Human photo, product screenshot, illustration or no image at all: how to choose based on your offer, what research says about faces and image memorability, and the most common mistakes.

The hero image has one job: helping visitors understand faster what the page sells, or for whom. It's not there to decorate, to "dress up" the page, or to win an art direction award. The test is simple: if you replace your image with a gray rectangle, does the page lose meaning? If the answer is no, the image isn't working — it's merely occupying the page's most expensive real estate. This message-carrying role has long been documented: a 1984 study by Terry Childers and Michael Houston in the Journal of Consumer Research on the picture-superiority effect shows that content presented visually is better remembered than the same content presented as text alone — provided the image carries the meaning rather than vaguely accompanying it. An image that shows the product or the outcome makes the offer memorable; a generic mood image makes nothing memorable at all.

The most expensive mistakes

• The recognizable stock photo — handshake, smiling team in a meeting: the visitor has seen it elsewhere; it signals interchangeability and damages credibility.
• The hero carousel: nobody waits for the second slide, every rotation steals attention from the message, and the page weight adds up.
• The oversized image: an uncompressed hero image delays rendering of the only screen everyone sees — it's almost always the page's LCP element, the one Google measures (see our article on page load speed).
• Text baked into the image: unreadable on mobile, invisible to screen readers and search engines — the message belongs in the HTML, not in pixels.
• The image that contradicts the headline: a "simplicity" headline over a cluttered interface screenshot — visitors believe the image, not the copy.

Which typeface should you choose for a landing page that converts?

A typeface acts before it's even read: it sets a brand personality, and its legibility shapes how much effort the reader expects an action to take. Two studies — one in marketing, one in cognitive psychology — explain why a landing page's font choice is not a cosmetic detail, and how to settle it.

The headline, the arguments, the form labels, and the call-to-action button text all pass through a typeface before reaching the visitor — and that choice acts twice, independently of the message it carries. First by installing a perceived personality before a single word is even read: a study by Pamela Henderson, Joan Giese, and Joseph Cote, published in the Journal of Marketing, analyzed 210 typefaces across 24 design characteristics and shows they cluster into six perceived dimensions — elaborate, harmony, natural, flourish, weight, compressed — that trigger measurable, reproducible brand impressions (Henderson, Giese & Cote, 2004). Second, by modulating the perceived effort of the action that follows, as the rest of this article shows.

Where the fluency effect matters most on your page

• The CTA button text: a decorative font on "Book my call" adds reading friction at the exact moment it's most costly.
• Form labels and messages — see our guide to form microcopy: a hard-to-read font compounds the anxiety already documented around a required field.
• Reassurance blocks (guarantee, FAQ, disclaimers): these are the ones that should feel the easiest to process, not the most stylish.
• The main headline, by contrast, tolerates — and sometimes calls for — a more crafted typeface: it sets brand personality before reading effort becomes relevant.

Preconnect, preload, dns-prefetch: preparing connections before the browser needs them

Before a browser can download a single file, it has to resolve the domain name, open a TCP connection, and negotiate TLS encryption — three invisible network round trips, repeated for every third-party domain the page calls (a font, a chat widget, a video, a payment script). The dns-prefetch, preconnect, and preload resource hints let you get that work done before the browser even discovers it needs it. Used well, they shave hundreds of milliseconds off LCP; used carelessly, they slow down the very page they were meant to speed up.

<link rel="dns-prefetch"> only resolves the domain name ahead of time — the cheapest of the three, a few tens of milliseconds saved, with no notable side effect. You can apply it broadly, across every known third-party domain on the page, with little risk. <link rel="preconnect"> goes further: DNS, TCP handshake, and TLS negotiation, all at once. The gain is bigger — you remove up to two full network round trips from the critical path — but so is the cost: the connection stays open, using browser memory and CPU, and if no request uses it within the next few seconds, all that work is wasted. <link rel="preload"> is different in nature: it doesn't prepare a connection, it downloads a specific resource (a font file, an image, a script) at high priority, before the browser would otherwise discover it in the HTML or CSS.

Where it actually matters on a landing page

• A Google Fonts typeface that isn't self-hosted — every visit triggers a connection to fonts.googleapis.com, then fonts.gstatic.com; a preconnect to both domains shortens the delay before the font file starts downloading (self-hosting, which we cover in our article on Google Fonts and GDPR, removes the problem entirely).
• An embedded Stripe payment button or widget — the payment script loads from js.stripe.com; a discreet dns-prefetch spares the visitor a DNS lookup delay right when they click the purchase button.
• A YouTube or Vimeo video used as a hero background — several third-party domains (player, video CDN, tracking) get added at once; here it's often better to defer loading the iframe itself rather than piling on preconnects, as we cover in our article on loading speed.
• A live chat widget — Crisp, Intercom, or similar tools load their own script from a separate domain; worth preconnecting if the widget needs to appear quickly, as we cover in our article on live chat.
• The Meta or GA4 tracking pixel — these scripts almost never need a preconnect: they don't block anything visible, and deferring their execution has no impact on LCP, as we detail for the Meta pixel and GA4 tracking.

Core Web Vitals LCP: why your landing page's first screen takes too long to appear

LCP (Largest Contentful Paint) measures how long it takes for the largest visible element on the first screen to fully render — on a landing page, that's almost always the hero image or the main headline. Past 2.5 seconds, Google rates the experience as poor, and so does the visitor: they've already started wondering whether the page has finished loading. Here's exactly what LCP measures, why it tends to drag on image-heavy pages, and how to fix it without sacrificing the design.

LCP is one of Google's three Core Web Vitals, alongside CLS (visual stability) and INP (responsiveness to interactions), which we cover in a separate article. Unlike total load time or the browser's onLoad event, LCP only cares about one specific moment: when the largest element in the visible viewport becomes fully rendered. A site can keep loading scripts, fonts, or sections further down the page for several seconds after a good LCP — that no longer affects this particular score, though it can still affect INP or the overall feel of the page.

The most common causes on a landing page

• A hero image that's too heavy or badly formatted — a JPEG or PNG exported at desktop screen size, served as-is to mobile, or without modern compression (WebP, AVIF).
• A server response time (TTFB) that's too slow — an overloaded shared host, no caching, or server-side rendering computed fresh on every request instead of a statically pre-generated site.
• Render-blocking resources — CSS or fonts loaded synchronously before the browser can paint anything to the screen at all.
• An image the browser discovers too late — loaded via JavaScript, set as an un-preloaded CSS background, or hidden behind a carousel that only reveals the first image after a script runs.
• A web font that delays the headline's render — if the headline is the largest visible element and a custom font blocks its rendering, the font — not the image — is what determines your LCP.

Core Web Vitals INP: why a fast-loading landing page can still lose customers

A landing page can paint its hero in 800ms and still leave a visitor clicking the CTA with nothing happening for half a second. That gap has had a name since March 2024: INP, the Core Web Vital that measures interactivity, not loading. Here's what it measures, the threshold that matters, and how to improve it on a Next.js landing page.

INP is a Google ranking factor, but its most direct impact remains behavioral. A study by Ioannis Arapakis, Souneil Park and Martin Pielot presented at CHIIR 2021 (see the study) shows that response delays exceeding 7 to 10 seconds on mobile trigger a measurable rise in perceived frustration and fatigue — and that tolerance drops even faster once the interaction repeats without a smooth response. An older but still-cited study by John Hoxmeier and Chris DiCesare presented at AMCIS 2000 found that a lengthening system response time lowers perceived satisfaction in a near-linear way, well before any full-abandonment threshold. Neither study looks specifically at sales landing pages, but the mechanism they document — frustration rising as the gap between action and visible response widens — is exactly what INP sets out to quantify on today's web.

What tanks INP on a landing page, in practice

• Third-party scripts loaded eagerly — Meta pixel, Google Ads tag, live chat: when they fire on click rather than in the background, they block the main thread at the exact moment the visitor is interacting. See our article on the Meta pixel and Conversions API to run them server-side instead of in the browser.
• JavaScript-animated carousels and sliders, whose event handlers recompute positions on every interaction — often costlier than they look, as detailed in our article on carousels on a landing page.
• Overly heavy form validation, when every keystroke triggers a full field re-validation instead of a targeted check.
• Third-party chat and pop-up widgets that initialize on load and then intercept subsequent clicks while still hydrating.
• Long JavaScript tasks over 50ms that hog the main thread — usually a poorly split bundle rather than a single identifiable culprit function.

Optimizing landing page images: formats, weight, and load order

On a landing page, images almost always account for the bulk of the downloaded weight — more than the HTML, CSS, and JavaScript combined. They're also where you gain the most, fastest: picking the right format, serving the right size, compressing properly, and loading in the right order is often enough to flip a PageSpeed score without touching the design or the copy.

The patience budget is short. A study by Fiona Nah published in 2004 in Behaviour & Information Technology measured users' "tolerable waiting time" for retrieving information: it sits at around 2 seconds, and visual feedback during loading noticeably extends that tolerance (see the study). Two seconds is roughly what a single photo exported straight out of a camera takes to arrive over an average mobile connection.

Choosing the right format: the decision table

TTFB: the server response time that sinks your landing page before the first pixel

Before the browser renders a single pixel, it waits on the server: that's TTFB, time to first byte. A slow TTFB eats into the time budget of every metric that follows, LCP first, often without anyone ever measuring it directly. What it actually measures, what research says about its business impact, and how to reduce it without touching the design.

The gut feeling that "slow is annoying" isn't enough to convince a client or a stakeholder to prioritize something this technical — the research is more precise. In a foundational study published in 2004 in Behaviour & Information Technology, Fiona Fui-Hoon Nah measured how long users tolerate waiting before abandoning a page: past roughly two seconds with no loading feedback at all, attention drops off and abandonment becomes likely (Nah, 2004). More recently, a study by Wojciech Stadnik and Zdzisław Nowak on a real e-commerce platform running Magento established a direct, measurable link between average page load time and observed conversion rate, drawing on real-world Google Analytics traffic data rather than lab tests (Stadnik & Nowak, 2018). TTFB is only one component of total load time, but it's the first one: any delay accumulated here carries through fully into every metric that follows.

Common causes of a slow TTFB on a landing page

• Overloaded or geographically distant shared hosting — a server handling hundreds of sites at once, or located far from the page's actual audience (geo-targeted ad traffic, for instance), adds compounding network latency and queuing time.
• Rendering generated fresh on every request — a CMS or framework that rebuilds the page dynamically (database queries, API calls, template assembly) instead of serving an already-ready static file.
• No caching or CDN — without edge caching, every visitor triggers the full processing cycle on the origin server, even when the content hasn't changed since the last visit.
• Cold-start serverless functions — an on-demand function architecture can add several hundred milliseconds on the first calls after a period of inactivity, if the main page depends on that kind of function instead of being pre-generated.
• Excessive plugins or middleware — on a general-purpose CMS, every active plugin (analytics, popups, server-side A/B testing, personalization) adds processing before the response is sent.

Landing pages on a slow connection: designing for 3G, data-saver mode, and poorly covered areas

A Meta campaign for a local tradesperson runs on a Saturday morning: some of the clicks come from a van parked in a rural area, on weak 4G or backup 3G. That visitor isn't going to wait for 3MB of JavaScript and full-resolution images to load before seeing the phone number. What research says about how tolerant mobile visitors are to delays, and what, very concretely, keeps a landing page usable on a slow or unstable network.

A study by Ioannis Arapakis, Souneil Park, and Martin Pielot, published in 2021 at the ACM CHIIR conference, measured how real mobile users reacted to ten controlled latency levels, from 337ms to about 13 seconds. First finding: mobile visitors turn out to be roughly four times more tolerant of delay than desktop users measured in comparable work. Second finding, more useful for an ad-driven landing page: past a threshold of 7 to 10 seconds, that tolerance collapses — participants reported feeling markedly more tense, frustrated, and ready to give up. A mobile network forgives more than you'd think, but only up to a precise point, beyond which the wait turns into a memorably bad experience rather than a minor annoyance.

What to actually adapt on a landing page

• Responsive WebP/AVIF images, served at the right size via srcset instead of a single high-resolution image resized in CSS — see our guide on optimizing landing page images.
• No autoplaying hero video when Save-Data is on or effectiveType reports "2g"/"3g" — fall back to the poster image, without losing the intent covered in our article on video in landing pages.
• Lazy loading below the fold, paired with skeleton screens rather than blank space that reads as a broken page while data is still being fetched.
• Avoiding heavy JavaScript carousels and widgets above the fold — our comparison on carousels on landing pages already covers why they cost more than they return; on a slow network, that cost only grows.
• preconnect/preload reserved for truly critical resources — on a high-latency connection, every extra connection opened too early delays the rest; see our guide on preconnect and preload.
• Live chat and third-party widgets loaded deferred, never in a blocking way, as covered in our article on live chat — a slow-to-respond third-party script can hold up the rendering of everything else on the page.

PageSpeed Insights, Lighthouse, GTmetrix: why the speed scores never agree

PageSpeed Insights reports 45 on mobile, GTmetrix shows 92 for the same URL, and local Lighthouse in Chrome climbs to 98. Three tools, three contradictory verdicts on the same landing page — and none of the three is lying. Here's what each one actually measures, why the numbers diverge, and which one to look at to decide what to fix.

Lighthouse (whether it runs in Chrome DevTools, from the command line, or behind PageSpeed Insights) always does the same thing: it loads the page once, in a controlled environment, with a simulated network and CPU following a fixed profile. This is called lab data — reproducible, useful for before/after comparisons, but coming from a single synthetic load. PageSpeed Insights also shows field data: the metrics actually measured on your real Chrome visitors over the past 28 days, aggregated by Google through the Chrome User Experience Report (CrUX) and shown at the 75th percentile, as we detail in our article on LCP. These are two separate blocks in the same report: the numeric score (0 to 100) comes only from the lab run, while the "Good / Needs improvement / Poor" verdict on the Core Web Vitals relies on field data whenever enough traffic exists. A page can therefore show a high lab score and, right below it, a red badge on the real-world LCP — the two numbers coexist without contradicting each other, they simply answer different questions.

A simple method to stop chasing a number

1. Pick a single lab tool for your before/after comparisons on a given change (always Lighthouse, or always GTmetrix with the same settings) — comparing yesterday's GTmetrix score to today's PageSpeed Insights score means nothing.
2. Run three passes, not one, and use the median rather than the first number shown: this filters out most of the noise tied to the machine's load at that moment.
3. Once the site is live with real traffic, shift your attention to Search Console's "Core Web Vitals" report: it's the only measurement that matters for SEO and the only one that reflects your actual visitors.
4. Never treat 100/100 as a goal in itself: beyond each metric's "Good" threshold (2.5s for LCP, 0.1 for CLS, 200ms for INP), the extra points have no measurable effect on ranking or on conversion.
5. Treat a 3-to-5-point gap between two runs of the same tool as noise; a gap of 20 points or more signals an actual change worth investigating.

The Speculation Rules API: making the click on a landing page's CTA truly instant

A visitor clicks "Book a demo" or "Join the waitlist," and waits a beat while the next page loads — a few hundred milliseconds, enough to introduce a moment of hesitation. Next.js's prefetch already downloads that page's data ahead of time, but not its render. Chrome's Speculation Rules API goes a step further: it executes and paints the target page in the background before the click happens, so the navigation feels like it takes no time at all.

Two trigger levels, two levels of risk

• "moderate" (on hover or pointerdown): the prerender only fires once the visitor shows a real intent to click — the mouse hovers the link, or a finger touches the screen before release. This is the safest setting for a landing page: the number of pages prerendered for nothing stays low, and the time saved already covers most of the perceived delay.
• "eager" (as soon as the link appears on screen): the prerender starts as soon as the call-to-action button enters the viewport, without waiting for an intent signal. The time saved is maximal if the visitor does click, but the cost in wasted bandwidth and server requests climbs quickly if many visitors never click — best reserved for pages where the click-through rate on that specific link is already known to be high.

The idea of guessing ahead of time what a visitor will ask for, to serve it faster, isn't new: as early as 1995, a study by Azer Bestavros, presented at the ACM CIKM conference and focused on using speculation to reduce server load and service time on the Web (see the study), already laid out the central trade-off of any predictive preloading strategy: anticipating a request the visitor never actually makes consumes bandwidth and server resources for nothing, and that cost grows with the number of speculated pages. On a landing page, that trade-off plays out concretely: every URL added to the speculation rules is a page potentially loaded, executed, and rendered for nothing if the visitor doesn't click — which is why it pays to keep the list limited to the exact conversion path rather than speculating on every link on the page.

bfcache: what actually happens when a visitor hits "back" from your landing page

A visitor clicks "Pay" or "Book a slot," leaves your landing page for Stripe or Calendly, then hits back. A single HTTP header decides what happens next: either the page reappears instantly, scroll position and form intact, or the browser reloads everything from scratch. That's bfcache — and on Next.js, it's easier to break than you'd think.

A study by Lara Catledge and James Pitkow, run at Georgia Tech on an instrumented version of the XMosaic browser and presented in 1995 at the 3rd International World Wide Web Conference (see the study), tracked 107 users for 21 days and measured how their navigation actions actually broke down: clicking a hyperlink came first at 52%, and the back button followed immediately at 41% — ahead of every other way of navigating, typed URLs included. That number predates online payment redirected to a third-party domain, Calendly booking links, or Typeform forms embedded via external iframe — all the steps that, on a modern landing page, deliberately send the visitor elsewhere before bringing them back. Going back isn't an occasional shortcut here: it's a predictable, frequent part of the conversion path itself.

The other common blockers, independent of the framework

• An unload event listener — often inherited from an old chat widget or analytics snippet — disables bfcache on desktop in Chrome and Firefox. The side-effect-free alternative is the pagehide event, which covers the same use cases without blocking the cache.
• An open WebSocket connection or an in-flight IndexedDB transaction at the moment the visitor leaves the page — typical of a live chat widget that keeps its connection alive in the background.
• A beforeunload confirmation ("are you sure you want to leave this page?") added to a multi-step form to prevent lost input: useful for the visitor, but worth testing specifically, since browsers handle this case differently from a plain unload.

Cache-Control and CDN: the caching strategy for a Next.js landing page on Vercel

A well-cached landing page loads in a few tens of milliseconds without ever waking up the server. Misconfigured, that same cache serves yesterday's promo to everyone — or worse, one visitor's response to another. What Next.js actually does on Vercel, and how to set Cache-Control without getting caught out.

Three caches, three jobs

• Browser cache — stored on the visitor's device, it skips a full network request on a repeat visit. Controlled by the Cache-Control header returned by the server (max-age).
• CDN cache (Vercel Edge Network) — a copy of the response placed on geographically distributed servers, between the browser and the server function. It's what lets a visitor in Lyon receive the page from Paris instead of the region where the app is actually deployed. Controlled by the s-maxage directive, distinct from max-age.
• Next.js's internal cache — the Full Route Cache (the HTML and React payload already generated for a static route) and the Data Cache (the result of a server-side fetch). This layer decides whether a page is regenerated on every request or served as-is from the last build.

The point of caching isn't just the number shown in a measurement tool: it's crossing psychological thresholds documented for over half a century. In a foundational 1968 study still widely cited in software ergonomics, Robert B. Miller ("Response Time in Man-Computer Conversational Transactions") identifies three tiers: under 0.1 second, a response is perceived as instantaneous; under one second, a sequence of actions still feels continuous, with no break in concentration; past ten seconds, attention drifts away. A response served from Vercel's CDN cache is measured in tens of milliseconds; a response that has to go through a server function, a cold DNS lookup, and a TLS handshake can easily exceed a second on a first load. That's not a cosmetic nuance: it's the difference between a page that "responds" and a page that "loads."