// tailwind.config.js
module.exports = {
theme: {
extend: {
keyframes: {
gradient: {
'0%, 100%': { backgroundPosition: '0% 50%' },
'50%': { backgroundPosition: '100% 50%' },
},
},
animation: {
'gradient-slow': 'gradient 8s ease infinite',
},
},
},
}
// Utilizare în HTML / JSX:
// <div class="bg-gradient-to-r from-blue-500 via-purple-500 to-pink-500 bg-[length:200%_200%] animate-gradient-slow">
// Conținutul tău aici
// </div>Salutare tuturor. Am avut recent de bibilit un landing page pentru un SaaS și clientul ținea neapărat să aibă un gradient animat „viu” pe hero secțiune, genul ăla pe care-l vezi la Stripe sau Vercel. Prima pornire a unui coleg din echipă a fost să arunce în proiect Framer Motion, dar am zis că e păcat de cele 30-40kb adăugate la bundle doar pentru un efect vizual.
Am rezolvat totul cu CSS pur și câteva clase de Tailwind, iar performanța pe mobil e impecabilă. Vă arăt imediat cum se face și care-i șmecheria din spate pe care mulți o ratează.
De ce nu JS și unde e capcana?
Cea mai mare greșeală când încerci să animezi un gradient e să crezi că poți anima direct culorile din linear-gradient cu proprietatea transition. Browserele încă nu știu să facă interpolare nativă între culorile unui gradient în mod eficient (există @property în CSS modern, dar suportul în browsere mai vechi e încă dubios).
Soluția clasică și extrem de performantă este să faci gradientul mult mai mare decât containerul (de exemplu, 200% sau 400% din lățime și înălțime) și să-i animezi poziția (background-position). Practic, muți camera pe o imagine uriașă.
La proiectul de care vă ziceam, cu vreo 15.000 de vizite lunare, am economisit cam 8% la timpul de încărcare pe mobil doar eliminând scripturile inutile de animație pentru elemente decorative.
Cum configurăm Tailwind
Ca să nu ne umplem fișierele de CSS brut, cel mai curat e să extindem configurația de Tailwind. Avem nevoie de două lucruri: definirea animației personalizate și a keyframe-urilor.
Configurația în fișierul de setări arată ca în exemplul de mai jos. După ce ai adăugat asta, în HTML sau JSX folosești clasa animate-gradient-slow combinată cu un gradient setat la o dimensiune mărită, de exemplu bg-[length:200%_200%]. Clasa aceea arbitrară de bg-[length:...] este crucială, altfel animația nu are unde să se miște.
Trade-off-uri sincere
Chiar dacă e o soluție elegantă, are și ea limitele ei.
Animarea de background-position forțează browserul să facă repaint-uri destul de des. Pe un laptop modern sau pe un iPhone de generație nouă nu vei simți nimic, totul rulează la 60 FPS sau chiar 120 FPS. Totuși, am testat pe un Android mai vechi (un Huawei de acum 5 ani) și, dacă gradientul acoperea tot ecranul, se simțea un mic agățat când dădeai scroll.
Dacă ai o pagină foarte încărcată cu alte scripturi sau imagini grele, s-ar putea ca un gradient pe tot ecranul să scadă scorul de performanță pe telefoane low-end. Sfatul meu: limitează efectul doar la zona de Hero sau pe butoane mici, unde suprafața de randare e redusă.
CSS-ul simplu câștigă când vrei performanță brută și zero JS, atât. Voi cum procedați când aveți de făcut micro-interacțiuni de genul ăsta? Aruncați direct o librărie de JS sau preferați să stoarceți tot ce se poate din CSS-ul nativ?