Wyniki wyszukiwania "performance"

Twój kod działa idealnie na dziesięciu elementach i zacina się na dziesięciu tysiącach - mimo że ani jedna linijka się nie zmieniła. Big-O nie mówi „jak szybko”, tylko „jak koszt rośnie, gdy rośnie ilość danych”. O tym, jak rozpoznać kształt tego wzrostu w zwykłym kodzie frontendowym - i jak zamienić pętlę w pętli na coś, co nie zwalnia przy dużej ilości danych.

Ta sama odpowiedź serwera może w jednej chwili leżeć w kilku cache'ach naraz - pamięci aplikacji, Service Workerze, cache HTTP, na CDN - a całą stronę trzyma jeszcze bfcache. Każdy ma innego właściciela i co innego go czyści, więc „wyczyść cache" trafia w jeden z nich, czasem w żaden. Zostaje pytanie, od którego zaczyna się każde takie debugowanie: która warstwa trzyma starą kopię i co ją unieważnia.

Wyłącz internet, odśwież stronę - a ona dalej działa. Stoi za tym Service Worker: osobny skrypt, który wchodzi między stronę a sieć i przechwytuje każde żądanie o plik, zanim trafi ono do serwera. To on decyduje, czy odpowiedzieć z sieci, z własnego cache (Cache API), czy po swojemu - a z tej jednej decyzji biorą się wszystkie strategie cache'owania, tryb offline i klasyczna pułapka 'po wdrożeniu user widzi starą wersję'.

Weź jeden plik style.css i prześledź jego dzień na działającej stronie: najpierw pobiera go przeglądarka, potem serwuje go z pamięci bez pytania serwera, później pyta serwer, czy jej kopia jest nadal aktualna, i zwykle dostaje samo potwierdzenie zamiast całego pliku, a po wdrożeniu nowej wersji pobiera go od nowa. Z tej jednej historii wychodzi cały HTTP caching - Cache-Control, ETag, 304 i stale-while-revalidate.

Każdy element DOM przechodzi przez pięć etapów, zanim go zobaczysz, niezależnie od frameworka. Niektóre style odpalają tylko ostatni etap, inne uruchamiają wszystkie pięć. Stąd różnica w kosztach animacji - od jednego etapu composite po pełny reflow.