Are We Building Websites or Movies? Scrollytelling, SEO and AI Visibility

The Performance Bill: What Heavy JavaScript Costs You in Core Web Vitals

Start with the baseline, because it reframes everything. According to the HTTP Archive Web Almanac 2025, the median mobile home page already ships 632 KB of JavaScript and weighs 2.56 MB in total — and page weight growth is accelerating, up 202.8% over the last decade. The Performance chapter shows the result: only 48% of origins pass all Core Web Vitals on mobile (56% on desktop).

That is the average site. A scrollytelling build adds a WebGL context, a scroll-animation library, and multi-megabyte video on top of it.

Why Animation-Heavy Sites Hit INP Hardest

INP (Interaction to Next Paint) measures how quickly your page visibly responds when a user clicks, taps, or types — good is 200ms or less, poor is over 500ms. Google's own explanation of what breaks it is direct: "An input delay occurs until event handlers start running, possibly caused by factors such as long tasks on the main thread."

A long task is defined as any single piece of JavaScript work that occupies the main thread for more than 50 milliseconds. Scroll-driven scenes, physics, and shader setup produce exactly this kind of work. As web.dev puts it: "When a user attempts to interact with a page when there are many long tasks… the user interface will feel unresponsive, and possibly even broken if the main thread is blocked for very long periods of time."

The Almanac gives this a number: the median mobile page's lab Total Blocking Time is roughly 1,916ms, and it rose 58% year over year. The main thread is getting busier, not quieter.

Why the Cinematic Hero Delays LCP

LCP (Largest Contentful Paint) — good is 2.5 seconds or less — measures when the biggest visible element finishes rendering. Crucially, its official list of eligible elements includes <video> elements and "an element with a background image loaded using the url() function". Your full-bleed hero video or CSS background is your LCP element. And Google notes that "anything that blocks the main thread can also lead to unnecessary element render delay" — so the WebGL bundle you load to power the scene actively delays the scene from appearing.

The CLS Nuance Most Articles Get Wrong

It is tempting to claim "scroll animations cause layout shift." They usually do not. Google's CLS documentation — good is 0.1 or less — is explicit about the fix: "To move elements around, avoid changing the top, right, bottom, or left properties and use transform: translate() instead." A transform-based animation generates no layout shift at all. Your real CLS risk on a cinematic site is late-loading media without reserved dimensions — the hero video that pops in and shoves the copy down.

The Accessibility Bill: Which WCAG Criteria Immersive Sites Actually Fail

This is the part that gets hand-waved, and it should not. WCAG names motion explicitly, and one of the relevant criteria sits at Level A — the baseline, not the aspirational tier.

WCAG 2.2.2 Pause, Stop, Hide — Level A

The criterion reads: "For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it." An autoplaying looping hero video or an ambient WebGL background with no pause control fails this at the lowest conformance level there is.

WCAG 2.3.3 Animation from Interactions — Level AAA

This one describes scrollytelling almost by name. The W3C's understanding document states: "if scrolling a page causes elements to move (other than the essential movement associated with scrolling) it can trigger vestibular disorders," and it does not soften the consequences: "Triggered reactions include nausea, migraine headaches, and potentially needing bed rest to recover."

It is worth being precise: this is a Level AAA criterion, not A or AA. That does not make it optional in spirit — it makes the argument honest. The mitigation is well documented and cheap: honour prefers-reduced-motion, the media query that detects when a user has asked their operating system to "minimize the amount of non-essential motion."

Scroll-Jacking: No Criterion Names It, but It Still Fails

Being accurate here matters, because a lot of SEO content asserts "scroll-jacking violates WCAG [number]" and no such criterion exists. What does exist is more useful. The W3C's ACT rule on scrollable content verifies that scrollable elements "can be reached with sequential focus navigation so that they can be scrolled by keyboard" — mapping to SC 2.1.1 Keyboard (Level A). When your custom scroll container swallows keyboard scrolling, or when SC 2.4.3 Focus Order breaks because tabbing lands on an element the scroll narrative has not "revealed" yet, those are real, citable failures.

Context for how common the basics already are: in the same Almanac chapter, only 31% of mobile sites meet minimum colour contrast requirements, and 67% remove default focus outlines. Most sites are not passing the easy tests. Adding a cinematic layer on top of that is a choice about where you spend a finite accessibility budget.

The Blind Spot: AI Assistants Do Not Execute Your JavaScript

Here is the part I think most teams have not internalised. You can nail Core Web Vitals and rank first on Google, and still be a blank page to the systems answering your customers' questions right now.

The reason is that Google renders JavaScript and the AI crawlers do not. Google's JavaScript SEO documentation describes a three-stage pipeline — crawling, rendering, indexing — and confirms that "once Google's resources allow, a headless Chromium renders the page and executes the JavaScript." (Note the deferral: pages queue for rendering and "may stay on this queue for a few seconds, but it can take longer than that." Google commits to no time bound.)

The AI crawlers appear to do no such thing. In "The rise of the AI crawler" (Vercel, with MERJ, December 2024) — the only public server-log study of AI bot behaviour that exists — the finding is stated flatly:

"The results consistently show that none of the major AI crawlers currently render JavaScript. This includes: OpenAI (OAI-SearchBot, ChatGPT-User, GPTBot), Anthropic (ClaudeBot), Meta (Meta-ExternalAgent), ByteDance (Bytespider), Perplexity (PerplexityBot)."

The mechanism is worth understanding, because it is subtler than "they ignore JS." They download your JavaScript files — the study measured JavaScript at 11.50% of ChatGPT's requests and 23.84% of Claude's — they simply never run them. As the study puts it: "they don't execute them. They can't read client-side rendered content." If your copy only exists after hydration, it does not exist to them.

Meanwhile the study confirms the asymmetry directly: "Google's Gemini leverages Googlebot's infrastructure, enabling full JavaScript rendering." That is the whole uncomfortable point in one sentence — the same page can rank first in Google and be invisible in ChatGPT.

The Honest Caveat: Agentic Browsers Do Render

The strongest counter-argument to my own point, and one I have not seen made: AI agents that drive a real browser execute JavaScript by construction. OpenAI now ships ChatGPT Atlas, "a new web browser built with ChatGPT at its core," with an agent mode that navigates sites on your behalf. Perplexity has publicly acknowledged using a third-party cloud browser service "for highly specialized tasks." A real browser sees your client-side content perfectly well — and because it carries a normal browser user-agent, it is invisible to bot-log studies like Vercel's.

So the defensible claim is narrower than the popular one, and it is still the one that matters:

The declared crawlers — the bots that build the retrieval index an AI assistant cites from — do not run your JavaScript. Agents that visit a page because a user sent them there do. Rendering saves you at the visit; it does not save you at the citation.

Who Renders JavaScript, and Who Doesn't?

The full picture in one place, based only on what primary sources support as of July 2026:

One clarification, because it is a common confusion: Google states there are "no additional requirements" to appear in AI Overviews or AI Mode beyond being indexed in normal Search, and its AI optimization guide confirms "Google is able to process content within JavaScript as long as it isn't blocked." So Google's AI features are not the problem. Everyone else's are.

So Can a Cinematic Site Still Be Fast, Accessible, and Citable?

Yes — and I want to be fair about this, because the answer is genuinely yes. It just costs more engineering than most teams budget for. In the interest of not writing a one-sided article: I could not find a single published case study of a WebGL-heavy or scrollytelling site achieving green Core Web Vitals. Not one. That is not proof it is impossible; it is a signal about how rarely it is achieved. And Google itself offers the fairest counterpoint on page experience: "Core Web Vitals are used by our ranking systems," but "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." A stunning, relevant site can still win. It is simply playing with a handicap.

If you are going to build one, here is the bill, with the official source for each line.

One caveat I will flag rather than dress up as doctrine: deferring WebGL context creation until after LCP is, in my experience, one of the biggest single wins on these builds. But there is no official Google or MDN document prescribing it — it is a reasoned inference from the long-task guidance above, not a cited best practice. Treat it as my recommendation, not Google's.

One thing you should not reach for: dynamic rendering (serving pre-rendered HTML to bots and the JS app to users). Google now calls it "a workaround and not a recommended solution, because it creates additional complexities and resource requirements." Server-side or static rendering is the supported path.

When Is Scrollytelling the Right Call?

My view, stated plainly, since this article is an argument and not a neutral survey.

Scrollytelling earns its cost when the "wow" moment is the goal: product launches, marketing campaigns, brand storytelling, and creative showcases. These are typically campaign-scoped, promoted through channels other than organic search, measured on memorability rather than long-tail traffic, and often short-lived. Spending a large engineering budget on a cinematic experience there is a rational trade.

It is the wrong default when discoverability is the business model:a SaaS product, a documentation site, a content-led business, or anything that depends on long-term organic traffic and AI-assistant citations. There, the site's job is not to be admired — it is to be found, understood, and acted on. Every one of the three bills above is charged directly against that job.

You can build an outstanding user experience without turning your website into a movie. The best sites I know balance beautiful design with performance, accessibility, and usability — and they do it because a great website should not make users admire the experience. It should help them accomplish what they came to do.

How to Check Where Your Own Site Actually Stands

The good news is that none of this has to be a matter of opinion — all three bills are measurable.

For the performance and accessibility side, Greadme's Deep Scan runs a full Lighthouse audit and reports your Core Web Vitals, long tasks, and WCAG failures in plain language. For the crawlability side — the question of what exists in your raw HTML before JavaScript runs — see our guide to the SEO issues with client-side rendering, which is the same failure mode that makes you invisible to AI crawlers.

For the AI-visibility side specifically, guessing is the worst option. Greadme's AI Visibility Analyzer tests whether AI models actually mention your domain when users ask questions in your niche, which turns "are we invisible to ChatGPT?" into a number instead of an anxiety. If you want the mechanics of how these engines choose their sources, see how ChatGPT, Perplexity, and Google pick citations.

FAQ

Do AI crawlers like ChatGPT, Claude, and Perplexity render JavaScript?

Based on the only public server-log study of AI crawler behaviour — Vercel with MERJ, December 2024 — no. Their declared crawlers (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) fetch JavaScript files but do not execute them, which means they cannot read client-side rendered content. Important caveats: no AI vendor has ever officially confirmed or denied this, the study has not been repeated since, and agentic browsers like ChatGPT Atlas do drive a real browser and therefore do execute JavaScript.

If Google renders JavaScript, does it matter that AI crawlers don't?

Yes, and this is the core asymmetry. Google runs a headless Chromium and confirms that AI Overviews and AI Mode have no additional technical requirements beyond normal indexing, so a client-side rendered site can rank perfectly well there. But the systems that answer questions outside Google — ChatGPT, Claude, Perplexity — build their retrieval indexes from crawlers that appear not to render. Ranking #1 on Google is no longer proof that you are visible everywhere.

Is scrollytelling bad for SEO?

Not inherently — it is bad for SEO when the content only exists after JavaScript runs, and when the animation work degrades Core Web Vitals. If your text, headings, and key facts are server-rendered into the initial HTML, and your animation runs off the main thread via CSS scroll-driven animations, a scrollytelling site can rank. The risk is not the aesthetic; it is client-side rendering plus a busy main thread.

Does scroll-jacking violate WCAG?

No WCAG success criterion names "scroll-jacking" directly, and anyone citing a specific number for it is wrong. In practice it commonly fails SC 2.1.1 Keyboard (Level A) when custom scroll containers cannot be scrolled by keyboard — the W3C has a proposed ACT rule covering exactly this — and SC 2.4.3 Focus Order (Level A) when focus lands on content the narrative has not revealed. Separately, an autoplaying animation over five seconds with no pause control fails SC 2.2.2 (Level A).

How much JavaScript is too much?

There is no official threshold, but there is useful context: the median mobile page already ships 632 KB of JavaScript (Web Almanac 2025), and only 48% of origins pass all Core Web Vitals on mobile. The metric that actually matters is not bytes but main-thread time — any single task over 50ms is a "long task," and enough of them will push INP past the 200ms "good" threshold regardless of your bundle size.

Will server-side rendering fix my AI visibility?

It fixes the mechanical half of the problem — it puts your content in the raw HTML where a non-rendering crawler can actually read it. It does not, on its own, make an AI cite you. Citation still depends on whether your content is original, authoritative, and worth quoting. Server-side rendering gets you into the room; the content decides whether you get called on.

Should I ever build a scrollytelling site?

Yes — when a memorable "wow" moment is the primary goal: product launches, marketing campaigns, brand storytelling, creative showcases. These are usually campaign-scoped and promoted through channels other than organic search. Avoid it as the default for a SaaS product, documentation site, or any business whose growth depends on organic traffic and AI-assistant discoverability.