Zmniejsz zakres i złożoność obliczeń dotyczących stylu

Kod JavaScript często powoduje zmiany wizualne. Czasami wprowadza te zmiany bezpośrednio przez manipulowanie stylem, a czasami przez obliczenia, które powodują zmiany wizualne, takie jak wyszukiwanie lub sortowanie danych. Złanie zsynchronizowany lub długo działający kod JavaScript może być częstą przyczyną problemów z wydajnością. W miarę możliwości staraj się minimalizować jego wpływ.

Obliczanie stylu

Zmiana DOM przez dodawanie i usuwanie elementów, zmianę atrybutów lub klas albo odtwarzanie animacji powoduje ponowne obliczanie stylów elementów i w wielu przypadkach układu części lub całej strony. Ten proces nazywa się obliczeniem stylu.

Przeglądarka zaczyna obliczać style, tworząc zestaw pasujących selektorów, aby określić, które klasy, pseudoselektory i identyfikatory mają zastosowanie do danego elementu. Następnie przetwarza reguły stylów z odpowiednich selektorów i określa, jakie style końcowe ma element.

Rola ponownego obliczania stylów w opóźnieniu interakcji

Interakcja do kolejnego wyrenderowania (INP) to dane o wydajności w czasie działania, które służą do oceny ogólnej responsywności strony na dane wprowadzane przez użytkownika. Mierzy opóźnienie interakcji od momentu, gdy użytkownik wejdzie w interakcję ze stroną, do momentu, gdy przeglądarka wyrenderuje kolejny kadr, pokazujący odpowiednie wizualne zmiany w interfejsie.

Ważnym elementem interakcji jest czas potrzebny na wyrenderowanie następnego klatki. Przetwarzanie wykonywane w celu wyświetlenia następnej klatki składa się z wielu części, w tym obliczenia stylów stron, które występują tuż przed układem, malowaniem i kompozycją. Ten przewodnik skupia się na kosztach obliczania stylów, ale skrócenie dowolnej części łącznego czasu renderowania interakcji powoduje również skrócenie łącznego czasu oczekiwania.

Zmniejsz złożoność selektorów

Upraszczanie selektorów CSS może przyspieszyć obliczenia stylów na stronie. Najprostsze selektory odwołują się do elementu w CSS tylko za pomocą nazwy klasy:

.title {
  /* styles */
}

W miarę rozwoju projektu może on wymagać bardziej złożonego kodu CSS, a Ty możesz skończyć z selektorami, które wyglądają tak:

.box:nth-last-child(-n+1) .title {
  /* styles */
}

Aby określić, jak te style mają być stosowane na stronie, przeglądarka musi zapytać: „Czy jest to element z klasą title, którego nadrzędny element ma klasę box i jest podrzędnym elementem minus-nth-plus-1 swojego nadrzędnego elementu?”. Przeanalizowanie tego może zająć przeglądarce trochę czasu. Aby to uprościć, możesz zmienić selekcję na bardziej szczegółową nazwę klasy:

.final-box-title {
  /* styles */
}

Te nazwy klas zastępczych mogą wydawać się dziwne, ale znacznie ułatwiają pracę przeglądarce. W poprzedniej wersji, aby na przykład przeglądarka mogła stwierdzić, że element jest ostatnim tego typu, musi najpierw wiedzieć wszystko o wszystkich innych elementach, aby określić, czy jakieś elementy występujące po nim mogą być nth-last-child. Może to być dużo bardziej kosztowne pod względem obliczeniowym niż dopasowanie selektora do elementu wyłącznie na podstawie nazwy klasy.

Zmniejsz liczbę elementów, którym nadajesz styl.

Innym czynnikiem wpływającym na wydajność, a często ważniejszym niż złożoność selektora, jest ilość pracy, jaką należy wykonać, gdy zmienia się element.

Ogólnie rzecz biorąc, najgorszy koszt obliczenia stylu elementów obliczeniowych to liczba elementów pomnożona przez liczbę selektorów, ponieważ przeglądarka musi sprawdzić każdy element co najmniej raz w porównaniu z każdym stylem, aby sprawdzić, czy pasuje.

Obliczenia stylów mogą być kierowane bezpośrednio na kilka elementów zamiast unieważnia całej strony. W nowoczesnych przeglądarkach jest to zwykle mniejszy problem, ponieważ przeglądarka nie zawsze musi sprawdzać wszystkie elementy, na które może wpływać zmiana. Starsze przeglądarki nie zawsze są zoptymalizowane pod kątem takich zadań. Jeśli to możliwe, zmniejsz liczbę nieważnych elementów.

Pomiar kosztu ponownego obliczania stylów

Koszt ponownego obliczania stylów w przeglądarce możesz mierzyć na kilka sposobów. Każdy z nich zależy od tego, czy chcesz mierzyć ten proces w przeglądarce w środowisku programistycznym, czy chcesz mierzyć czas trwania tego procesu w Twojej witrynie przez prawdziwych użytkowników.

Pomiar kosztu przeliczania stylów w narzędziach deweloperskich w Chrome

Jednym ze sposobów pomiaru kosztów ponownego obliczania stylów jest użycie panelu wydajności w Narzędziach deweloperskich w Chrome. Aby rozpocząć, wykonaj te czynności:

  1. Otwórz Narzędzia deweloperskie.
  2. Otwórz kartę Skuteczność.
  3. Zaznacz pole wyboru Statystyki selektora (opcjonalnie).
  4. Kliknij Nagrywaj.
  5. Wejdź w interakcję ze stroną.

Gdy zatrzymasz nagrywanie, zobaczysz obraz podobny do tego:

Narzędzia deweloperskie wyświetlające obliczenia stylów.
Raport Narzędzi deweloperskich pokazujący obliczenia stylów.

Pasek u góry to miniaturowa tabela Flame, która również przedstawia liczbę klatek na sekundę. Im bliżej dolnej krawędzi paska znajduje się dana aktywność, tym szybciej przeglądarka wyświetla klatki. Jeśli widzisz, że wykres płomienia jest wyrównany u góry i powyżej niego znajdują się czerwone paski, oznacza to, że zadanie powoduje długi czas trwania klatek.

Powiększenie obszaru problemowego w Narzędziach deweloperskich w Chrome w podsumowaniu aktywności w wypełnionym panelu wydajności w Narzędziach deweloperskich w Chrome.
Długie ramki w podsumowaniu aktywności w Narzędziach deweloperskich

Warto przyjrzeć się dokładniej ruchomym elementom, które wyświetlają się przez dłuższy czas podczas interakcji, np. przewijania. Jeśli widzisz duży fioletowy blok, powiększ widok aktywności i wybierz pracę oznaczoną etykietą Przelicz styl, aby uzyskać więcej informacji o potencjalnie kosztownej pracy związanej z przeliczaniem stylu.

Uzyskiwanie szczegółowych informacji o długotrwałych obliczeniach stylu, w tym ważnych informacji, takich jak liczba elementów, na których wykonywane są obliczenia stylu.
Przedłużone obliczanie stylów trwające w podsumowaniu w Narzędziach deweloperskich ponad 25 ms.

Kliknięcie zdarzenia powoduje wyświetlenie jego stosu wywołań. Jeśli renderowanie zostało wywołane przez interakcję użytkownika, jest wywoływany kod JavaScript, który spowodował zmianę stylu. Pokazuje też liczbę elementów, których dotyczy zmiana (w tym przypadku ponad 900 elementów), oraz czas obliczenia stylu. Na podstawie tych informacji możesz zacząć szukać rozwiązania w kodzie.

Jeśli przed przeprowadzeniem śledzenia zaznaczysz pole wyboru Statystyki selektora w ustawieniach Panelu skuteczności, na dole panelu śledzenia pojawi się dodatkowa karta o tej samej nazwie.

Tabela statystyk selektora CSS, jaką znajdziesz w panelu wydajności w Narzędziach deweloperskich w Chrome Ta tabela zawiera nagłówki i odpowiednie dane, takie jak upłynięty czas, próby dopasowania, liczba dopasowań, odsetek niepasujących węzłów, selektory oraz arkusz stylów, w którym można je znaleźć.
Tabela statystyk selektora w panelu wydajności w Narzędziach deweloperskich w Chrome.

Ten panel zawiera przydatne dane o względnym koszcie każdego selektora, dzięki czemu możesz zidentyfikować kosztowne selektory arkusza CSS.

Więcej informacji znajdziesz w dokumentacji dotyczącej statystyk selektora CSS.

Pomiar kosztu przeliczenia stylu w przypadku rzeczywistych użytkowników

Jeśli chcesz się dowiedzieć, ile czasu zajmuje ponowne obliczanie stylów przez prawdziwych użytkowników Twojej witryny, interfejs Long Animation Frames API udostępnia narzędzia potrzebne do tego celu. Dane z tego interfejsu API zostały dodane do biblioteki JavaScript web-vitals, w tym czas ponownego obliczania stylów.

Jeśli podejrzewasz, że opóźnienie wyświetlania interakcji jest głównym czynnikiem wpływającym na INP strony, musisz określić, ile z tego czasu jest poświęcane na ponowne obliczanie stylów na stronie. Więcej informacji znajdziesz w artykule Jak mierzyć czas przeliczania stylów w polu.

Zasoby