When website animation earns its keep (and when it is just a tax)

We tested that rule against our own most elaborate page, thesocialtarget.com/world, and are publishing the bill. Not a case study dressed up as an apology: a receipt. What the page cost to build, what it costs a visitor to load, where we deliberately swapped the clever version for a plainer one, and the decision test that tells you when the same trade is worth making on your own site.

Three questions sit underneath most of the traffic this topic gets, so we are answering them directly before anything else: does animation slow a website down, is scroll animation worth building, and what does a moving website actually cost, to build and to load.

Does animation slow down a website?

Not because it moves. A website slows down because of what has to load before it can move: video files, image sequences, extra script weight. A CSS transform costs almost nothing measurable. A scroll-driven video sequence can add tens of megabytes to a single page.

"Animation" is not one thing with one price. A hover state built from a CSS transform, the kind that slides a button or nudges an icon, adds a few lines of style sheet and nothing a visitor's connection notices. A short, looping SVG animation is a similar story: a few kilobytes, decoded by the browser's own rendering engine, no extra request beyond the file itself.

Scroll-triggered effects change the maths, because most of them are not animating shapes, they are animating pre-recorded footage or image sequences, and footage and images are the two heaviest asset types on the web. The weight was never really about "animation" as a category. It was about whether the effect is drawn by the browser on the fly, which is close to free, or played back from a file the visitor has to download first, which is not.

Is scroll-triggered animation worth it?

Only when the motion explains something a still image or a paragraph cannot: a process, an assembly, a before-and-after over time. If the motion is decorative, a headline fading up, a logo sliding in, it is not doing a job. It is a tax the visitor pays in seconds and battery for no return.

That is the whole test, and it is a deliberately narrow one. It rules out most of what gets built. A fade-up on scroll is not explaining anything; the words underneath it would read exactly the same without it. A parallax hero is not explaining anything either. Both are decoration wearing the vocabulary of a feature.

What survives the test is narrow by design: a diagram that has to unfold in steps to make sense, a before-and-after that only means something as a transition, a sequence a photograph genuinely cannot compress into one frame. Our own page exists because we needed to show a process, not tell it, and that is the only reason the budget below was ever spent.

What did our own scroll film cost to build?

The engine behind thesocialtarget.com/world is 1,209 lines of plain JavaScript across two files. Zero dependencies, no framework, no build step: nothing installed, nothing to keep patched.

The page is five scrolled scenes, joined by four short connecting clips that play as the visitor moves between them, so the film is a stitched sequence rather than one continuous take. Scroll position drives playback directly: scroll down and the current clip plays forward, scroll back up and it plays backward, which is the mechanic that makes the page feel handmade rather than templated.

None of that needed a framework. The entire thing is two files: the markup and a plain script that listens to scroll position and maps it onto video playback. No component library, no animation package, no build pipeline compiling anything before it ships. That is the encouraging half of this article: the cleverness lived in a small, ordinary piece of engineering, not in an expensive stack. Fancy did not need to be complicated to build.

What does it cost to load?

Total page weight is 64 MB: 50 MB of video, 13 MB of image frames, and 688 KB of still images. The video is the bill; everything else is a rounding error next to it.

That is not a number we would defend on a page whose job is to be found, sell, or convert. It is the number for a page whose job is to be watched, and the two jobs have different budgets. Fifty megabytes of the total is the video powering the connecting clips and scrolled scenes described above. Thirteen megabytes is a separate set of image frames used where the page needs a scrubbed sequence rather than continuous footage. Stills, at 688 KB, are the lightest asset on the page by a wide margin, and they matter for a reason covered below: they are what a visitor gets instead of the film, not alongside it.

What happens on a phone?

Phones do not get the desktop version, but they do get the same animation. iOS limits how much video a page may decode at once, so thesocialtarget.com/world drops video on mobile and scrubs a sequence of still frames on a canvas instead, 64 per scene, driven by exactly the same scroll position.

Scrubbing several synced videos back and forth is a decode-heavy trick, and iPhones ration how much of that decoding a web page is allowed to do. Build the desktop version straight onto a phone and it stutters exactly where most visitors are standing. So the mobile path is not the desktop page shrunk down: it is a genuinely different build underneath, either a smaller re-encoded video or, where the scene carries a frame set, a sequence of 64 still images drawn one at a time onto a canvas element.

Worth being precise about what that means, because "images instead of video" sounds like a downgrade to a slideshow and it is not. The motion is identical. The same scroll position drives the same sequence at the same speed, forwards and backwards, frame by frame. What changes is only what the browser is asked to do: paint the next picture, rather than seek inside a compressed video and wait for a decoder that may be rationed. The visitor sees the same page. The phone does less work to show it.

The plainer version is not a compromise apologised for. It is the version that works on the device most visitors are holding, and on the device that matters most, the plain technique beat the clever one.

What happens with reduced motion, or with JavaScript off?

Two separate trades, both deliberate. If a visitor's device asks for reduced motion, the clips are never loaded at all, and stills cross-dissolve instead: the saving is real bandwidth, not just suppressed movement. With JavaScript disabled, the served page carries no readable text beyond the title.

The first trade is the one we are proud of. prefers-reduced-motion is honoured at the network layer, not just hidden with CSS: a visitor who has told their operating system they want less motion never has the video requested on their behalf, so the saving is the full weight of the clips, not a muted autoplay sitting in the background. They get the 688 KB of stills, cross-dissolving between scenes, and nothing else downloads.

The second trade is the honest limit of the page. Turn JavaScript off and the served HTML carries nothing to read but the page title. For a showreel, that is survivable: nobody is arriving at a scroll film hoping to read it with scripts disabled, and the page was never built to be indexed on its content. It would be a different story on a page that needs to be found, which is exactly the boundary this article is really about.

So how do you decide, on your own site?

Ask what the motion explains, then ask what happens to the page when the motion is stripped out: reduced motion, JavaScript off, a slow connection. If the answer to the first question is "nothing" and the answer to the second is "the page stops working", the effect is not earning its keep.

Run every proposed effect through the same short list we used to justify our own.

Does it show something a paragraph or a still image genuinely cannot? If the honest answer is no, it is decoration, and decoration is a tax whatever the brief calls it.

What does the page look like with the effect removed entirely? A page whose content survives intact without the motion has priced the effect correctly: it is an addition, not a load-bearing wall. A page that goes blank without it, the way ours does with JavaScript off, has made a trade that only belongs on a page whose job is to be watched rather than read or found.

Who is this page actually for? A single flagship page built to be experienced can spend a heavy budget deliberately, the way ours does. A service page, an article, or anything that needs to rank or convert should default to the cheap end of the scale: CSS transforms, small SVGs, motion that respects prefers-reduced-motion as standard, and readable content that survives with scripts off.

Was the spend a decision or a default? The difference between our page and most heavy sites is not the megabytes. It is that somebody looked at the number before it shipped and decided it was worth it for what the page does. Most bloated sites never had that conversation; the weight simply accumulated.

If you are weighing whether an effect on your own site is doing a job or just costing you one, that is a conversation we have often. Tell us about your business through our intake form, and we will tell you plainly which of your site's animations earn their keep and which ones are a tax nobody decided to charge.