Refaktoryzacja CSS: optymalizacja rozmiaru i wydajności (część 3)

W poprzednich artykułach z tej serii omówiliśmy kontrolę stanu bazy kodu CSS oraz strategię przyrostowej refaktoryzacji CSS, testowanie i konserwację. Niezależnie od tego, jak bardzo poprawiono bazę kodu CSS podczas procesu refaktoryzacji oraz o ile jest ona łatwiejsza w utrzymaniu i rozszerzalności, ostateczny arkusz stylów musi zostać zoptymalizowany pod kątem najlepszej możliwej wydajności i najmniejszego możliwego rozmiaru pliku.

Wdrożenie zrefaktoryzowanej bazy kodu nie powinno skutkować gorszą wydajnością strony i gorszym doświadczeniem użytkownika. W końcu użytkownicy nie będą czekać w nieskończoność na załadowanie strony. Ponadto kierownictwo będzie niezadowolone ze zmniejszonego ruchu i przychodów spowodowanych niezoptymalizowaną bazą kodu, pomimo poprawy jakości kodu.

W tym artykule omówimy strategie optymalizacji CSS , które mogą zoptymalizować rozmiar pliku CSS, czas ładowania i wydajność renderowania. W ten sposób zrefaktorowana baza kodu CSS jest nie tylko łatwiejsza w utrzymaniu i rozszerzalności, ale także wydajniejsza i zaznacza wszystkie pola, które są ważne zarówno dla użytkownika końcowego, jak i dla kierownictwa.

Optymalizacja rozmiaru pliku arkusza stylów

Optymalizacja rozmiaru pliku sprowadza się do usunięcia zbędnych znaków i formatowania oraz optymalizacji kodu CSS w celu użycia innej składni lub skróconych właściwości w celu zmniejszenia ogólnej liczby znaków w pliku.

Optymalizacja i minifikacja

Optymalizacja i minifikacja CSS istnieją od lat i stały się podstawą optymalizacji frontendu. Narzędzia takie jak cssnano i clean-css należą do moich ulubionych narzędzi, jeśli chodzi o optymalizację i minifikację CSS. Oferują szeroką gamę opcji dostosowywania, aby dodatkowo kontrolować sposób optymalizacji kodu i obsługiwane przeglądarki.

Te narzędzia działają w podobny sposób. Najpierw niezoptymalizowany kod jest analizowany i transpilowany zgodnie z regułami określonymi w konfiguracji. Rezultatem jest kod, który używa mniej znaków, ale nadal zachowuje formatowanie (podziały wierszy i spacje).

 /* Before - original and unoptimized code */ .container { padding: 24px 16px 24px 16px; background: #222222; } /* After - optimized code with formatting */ .container { padding: 24px 16px; background: #222; }

I wreszcie, zoptymalizowany kod transpilowany jest minimalizowany przez usunięcie całego niepotrzebnego formatowania tekstu . W zależności od bazy kodu i obsługiwanych przeglądarek ustawionych w konfiguracji, kod z przestarzałymi prefiksami dostawców może również zostać usunięty.

 /* Before - optimized code with formatting */ .container { padding: 24px 16px; background: #222; } /* After - optimized and minified code */ .container{padding:24px 16px;background:#222}

Nawet w tym podstawowym przykładzie udało nam się zmniejszyć całkowity rozmiar pliku z 76 bajtów do 55 bajtów, co dało redukcję o 23%. W zależności od bazy kodu oraz narzędzi optymalizacyjnych i konfiguracji, optymalizacja i minifikacja CSS może być jeszcze bardziej efektywna.

Optymalizację i minifikację CSS można uznać za łatwą wygraną ze względu na znaczną wypłatę dzięki kilku poprawkom w przepływie pracy CSS. Dlatego minifikację należy traktować jako minimalną optymalizację wydajności i wymaganie dla wszystkich arkuszy stylów w projekcie.

Optymalizacja zapytań o media

Kiedy piszemy zapytania o media w CSS, zwłaszcza gdy używamy wielu plików (PostCSS lub Sass), zwykle nie zagnieżdżamy kodu w jednym zapytaniu o media dla całego projektu. Aby poprawić łatwość utrzymania, modułowość i strukturę kodu, zwykle piszemy te same wyrażenia zapytań o media dla wielu komponentów CSS.

Rozważmy następujący przykład niezoptymalizowanej bazy kodu CSS.

 .page { display: grid; grid-gap: 16px; } @media (min-width: 768px) { .page { grid-template-columns: 268px auto; grid-gap: 24px; } } /* ... */ .products-grid { display: grid; grid-template-columns: repeat(2, 1fr); grid-gap: 16px; } @media (min-width: 768px) { .products-grid { grid-template-columns: repeat(3, 1fr); grid-gap: 20px; } }

Jak widać, mamy powtarzający się @media (min-width: 768px) na komponent dla lepszej czytelności i konserwacji. Uruchommy optymalizację i minifikację w tym przykładzie kodu i zobaczmy, co otrzymamy.

 .page{display:grid;grid-gap:16px}@media (min-width: 768px){.page{grid-template-columns:268px auto;grid-gap:24px}}.products-grid{display:grid;grid-template-columns:repeat(2,1fr);grid-gap:16px}@media (min-width: 768px){.products-grid{grid-template-columns:repeat(3,1fr);grid-gap:20px}}

Może to być trochę trudne do odczytania, ale jedyne, co musimy zauważyć, to powtarzające się zapytanie o media @media (min-width: 768px) . Doszliśmy już do wniosku, że chcemy zmniejszyć liczbę znaków w arkuszu stylów i możemy zagnieździć wiele selektorów w jednym zapytaniu o media, dlaczego więc minifikator nie usunął zduplikowanego wyrażenia? Jest ku temu prosty powód.

Kolejność reguł ma znaczenie w CSS, więc aby scalić zduplikowane zapytania o media, należy przenieść bloki kodu. Spowoduje to zmianę kolejności reguł, co może spowodować niepożądane efekty uboczne w stylach.

Jednak połączenie zapytań o media może potencjalnie zmniejszyć rozmiar pliku, w zależności od bazy kodu i struktury. Narzędzia i pakiety, takie jak postcss-sort-media-queries, pozwalają nam usunąć zduplikowane zapytania o media i jeszcze bardziej zmniejszyć rozmiar pliku.

Oczywiście istnieje ważne zastrzeżenie posiadania dobrze zorganizowanej struktury kodu CSS , która nie zależy od kolejności reguł. Optymalizacja ta powinna być brana pod uwagę przy planowaniu refaktoryzacji CSS i ustalaniu podstawowych zasad.

Polecam najpierw sprawdzić, czy korzyści z optymalizacji przewyższają potencjalne ryzyko. Można to łatwo zrobić, przeprowadzając audyt CSS i sprawdzając statystyki zapytań o media. Jeśli tak, sugerowałbym dodanie go później i uruchomienie automatycznych testów regresji, aby wyłapać wszelkie nieoczekiwane efekty uboczne i błędy, które mogą wystąpić w wyniku.

Usuwanie nieużywanego CSS

Podczas procesu refaktoryzacji zawsze istnieje możliwość, że otrzymasz nieużywane starsze style , które nie zostały całkowicie usunięte lub będziesz mieć kilka nowo dodanych stylów, które nie są używane. Te style zwiększają również ogólną liczbę znaków i rozmiar pliku. Wyeliminowanie tych nieużywanych stylów za pomocą automatycznych narzędzi może być jednak nieco ryzykowne, ponieważ narzędzia nie mogą dokładnie przewidzieć, które style są faktycznie używane.

Narzędzia takie jak purgecss przechodzą przez wszystkie pliki w projekcie i używają wszystkich klas wymienionych w plikach jako selektorów, aby zachować ostrożność i nie przypadkowo usunąć selektory dla dynamicznych elementów wstrzykniętych przez JavaScript, między innymi w potencjalnych przypadkach. Jednak purgecss oferuje elastyczne opcje konfiguracji jako obejście tych potencjalnych problemów i zagrożeń.

Jednak poprawa ta powinna być dokonana tylko wtedy, gdy potencjalne korzyści przewyższają ryzyko . Ponadto ta technika optymalizacji będzie wymagała znacznej ilości czasu na skonfigurowanie, skonfigurowanie i przetestowanie oraz może powodować niezamierzone problemy w dalszej kolejności, więc postępuj ostrożnie i upewnij się, że konfiguracja jest kuloodporna.

Eliminacja CSS blokującego renderowanie

Domyślnie CSS jest zasobem blokującym renderowanie, co oznacza, że ​​witryna nie będzie wyświetlana użytkownikowi, dopóki wszystkie połączone arkusze stylów i ich zależności (na przykład czcionki) nie zostaną pobrane i przeanalizowane przez przeglądarkę.

Jeśli plik arkusza stylów ma duży rozmiar lub wiele zależności, które znajdują się na serwerach lub sieciach CDN innych firm, renderowanie witryny może być znacznie opóźnione w zależności od szybkości i niezawodności sieci.

Największe malowanie treści (LCP) stało się ważnym wskaźnikiem w ciągu ostatnich kilku miesięcy. LCP jest ważne nie tylko dla wydajności, ale także dla SEO — strony z lepszymi wynikami LCP będą miały lepszy ranking wyników wyszukiwania. Usunięcie zasobów blokujących renderowanie, takich jak CSS, jest jednym ze sposobów poprawy wyniku LCP.

Jeśli jednak odroczymy ładowanie i przetwarzanie arkusza stylów, spowoduje to powstanie Flash Of Unstyled Content (FOUC) — treść zostanie wyświetlona użytkownikowi od razu, a style zostaną wczytane i zastosowane kilka chwil później. Ten przełącznik może wyglądać irytująco, a nawet wprowadzać w błąd niektórych użytkowników.

Krytyczny CSS

Dzięki Critical CSS możemy zapewnić, że witryna załaduje się z minimalną liczbą stylów, które są gwarantowane do użycia na stronie podczas jej początkowego renderowania. W ten sposób możemy sprawić, że FOUC będzie znacznie mniej zauważalne, a w większości przypadków nawet je wyeliminować. Na przykład, jeśli strona główna zawiera składnik nagłówka z nawigacją oraz składnik bohater znajdujący się w części strony widocznej na ekranie, oznacza to, że krytyczny CSS będzie zawierał wszystkie niezbędne style globalne i komponenty dla tych komponentów, podczas gdy style dla innych komponentów na stronie zostanie odroczone.

Ten kod CSS jest wbudowany w HTML pod znacznikiem style , więc style są ładowane i analizowane wraz z plikiem HTML. Chociaż spowoduje to nieco większy rozmiar pliku HTML (który również należy zminimalizować), wszystkie inne niekrytyczne CSS zostaną odroczone i nie zostaną załadowane od razu, a witryna będzie renderować się szybciej. Podsumowując, korzyści przewyższają wzrost rozmiaru pliku HTML.

 <head> <style type="text/css"><!-- Minified Critical CSS markup --></style> </head>

Istnieje wiele zautomatyzowanych narzędzi i pakietów NPM, w zależności od konfiguracji, które mogą wyodrębnić krytyczne CSS i wygenerować odroczone arkusze stylów.

Odraczanie arkuszy stylów

Jak dokładnie sprawimy, by CSS był nieblokujący? Wiemy, że nie powinno się do niego odwoływać w elemencie head HTML, gdy strona HTML jest pobierana po raz pierwszy. Demian Renzulli przedstawił tę metodę w swoim artykule.

Nie ma natywnego podejścia HTML (jak dotąd) do optymalizacji lub odroczenia ładowania zasobów blokujących renderowanie, więc musimy użyć JavaScript, aby wstawić niekrytyczny arkusz stylów do znaczników HTML po początkowym renderowaniu. Musimy również upewnić się, że te style są ładowane w sposób nieoptymalny (blokujący renderowanie), jeśli użytkownik odwiedza stronę z wyłączoną obsługą JavaScript w przeglądarce.

 <!-- Deferred stylesheet --> <link rel="preload" as="style" href="path/to/stylesheet.css" onload="this.onload=null;this.rel='stylesheet'"> <!-- Fallback --> <noscript> <link rel="stylesheet" href="path/to/stylesheet.css"> </noscript>

Dzięki link rel="preload" as="style" zapewniasz, że plik arkusza stylów jest żądany asynchronicznie, podczas gdy obsługa JavaScript przy onload zapewnia, że ​​plik jest ładowany i przetwarzany przez przeglądarkę po zakończeniu ładowania dokumentu HTML. Potrzebne jest trochę czyszczenia, więc musimy ustawić onload na null , aby uniknąć wielokrotnego uruchamiania tej funkcji i niepotrzebnego ponownego renderowania.

Dokładnie w ten sposób Smashing Magazine obsługuje swoje arkusze stylów. Każdy szablon (strona główna, kategorie artykułów, strony artykułów itp.) ma krytyczny CSS , wpisany w tag style HTML w elemencie head , oraz odroczony arkusz stylów main.css , który zawiera wszystkie niekrytyczne style.

Jednak zamiast przełączać parametr rel , możemy zobaczyć, że zapytanie o media jest przełączane z automatycznie opóźnionych mediów print o niskim priorytecie na atrybut all o wysokim priorytecie po zakończeniu ładowania strony. Jest to alternatywne, równie opłacalne podejście do odraczania ładowania niekrytycznych arkuszy stylów.

 <link href="/css/main.css" media="print" onload="this.media='all'" rel="stylesheet">

Dzielenie i warunkowe ładowanie arkuszy stylów za pomocą zapytań o media

W przypadkach, gdy ostateczny plik arkusza stylów ma duży rozmiar, nawet po zastosowaniu wyżej wymienionych optymalizacji, można podzielić arkusze stylów na wiele plików na podstawie zapytań o media i użyć właściwości media w arkuszach stylów, do których odwołuje się element HTML łącza, aby je warunkowo załadować .

 <link href="print.css" rel="stylesheet" media="print"> <link href="mobile.css" rel="stylesheet" media="all"> <link href="tablet.css" rel="stylesheet" media="screen and (min-width: 768px)"> <link href="desktop.css" rel="stylesheet" media="screen and (min-width: 1366px)">

W ten sposób, jeśli zastosuje się podejście mobile-first, style dla większych rozmiarów ekranu nie będą pobierane ani analizowane na urządzeniach mobilnych, które mogą działać w wolniejszych lub zawodnych sieciach.

Powtórzę tylko, że metoda ta powinna być stosowana, jeśli wynikiem wcześniej wspomnianych metod optymalizacji jest arkusz stylów o nieoptymalnym rozmiarze pliku. W zwykłych przypadkach ta metoda optymalizacji nie będzie tak skuteczna ani skuteczna, w zależności od rozmiaru arkusza stylów.

Odraczanie plików czcionek i arkuszy stylów

Odroczenie arkuszy stylów czcionek (na przykład plików czcionek Google) może być również korzystne dla początkowej wydajności renderowania. Doszliśmy do wniosku, że arkusze stylów blokują renderowanie, podobnie jak pliki czcionek, do których odwołuje się arkusz stylów. Pliki czcionek również znacznie obciążają początkową wydajność renderowania.

Ładowanie arkuszy stylów czcionek i plików czcionek to złożony temat i zagłębienie się w to wymagałoby zupełnie nowego artykułu, aby wyjaśnić wszystkie możliwe podejścia. Na szczęście Zach Leatherman nakreślił wiele realnych strategii w tym niesamowitym, kompleksowym przewodniku i podsumował zalety i wady każdego podejścia. Jeśli korzystasz z czcionek Google, Harry Roberts nakreślił strategię najszybszego ładowania czcionek Google.

Jeśli zdecydujesz się na odroczenie arkuszy stylów czcionek, otrzymasz Flash of Unstyled Text (FOUT). Strona będzie początkowo renderowana z czcionką rezerwową, dopóki nie zostaną pobrane i przeanalizowane pliki czcionek opóźnionych i arkusze stylów, po czym zostaną zastosowane nowe style. Ta zmiana może być bardzo zauważalna i może powodować przesunięcia układu i dezorientować użytkowników, w zależności od indywidualnego przypadku.

Barry Pollard przedstawił kilka strategii, które mogą nam pomóc w radzeniu sobie z FOUT i opowiedział o nadchodzącej funkcji CSS dostosowującej rozmiar, która zapewni łatwiejszy, bardziej natywny sposób radzenia sobie z FOUT.

Optymalizacje po stronie serwera

Kompresja HTTP

Oprócz minifikacji i optymalizacji rozmiaru plików, statyczne zasoby, takie jak pliki HTML, CSS, pliki JavaScript itp. Algorytmy kompresji HTTP, takie jak Gzip i Brotli, mogą być użyte do dodatkowego zmniejszenia rozmiaru pobieranego pliku.

Kompresja HTTP musi być skonfigurowana na serwerze, co zależy od stosu technicznego i konfiguracji. Jednak korzyści w zakresie wydajności mogą się różnić i mogą nie mieć tak dużego wpływu, jak standardowe minimalizowanie i optymalizacja arkusza stylów, ponieważ przeglądarki nadal będą dekompresować skompresowane pliki i muszą je przeanalizować.

Buforowanie arkuszy stylów

Buforowanie plików statycznych jest użyteczną strategią optymalizacji. Przeglądarki nadal będą musiały pobierać pliki statyczne z serwera przy pierwszym ładowaniu, ale gdy zostaną zbuforowane, będą ładowane z niego bezpośrednio przy kolejnych żądaniach, przyspieszając proces ładowania.

Buforowanie można kontrolować za pomocą nagłówka Cache-Control HTTP na poziomie serwera (na przykład przy użyciu pliku .htaccess na serwerze Apache).

Za pomocą max-age możemy wskazać, jak długo plik powinien pozostać w pamięci podręcznej (w sekundach) w przeglądarce, a za pomocą public , wskazujemy, że plik może być buforowany przez przeglądarkę i inne pamięci podręczne.

 Cache-Control: public, max-age=604800

Bardziej agresywną i skuteczną strategię pamięci podręcznej dla zasobów statycznych można osiągnąć dzięki immutable konfiguracji. To informuje przeglądarkę, że ten konkretny plik nigdy się nie zmieni i że wszelkie nowe aktualizacje spowodują usunięcie tego pliku, a jego miejsce zajmie nowy plik o innej nazwie. Nazywa się to pomijaniem pamięci podręcznej .

 Cache-Control: public, max-age=604800, immutable

Bez odpowiedniej strategii pomijania pamięci podręcznej istnieje ryzyko utraty kontroli nad plikami, które są buforowane w przeglądarce użytkownika. Oznacza to, że jeśli plik miałby się zmienić, przeglądarka nie będzie wiedziała, że ​​powinna pobrać zaktualizowany plik i nie używać przestarzałego pliku z pamięci podręcznej. Od tego momentu praktycznie nic nie możemy zrobić, aby to naprawić, a użytkownik utknie z nieaktualnym plikiem, dopóki nie wygaśnie.

W przypadku arkuszy stylów może to oznaczać, że gdybyśmy zaktualizowali pliki HTML o nową zawartość i komponenty, które wymagają nowego stylu, te style nie będą wyświetlane, ponieważ nieaktualny arkusz stylów jest buforowany bez strategii pomijania pamięci podręcznej, a przeglądarka nie będzie tego wiedziała musi pobrać nowy plik.

Przed użyciem strategii buforowania dla arkuszy stylów lub jakichkolwiek innych plików statycznych, należy zaimplementować skuteczne mechanizmy omijania pamięci podręcznej, aby zapobiec utknięciu nieaktualnych plików statycznych w pamięci podręcznej użytkownika. Do pomijania pamięci podręcznej można użyć jednego z następujących mechanizmów wersjonowania:

• Dołączanie ciągu zapytania do nazwy pliku.
  Na przykład styles.css?v=1.0.1. Jednak niektóre sieci CDN mogą całkowicie zignorować lub usunąć ciąg zapytania z nazwy pliku, co powoduje, że plik utknie w pamięci podręcznej użytkownika i nigdy nie zostanie zaktualizowany.
• Zmiana nazwy pliku lub dodanie skrótu.
  Na przykład styles.a1bc2.css lub styles.v1.0.1.css. Jest to bardziej niezawodne i efektywne niż dodawanie ciągu zapytania do nazwy pliku.

CDN czy samodzielny hosting?

Content Delivery Network (CDN) to grupa geograficznie rozproszonych serwerów, które są powszechnie używane do niezawodnego i szybkiego dostarczania statycznych zasobów, takich jak obrazy, filmy, pliki HTML, pliki CSS, pliki JavaScript itp.

Chociaż sieci CDN mogą wydawać się świetną alternatywą dla samoobsługowych zasobów statycznych, Harry Roberts przeprowadził dogłębne badania na ten temat i doszedł do wniosku, że samoobsługowe zasoby są bardziej korzystne dla wydajności.

„Naprawdę nie ma powodu, aby pozostawić swoje zasoby statyczne w infrastrukturze innej osoby. Postrzegane korzyści są często mitem, a nawet gdyby nie były, kompromisy po prostu nie są tego warte. Ładowanie zasobów z wielu źródeł jest wyraźnie wolniejsze”.

Biorąc to pod uwagę, zalecałbym domyślnie samodzielne hostowanie arkuszy stylów (w tym arkuszy stylów czcionek, jeśli to możliwe) i przejście do CDN tylko wtedy, gdy istnieją ku temu realne powody lub inne korzyści.

Audyt wielkości i wydajności pliku CSS

WebPageTest i inne podobne narzędzia do audytu wydajności mogą służyć do uzyskania szczegółowego przeglądu procesu ładowania witryny, rozmiarów plików, zasobów blokujących renderowanie itp. Narzędzia te mogą dać wgląd w to, jak Twoja witryna ładuje się na wielu różnych urządzeniach — od komputera stacjonarnego działającego w szybkiej sieci po smartfony z niższej półki działające w wolnych i zawodnych sieciach.

Zróbmy audyt wydajności na stronie wspomnianej w pierwszym artykule z tej serii — tej z 2MB zminifikowanego CSS.

Najpierw przyjrzymy się podziałowi zawartości, aby określić, które zasoby zajmują najwięcej przepustowości. Z poniższych wykresów widzimy, że obrazy przyjmują większość żądań, co oznacza, że ​​muszą być leniwie ładowane. Z drugiego wykresu widzimy, że arkusze stylów i pliki JavaScript są największe pod względem rozmiaru pliku. Jest to dobra wskazówka, że ​​te pliki muszą zostać zminimalizowane i zoptymalizowane, zrefaktoryzowane lub podzielone na wiele plików i załadowane asynchronicznie.

Jeszcze więcej wniosków możemy wyciągnąć z wykresów Web Vitals. Spoglądając na wykres największej zawartości treści (LCP), możemy uzyskać szczegółowy przegląd zasobów blokujących renderowanie i ich wpływ na początkowe renderowanie.

Możemy już stwierdzić, że arkusz stylów witryny będzie miał największy wpływ na LCP i statystyki ładowania. Możemy jednak zobaczyć arkusze stylów czcionek, pliki JavaScript i obrazy, do których istnieją odwołania w arkuszach stylów, które również blokują renderowanie. Wiedząc, że możemy zastosować wyżej wymienione metody optymalizacji, aby skrócić czas LCP, eliminując zasoby blokujące renderowanie.

Wniosek

Proces refaktoryzacji nie jest ukończony, gdy poprawiono kondycję i jakość kodu oraz po naprawieniu słabości i problemów z bazą kodu. Refaktoryzacja kodu powinna skutkować taką samą lub lepszą wydajnością w porównaniu do starszej bazy kodu.

Użytkownicy końcowi nie powinni doświadczać problemów z wydajnością ani długich czasów ładowania z refaktoryzowanej bazy kodu. Na szczęście istnieje wiele metod zapewniających, że bazy kodu są zarówno niezawodne, jak i wydajne — od prostych metod minifikacji i optymalizacji po bardziej złożone metody, takie jak eliminacja zasobów blokujących renderowanie i dzielenie kodu.

Możemy użyć różnych narzędzi do audytu wydajności, takich jak WebPageTest , aby uzyskać szczegółowy przegląd czasów ładowania, wydajności, zasobów blokujących renderowanie i innych czynników, dzięki czemu możemy wcześnie i skutecznie rozwiązać te problemy.

Bibliografia

• „CSS blokujący renderowanie”, Ilya Grigorik
• „Odłóż niekrytyczne CSS”, Demian Renzulli
• „Kompleksowy przewodnik po strategiach ładowania czcionek”, Zach Leatherman
• „Nowy sposób na zmniejszenie wpływu ładowania czcionek: deskryptory czcionek CSS”, Barry Pollard
• „Utrzymuj własne aktywa statyczne”, Harry Roberts
• „Optymalizuj ładowanie i renderowanie czcionek internetowych”, Ilya Grigorik