En CSS-animering är en ändring av ett elements stil som webbläsaren spelar upp över tid. Du kan skriva en på två sätt: transition -egenskapen, för tillståndsändringar som vid hovring, och animation -egenskapen med @keyframes, för sekvenser som körs av sig själva. Den här guiden täcker båda. Men grundtanken är enklare än så: vilken egenskap du väljer att animera spelar större roll än vilken syntax du väljer att skriva den med. Syntax lär man sig på en eftermiddag. Huruvida animeringen körs på kompositörstråden eller tvingar webbläsaren att räkna om layouten sextio gånger per sekund är det som avgör om gränssnittet fortfarande känns snabbt på den hårdvara dina användare faktiskt har, och det är här det kostar pengar att göra fel.
På Imaginary Cloud utvärderar vi animationsarbete utifrån två element: Animeringstajming, det vill säga varaktighet och fördröjning som förvandlar en omedelbar stiländring till rörelse, och Inre komponenter, de pseudo-element och extra element som gör att en komponent kan utföra flera rörelser samtidigt. Tillsammans visar de vad en effekt kommer att kosta att bygga och underhålla, och de genomsyrar varje avsnitt nedan.
Det finns flera sätt att skapa rörelse på en webbsida. Att lägga in en färdig GIF som en vanlig bild är enkelt, men då förlorar du möjligheten att ändra animationen via kod. Du kan manipulera HTML-element med JavaScript, vilket fungerar, men det körs på webbläsarens huvudtråd och hamnar i kö bakom allt annat. Eller så kan du definiera flera stilar för ett element i CSS och låta webbläsaren växla mellan dem över tid, vilket är både enklare att skriva och lättare för webbläsaren att optimera.
Inget av detta är bara dekoration. En laddningsanimation visar användaren att något fortfarande pågår, medan en tom vit sida får dem att undra om fliken har hängt sig. Samma väntetid, men en helt annan upplevelse. Det är hela anledningen till att det är värt att göra animationer ordentligt istället för att hoppa över dem.
CSS erbjuder två typer. transition -egenskapen hanterar hovringseffekter och andra användarinteraktioner. animation -egenskapen hanterar kontinuerlig rörelse eller, som vi ska se, rörelse med flera olika steg.
Se pennan types of animations av Patrícia Silva (@patsilva_tese) på CodePen.
Oavsett om de är enkla eller komplexa bygger alla CSS-animationer på två saker: animeringstid och inre komponenter. En animation utan tidsangivelse är ingen animation alls, eftersom den bara ändras omedelbart. Och inre komponenter är din räddning, eftersom ett enskilt element oftast inte räcker för att skapa den effekt du faktiskt vill ha. Låt oss gå igenom dem en i taget.
För att få en mjuk animation eller övergång måste du definiera tidsgränser. Både transition och animation -egenskaperna låter dig ange varaktighet, det vill säga hur lång tid det tar att gå från start till mål, vilket ställs in med den första tidsenheten i deklarationen. Sedan kommer fördröjning, hur länge elementet väntar innan det startar, vilket ställs in med den andra.
/* transition: property duration timing-function delay; */
transition: all 0.5s linear 0.2s;
/* animation: name duration timing-function delay iteration-count; */
animation: rotate 1s linear 0.2s infinite;Se pennan animation timing av Patrícia Silva (@patsilva_tese) på CodePen.
Den andra nyckelfaktorn, och vägen till något mer avancerat, är inre komponenter. Om du bara behöver ett eller två extra element är ::before och ::after pseudo-elementer löser det. Din HTML förblir precis som den var:
<ul>
<li><a href="#">home</a></li>
</ul>Och de två extra elementen deklareras helt i CSS:
a::before { content: ""; }
a::after { content: ""; }Styla dem som vanligt i din stilmall. Du behöver inte deklarera dem i HTML-koden alls, eftersom webbläsaren kopplar dem till huvudkomponenten åt dig och lämnar markeringen intakt. Den enda skillnaden är content -egenskapen, som tar en sträng. Se det som att du beskriver texten inuti en div, fast du gör det från CSS-sidan. Så här stylades a::before , med en tom sträng för content så att den inte skapar något annat än det där lilla hörnet:
a::before {
content: "";
position: absolute;
bottom: 12px;
left: 12px;
width: 12px;
height: 12px;
border: 3px solid #FCD63F;
border-width: 0 0 3px 3px;
opacity: 0;
transition: all 0.3s;
}Och hover-läget som den övergår till:
a:hover::before {
opacity: 1;
bottom: -8px;
left: -8px;
}Behöver du fler än två extra element? Använd då vanliga HTML-komponenter. Ändra strukturen, lägg till ostylade span-element, styla dem och applicera övergången eller animationen. Flera komponenter är också motiverade när du har olika typer av rörelser som sker samtidigt, eftersom varje komponent bara kan hantera en animation eller övergång åt gången. Laddningseffekten nedan är precis det: en div med namnet container med fyra span-element inuti, där containern har en animation som får den att växa och varje span-element har en annan som får dem att rotera.
<div class="container">
<span></span>
<span></span>
<span></span>
<span></span>
</div>Det är också härifrån din uppskattning kommer. En effekt som inte kräver några inre komponenter är en ändring i stilmallen. En effekt som kräver fyra är en ändring i markeringen, vilket innebär granskning, testning i olika webbläsare och en komponent som någon måste förstå sig på om ett år.
Så hur implementerar du en övergång? Börja med att definiera ett start- och slutläge för varje element som berörs, inklusive ::before och ::after -komponenterna. Egenskapen transition talar sedan om för dessa komponenter hur de ska bete sig däremellan. Den är en sammansättning av fyra andra: transition-delay och transition-duration, det tidsrelaterade paret vi gick igenom under Animation Timing, plus transition-property och transition-timing-function.
Se pennan transition property av Patrícia Silva (@patsilva_tese) på CodePen.
Låt oss titta på de två sista.
Detta anger vilka egenskaper som påverkas. Ställ in den på all så fångas varje egenskap som ändras mellan de två stilarna upp. Eller ange en specifik egenskap, eller en uppsättning av dem, vilket är vad du vill ha när olika egenskaper ska röra sig i olika hastigheter. Säg att du vill att bakgrundsfärgen ska ändras mycket snabbare än textfärgen:
transition-property: background-color, color;
transition-duration: 0.2s, 1s;Timing-funktionen ställer in övergångens hastighet. Den har en meny med nyckelordsvärden, plus två funktioner som låter dig definiera din egen kurva:
linear, konstant hastighet hela vägen;ease-in, börjar långsamt och blir sedan snabbare;ease-out, börjar snabbt och blir sedan långsammare;ease-in-out, en blandning av de två: långsam, snabbare, långsam igen;ease, en variant av den föregående och standardvärdet för denna egenskap;steps(n), som hoppar mellan n diskreta tillstånd istället för att interpolera, och är så man bygger sprite-sheet- och skrivmaskinseffekter;cubic-bezier(x1, y1, x2, y2), som definierar din egen accelerationskurva när inget av nyckelorden passar;linear(), ett nyare tillägg som approximerar fjädrar, studs och andra komplexa easing-effekter genom att lista punkter längs kurvan. Det har nu brett webbläsarstöd, så du behöver inte längre JavaScript för en studseffekt.Se pennan möjliga värden för transition-timing-function av Patrícia Silva (@patsilva_tese) på CodePen.
Till skillnad från transitions behöver animation -egenskapen ingen lista över påverkade egenskaper och inget explicit start- eller slutläge. Den friheten kommer från keyframes. Keyframes definierar komponentens olika tillstånd under ett namn, som du sedan ger till animation -egenskapen. Med två tillstånd räcker from och to . När du vill ha fler använder du procenttal, som i rotate -animationen från laddningseffekten:
@keyframes rotate {
0% { transform: rotate(0deg); }
10% { transform: rotate(0deg); }
50% { transform: rotate(90deg); }
90% { transform: rotate(90deg); }
100% { transform: rotate(90deg); }
}Precis som transitionär animation -egenskapen en sammansättning av andra. Du får animation-duration, animation-delay och animation-timing-function, som fungerar precis som deras motsvarigheter för övergångar gjorde under Animation Timing. Sedan animation-name, där namnet på keyframen anges. Sedan animation-iteration-count, ett specifikt nummer eller infinite. Sedan animation-play-state, som tar running eller paused och låter dig frysa en animation på plats från en klass eller ett skript. Och slutligen animation-direction och animation-fill-mode, båda nedan.
animation-fill-mode är den som brukar ställa till det. Den besvarar en fråga man oftast bara ställer sig när något ser fel ut: vad händer med elementet utanför själva animationens körtid?
Se pennan animation-direction av Patrícia Silva (@patsilva_tese) på CodePen.
Nästan alla egenskaper, så länge de uttrycks i enhetsvärden. Färger, höjd och bredd, marginaler och utfyllnad, opacitet, transform: allt fungerar bra. Kantlinjestil, position, float, background-image, font-family: har ingen effekt alls. MDN-referensen för animerbara CSS-egenskaper innehåller den fullständiga listan.
Men animerbart är inte samma sak som resurssnålt. När en webbläsare renderar en sida går den igenom en sekvens av steg: Layout, som beräknar var varje element placeras och hur stort det är; Paint, som fyller i pixlarna; och Composite, som sammanställer de målade lagren på skärmen. Om du animerar något som utlöser Layout, som width, måste webbläsaren även göra om Paint och Composite för varje enskild bildruta. Det är därför egenskaper som bara påverkar Composite-steget, transform och opacity, bör prioriteras. Googles web.dev-vägledning om CSS-övergångar går igenom varför transform är det smidiga och batterivänliga valet.
Om du vet att ett element snart ska animeras kan du ge webbläsaren en vink om detta med will-change -egenskapen så att lagret förbereds i förväg. Använd den sparsamt: att förbereda allt motverkar syftet och drar onödigt mycket minne.
Webbläsarstöd är inte längre ett hinder. Övergångar och animationer har varit en del av Baseline -uppsättningen av allmänt tillgängliga funktioner i alla större motorer i flera år. Det ditt val av egenskap fortfarande avgör är hur många av dessa tre renderingssteg webbläsaren måste upprepa, sextio gånger per sekund, på vilken enhet sidan än öppnas.
Se pennan JjKbdeE av Patrícia Silva (@patsilva_tese) på CodePen.
Som vi nämnde, transform är en av de mest resurssnåla egenskaperna att animera. Resurssnål betyder inte begränsad. Den ger dig mycket att arbeta med:
translate(x, y), flyttar ett element x pixlar horisontellt och y pixlar vertikalt. Negativa värden flyttar det åt vänster eller uppåt, positiva värden åt höger eller nedåt.rotate(y), roterar ett element y grader. Positiva värden för medurs, negativa för moturs. Som standard roterar det kring elementets mittpunkt, vilket du kan ändra med egenskapen transform-origin .scale(x, y), ändrar storleken. Två värden ändrar bredden x gånger och höjden y gånger. Ett värde ändrar båda med den faktorn och behåller elementets proportioner. Använd scaleX(x) och scaleY(y) för att rikta in dig på en axel. Över 1 gör det större, mellan 0 och 1 mindre.skew(x, y), snedställer elementet x grader horisontellt och y grader vertikalt. Ange ett värde så påverkas endast X-axeln, med y satt till 0. Precis som med skala, skewX() och skewY() riktar in sig på varje axel individuellt.matrix(a, b, c, d, tx, ty), som kombinerar skala, snedställning och förflyttning i en enda deklaration, och tar sex värden i den ordningen.Alla dessa roterar kring elementets mittpunkt om du inte ändrar transform-origin. Den tar ett eller två procentvärden, eller ett av nyckelorden top, bottom, right, left och center. Notera den amerikanska stavningen på det sista ordet: det är vad CSS-specifikationen definierar, och den enda formen som webbläsaren accepterar.
Om du har grävt i koden för de tidigare animationerna kanske du har märkt att vi inte använder transform genomgående. Det betyder inte att samma animationer inte kan byggas enbart med transformeringar. Därför har vi byggt om båda effekterna med enbart transform, för att visa att det går. HTML-strukturen förblir exakt densamma.
Se pennan tidigare animationer med transform av Patrícia Silva (@patsilva_tese) den CodePen.
Här är utvecklingen som förändrar vad en "CSS-animation" ens innebär år 2026. En scroll-driven animation kopplar en @keyframes -sekvens till scrollpositionen istället för till tidens gång. Den reveal-on-scroll-effekt som tidigare krävde IntersectionObserver, en scroll-lyssnare eller ett bibliotek som GSAP, består nu av tre rader CSS och körs på kompositörstråden istället för huvudtråden.
@keyframes fade-in {
from { opacity: 0; }
to { opacity: 1; }
}
.card {
animation: fade-in linear;
animation-timeline: view();
}Två funktioner driver detta. scroll() kopplar animationen till en scroll-behållares totala förlopp, vilket är precis vad du vill ha för en läsframstegsindikator. view() kopplar den till ett specifikt elements position inom vyn, vilket är vad du vill ha för en reveal-effekt. MDN:s guide för scroll-drivna animationer täcker hela API:et.
En ärlig brasklapp gällande stöd. Chromium-webbläsare har haft detta aktiverat som standard sedan Chrome 115 i juli 2023, och Safari lade till det i Safari 26 i september 2025. I mitten av 2026 kräver Firefox fortfarande en flagga, så det globala stödet ligger på ungefär 82 procent och funktionen har ännu inte nått Baseline. Betrakta det som en progressiv förbättring: skriv det synliga tillståndet som standard, omslut rörelsen i @supports (animation-timeline: scroll()), så blir felhanteringen helt enkelt "ingen animation" istället för en trasig sida. Omslut den även i prefers-reduced-motion , eftersom scroll-kopplad rörelse är särskilt benägen att orsaka obehag för användare med vestibulära störningar.
Ett relaterat par som är värt att känna till: @starting-style tillsammans med transition-behavior: allow-discrete gör det äntligen möjligt att animera ett element in och ut ur display: none, vilket är precis vad du behöver för dialogrutor, popovers och toasts som tidigare krävde JavaScript.
Se webbläsarens huvudtråd som en enkelriktad väg. Layout, rendering och varje rad JavaScript i din applikation köar på den, så när en tung uppgift tar upp vägen får allt bakom vänta. CSS-animeringar kan, beroende på vilka egenskaper du ändrar, använda en andra fil som kallas kompositörstråden. Animeringar på huvudtråden hackar när trafiken blir för tät. De på kompositörstråden fortsätter att flyta på.
Konsekvensen är mätbar. En webbläsare har ungefär 16 millisekunder på sig att producera varje bildruta vid 60 bilder per sekund, och ännu mindre när webbläsarens egen overhead räknas in. Missar du den tidsramen tappas bildrutan, och en tappad bildruta är vad användaren uppfattar som hack. Håll animeringar till transform och opacity så lämnar arbetet den kritiska sökvägen helt. Valet av egenskaper, långt mer än valet mellan CSS och JavaScript, avgör om en animering håller sin bildfrekvens.
Detta är inte abstrakt för oss. När vårt front-end-team byggde om AppTweaks instrumentpanel i React och TypeScript, var det en stor del av anledningen till att laddningstiden minskade med 80 procent att vi höll tungt arbete borta från huvudtråden. Samma princip som håller en instrumentpanel responsiv är den som håller en animering mjuk.
Det spelar även roll kommersiellt, eftersom upplevd hastighet är det användarna faktiskt känner av. Responsivitet har nu ett eget Core Web Vital: Interaction to Next Paint (INP) ersatte First Input Delay som en rankningssignal hos Google den 12 mars 2024, och det mäter den fulla latensen från ett användartryck till nästa renderade bildruta under hela besöket, inte bara vid den första interaktionen. Googles eget Search Central-meddelande förklarar förändringen, och MDN har en lättförståelig definition av INP. En animering som blockerar huvudtråden skadar det värdet direkt. En animering på kompositörstråden gör det inte.
JavaScript har fortfarande sin plats. Använd det när en animering måste svara på logik under körning, eller när du behöver den finare kontrollen hos Web Animations API. För de flesta gränssnittsrörelser är CSS det snabbare och billigare svaret. Om du vill ha en andra åsikt om var ditt gränssnitt tappar bildrutor, är det precis vad en teknisk och UX-revision är till för.
Rörelse är inte neutralt. För användare med vestibulära störningar kan stora eller upprepade rörelser utlösa illamående och yrsel, vilket är anledningen till att operativsystem erbjuder en inställning för minskad rörelse, och varför WCAG 2.1 listar Animation från interaktioner som ett framgångskriterium. Att ignorera den inställningen är ett misslyckande gällande tillgänglighet. Om du har en kund inom offentlig sektor eller ett företag är det även en fråga om efterlevnad.
CSS läser inställningen direkt via prefers-reduced-motion media query. Det säkraste är att behålla dina animationer som de är och neutralisera dem för alla som har bett om mindre rörelse:
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}Den nästan nollställda varaktigheten istället för none är avsiktlig. Den gör att alla animationend -hanterare fortfarande körs, så att inget i din JavaScript blir stående och väntar på en händelse som aldrig inträffar. Och där rörelse bär på betydelse snarare än att vara dekorativ, som i fallet med en laddningsindikator, byt ut den mot en statisk eller tonande motsvarighet istället för att ta bort feedbacken helt. Ett renare mönster för nya projekt är att välja den omvända vägen: definiera den reducerade versionen som standard, och lägg sedan till rörelse endast inuti @media (prefers-reduced-motion: no-preference).
Animationer uppskattas som finputs men betalas som ingenjörsarbete. Kostnaden, som definieras av animationstajming och interna komponenter, landar på tre områden, och det är värt att identifiera alla tre innan bygget påbörjas.
Det första är byggtid, vilket förutses av interna komponenter. En övergång på ett befintligt element består av ett fåtal deklarationer och tar långt under en timme inklusive granskning. En sekvens med keyframes som kräver fyra interna komponenter är en helt annan sak: ändringar i markup, granskning av dessa ändringar, kontroll i olika webbläsare och en komponent som någon annan kommer att ärva. Realistiskt sett tar det en dag snarare än en timme. Det är den proportionen man bör ta med sig in i en uppskattning.
Det andra är prestandarisk. En animation som triggar layoutändringar upplevs inte som långsam av en utvecklare på en snabb maskin. Problemet uppstår på mobiler i mellanklassen, där samma tidsbudget på 16 millisekunder per bildruta måste hållas med en bråkdel av processorkraften, och där ett hackigt gränssnitt uppfattas av användaren som en långsam webbplats snarare än en dåligt optimerad sådan. Att välja transform framför width kostar ingenting i byggtid och eliminerar risken helt. Vår ombyggnad av AppTweak-instrumentpanelen är beviset: de 80 procent vi återvann kom från att hålla arbetet borta från huvudtråden, inte från att lägga till mer.
Det tredje är underhåll. Varje animation är ett tillstånd som ditt gränssnitt kan fastna i, och varje animation måste överleva nästa omdesign. Tajming och interna komponenter hjälper även här. En effekt som byggts utifrån en tydlig tajmingsregel och en liten, namngiven uppsättning interna komponenter är något som en annan utvecklare kan ta över, och som du kan ändra utan att behöva riva upp hela komponenten. Det är samma disciplin som gör ett designsystem värt att ha, och samma anledning till att det lönar sig att ha en UI-utvecklare som ansvarar för front-end snarare än ett stilark som ingen äger.
Det finns en liknande bedömning gällande verktyg. När vi migrerade FlippedNormals från WordPress till en anpassad plattform på AWS, var beslutet inte att "anpassat är bättre" i teorin; det var att den befintliga stacken begränsade tillväxten, så migreringen betalade sig själv genom ökat utrymme och högre trafik. Animationsval fungerar på samma sätt. Frågan är inte om rörelse är värt det. Frågan är vilka interaktioner som motiverar det strukturella arbetet, och vilka som fungerar alldeles utmärkt med en övergång på en egenskap som endast hanteras av kompositorn.
För det mesta gränssnittsarbete, ja. CSS-animeringar på transform och opacity kan hanteras av kompositörstråden och fortsätta köras medan huvudtråden är upptagen, medan JavaScript-animeringar körs på huvudtråden och konkurrerar med allt annat som körs där. JavaScript är fortfarande rätt verktyg när en animering måste svara på logik under körning, eller när du behöver den finare kontrollen som Web Animations API erbjuder.
transform och opacity, eftersom de bara utlöser kompositsteget i renderingspipelinen. Att animera width, height, margin, padding eller topp och vänster utlöser layout, vilket tvingar Paint och Composite att köras igen för varje bildruta. MDN:s referens för animerbara egenskaper listar vad som finns tillgängligt.
En övergång körs mellan två tillstånd och behöver något som utlöser den, vanligtvis en hover eller en klassändring. En animation körs av sig själv, behöver ingen utlösare och kan definiera så många mellanliggande tillstånd som du vill genom @keyframes -procentvärden. Övergång för ett tillståndsbyte. Animation för en sekvens.
I de flesta webbläsare, ja. Scroll-drivna animationer använder animation-timeline med scroll() eller view() för att koppla en keyframe-sekvens till scrollpositionen, helt i CSS, som körs på kompositörstråden. Stödet är brett men inte universellt i mitten av 2026 (Firefox stable ligger fortfarande bakom en flagga), så omslut det i @supports och behandla det som progressiv förbättring. Se MDN-guiden för scroll-drivna animationer.
Det beror oftast på att animationen påverkar en egenskap som triggar layout, vilket gör att webbläsaren måste räkna om geometrin för varje bildruta och därmed överskrider tidsramen på 16 millisekunder. Kontrollera först vilka egenskaper du animerar och byt ut dem mot motsvarande transform-egenskaper där det går: translate() istället för top och left, scale() istället för width och height.
Respektera prefers-reduced-motion: reduce mediefråga som rapporterar den inställning för reducerad rörelse som användaren redan har valt på operativsystemnivå. Förkorta varaktigheter till nära noll istället för att ta bort animationer helt, så att all kod som lyssnar efter animationend fortfarande körs. Och där rörelse förmedlar mening, som vid laddningsindikatorer, ersätt den med ett statiskt alternativ istället för att ta bort den helt.
Det kan de göra. En animation på huvudtråden konkurrerar med händelsehantering, vilket skadar Interaction to Next Paint, det Core Web Vital-mått för responsivitet som ersatte First Input Delay i mars 2024. Genom att hålla animationer på kompositorn med transform och opacity hålls det arbetet borta från den kritiska sökvägen.
Inte på samma egenskap. Varje element kan ha en övergång eller animation per egenskap, vilket är precis anledningen till att avancerade effekter byggs upp av inre komponenter: ::before och ::after för ett eller två extra element, eller ytterligare span- eller div-element när du behöver mer, där varje del har sin egen rörelse.
Så få som krävs för att uttrycka rörelsen. Det rotera animeringen i laddningseffekten ovan använder fem, och tre av dem finns där för att hålla en position snarare än att röra sig mellan dem. Att hålla ett tillstånd vid 10 % och 90 % är det som skapar en paus. Att lägga till keyframes som inte ändrar ett värde tillför ingenting alls.
Att skapa animationer med CSS, och med transform i synnerhet, bör vara ditt förstahandsval. Se till att få till timing och komponenter rätt, och välj sedan egenskaper som håller arbetet i kompositörsfasen. Det är just det valet som skiljer ett gränssnitt som håller 60 bildrutor per sekund från ett som hackar på den hårdvara de flesta av dina användare har, och det kostar ingenting extra att göra rätt från början. Var försiktig med att överanvända rörelse, respektera inställningen för reducerad rörelse, och kom ihåg kärnan i alltihop: vilken egenskap du animerar spelar större roll än antalet animationer du skriver.
Om du överväger att optimera prestandan för din frontend, eller vill ha en second opinion om var ett gränssnitt tappar bildrutor, hjälper vårt team för webb- och mobilutveckling gärna till. Du kan se hur vi har tagit oss an liknande projekt eller inleda en dialog.
Webbutvecklare med en speciell kärlek till front-end. Mamma till katter. Jag försöker hjälpa till att rädda planeten på min fritid genom att dela miljövänliga alternativ.
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
People who read this post, also found these interesting:
.webp)
