Hogyan készült ez az oldal

Teljes oldalas, 6–14 képernyő magas screenshotokat tettem a portfóliókártyákra. Egy kártya körülbelül egy másodpercig van fókuszban; ennyi idő alatt a látogató egy képernyőnyit sem lát a képből. A teljes képet mégis minden eszköz dekódolja: 15 kép, 217 MB memória. A WebP-fájlok kicsik voltak, ezért a gond fel sem tűnt. Mindet 1800 pixel magasra vágtam. A dekódolt bitmap memóriaigénye számít; a kis fájlméret félrevezetett.

Awwwards-stílusú animációkkal raktam tele az oldalt, és a leglátványosabb alatt összerogyott a teljesítmény. A portfóliósáv képein a clip-path és a transform tulajdonságot egyszerre animáltam: Chrome-ban simán futott, a WebKit viszont az így vágott képréteget képkockánként újrarajzolja a fő szálon – a sáv közepén 43–80 ms-os képkockaidőt mértem. Akadozva a leggondosabb mozgás is olcsó trükknek hat. Átírtam: már csak az opacity és a transform változik, mindkettő a kompozitoron fut, a tempó ugyanaz. Ezt is meg kellett tanulnom – egy effekt annyit ér, amennyit 60 fps mellett tud, és azóta két böngészőben mérek.

A simított görgetés React state-ből olvasta a prefers-reduced-motion beállítást. Ezt egy effect csak az első render után töltötte fel, ezért az oldal egy képkockáig az alapértékkel indult. Aki csökkentett mozgást kért, rövid időre mégis megkapta a simított görgetést. useSyncExternalStore-ra cseréltem; így már az első render a valódi beállítást látja.

Gyorsításnak szántam a will-change-et, és rászórtam mindenre, ami animál. Minden megjelölt elem külön kompozitorréteget kap, és akkor is memóriát foglal, amikor semmi nem mozog. Kigyomláltam. Most csak az animáció idejére kerül fel, majd az animáció végén lejön.

A kapcsolatfelvételi űrlap kéréskorlátozásához külső Redis-szolgáltatást kötöttem be, pedig naponta csak néhányan küldik el. Kivettem. Egy folyamaton belüli számláló ugyanazt tudja, külső függőség és API-kulcs nélkül.