Every few months a client sends us a competitor's site that moves beautifully and asks two questions in the same breath: can we have that, and will it make our site slow. The second question deserves a straight answer, and the straight answer is that it depends entirely on which animations and how they are built.
This guide explains what a browser finds cheap and what it finds expensive, which is not what most people assume. Then it covers the things that actually make sites slow, most of which have nothing to do with motion, and finishes with the rules we follow so a site can be lively and still score well.
What Google actually measures
Google's Core Web Vitals are three numbers. Largest Contentful Paint measures how long the biggest visible element takes to appear, and the target is 2.5 seconds or less. Interaction to Next Paint measures how quickly the page responds when someone taps or clicks, with a target of 200 milliseconds or less. Cumulative Layout Shift measures how much the page jumps around while loading, with a target of 0.1 or less.
Notice what is not on that list. There is no penalty for movement, no measurement of how much animates, and no reward for a static page. A site fails these numbers when its main image is slow to arrive, when scripts block the page from responding, or when content shifts as things load. Animation only matters where it causes one of those three problems.
The animations that are nearly free
Browsers have a fast lane. Changes to an element's position, scale, rotation and opacity can be handed to the graphics processor and drawn without recalculating where anything else on the page sits. A marquee sliding sideways, a card fading in, a photo drifting as you scroll, a hover that lifts a button: all of these live in that fast lane and cost almost nothing, even on an old phone.
This carousel is a good example. Slides cross fade rather than slide, so the only thing changing is opacity, and the loop runs on the graphics layer. It could run all day on a budget Android device without the page noticing. Most of the movement people admire on premium websites is built this way.
The animations that cost real money
Three kinds of motion are genuinely expensive. Anything that changes layout, such as animating an element's width, height or margin, forces the browser to recompute the position of everything around it on every frame. Anything that runs heavy JavaScript on every scroll event or every frame competes with the visitor's taps for the same thread. And anything that renders a full 3D scene needs the graphics card working continuously.
This zooming canvas is the honest example of the third kind. It is a WebGL scene with dozens of photographs at different depths, and it is spectacular. It is also the heaviest thing in our studio, and we would never put it on a page that needs to load fast on mobile data. We use it where the wow is the point, load it only when the section is about to be seen, and swap it for a still image when the visitor has asked their device to reduce motion.
What actually makes websites slow
In our experience the culprit is almost never the animation. It is a hero image exported at four thousand pixels wide and two megabytes. It is an autoplaying video that was never compressed. It is a page loading six fonts, three analytics scripts and a chat widget before it shows a single word. It is a slideshow plugin from 2016 pulling in a library ten times its own size.
Fix those and most sites pass Core Web Vitals without touching a single animation. This is why we are suspicious of any advice that says to strip the motion out. It removes the thing visitors remember while leaving the two megabyte image exactly where it was.
The rules we build by
Animate only transforms and opacity, and reach for anything else only with a reason. Serve every image as WebP at the size it is actually displayed, and give every video a poster frame so nothing waits on a download. Load heavy sections only when they are about to scroll into view. Respect the reduce motion setting on the visitor's device, which replaces movement with a still for people who have asked for that. Pause every loop when the tab is not visible.
Then measure. Google's PageSpeed Insights is free and reports the three vitals for any address. We run it before launch and after any change that adds media. If a number slips, the report says exactly which element caused it, and it is almost always an image.
So, should your site move?
Yes, where movement does a job: guiding the eye, showing more work in less space, making a product feel closer to real. No, where it is decoration for its own sake, because that is the motion that gets built carelessly and blamed later.
A website in Singapore competes for attention on phones, on trains, on mobile data. It has to load fast and it has to be worth looking at. Those are not opposites. They are the same brief, and the sites that win are the ones built to both.