Szybki WordPress – Cascading Style Sheets

Następnym elementem, który wpływa na na szybkość naszej witryny jest to jak wygląda, a za wygląd dopowiadają arkusze stylów (po angielsku Cascading Style Sheets, w skrócie CSS).

Zazwyczaj sam motyw nie ma szczególnie złego pliku style.css, o ile jest jeden. Jeżeli jest ich więcej, ale są ładowane wszędzie, to jest to miejsce, któremu możemy się przyjrzeć.

Do tego dochodzą pliki CSS pochodzące z używanych wtyczek i często robi się z tego niezły bałagan. Dziesiątki, wykonywanych za każdym razem, zapytań o pliki definiujące wygląd to spadek szybkości działania o kilka punktów procentowych – czyli coś czego staramy się uniknąć.

Wiele plików

Czy faktycznie wiele plików CSS to taki problem?

I tak i nie. To zależy.

Rozważmy prymitywny scenariusz, który dotyka większość niezoptymalizowanych witryn opartych o WordPressa: motyw, kilka wtyczek dają w efekcie kilka do kilkunastu plików CSS ładowanych przy każdej pobieranej stronie.

Dobrze napisana wtyczka powinna ładować swoje pliki wtedy kiedy jest używana. Jednak spora część z nich jest użyta w całej witrynie, bo dodają stały element, co oznacza, że muszą ładować swoje pliki wszędzie.

Efekt jest łatwy do przewidzenia, mamy witrynę w której ładowane jest kilka lub kilkanaście plików CSS.

Jeden plik

A gdyby tak mieć tylko jeden plik odpowiedzialny za wygląd?

Jest to do zrobienia i zazwyczaj jest to jeden z elementów optymalizacji szybkości działania witryny – połączenie wielu plików w jeden.

Można to zrealizować na kilka sposobów – albo automatycznie, za pomocą jednej z kilku istniejących wtyczek, albo ręcznie.

Wtyczką, którą najczęściej spotykam jest Autoptimize, która robi naprawdę dobrą robotę.

Drugi sposób, to ręczna optymalizacja, która niestety jest sporo droższa od włączenia wtyczki. Oprócz łączenia plików, zawsze staram się wtedy jeszcze spróbować po prostu wyłączyć część plików CSS zastępując je tylko tym co w danej witrynie jest potrzebne. Dodatkową zaletą tego rozwiązania jest uwspólnianie części kodu oraz większa zgodność wyglądu elementów pochodzących od różnych dostastwców.

Jak to łącze pliki?

Do połączenia plików w jeden używam grunta wraz z odpowiednią konfiguracją, zawierającą oprócz plików motywu, pliki z wtyczek.

Jeżeli chodzi o pliki ładowane przez wtyczki, to zazwyczaj wystarczy użyć funkcji wp_deregister_style(), dzięki czemu można wyrejestrować pliki zanim zostaną załączone.

Ale jednak wiele plików

W rozwiązaniach, gdzie ekstremalnie bardzo liczy się dla nas szybkość, uzyskany powyżej plik nie będzie zbyt dobry. Tam gdzie liczą się naprawdę ułamki sekund, a biznes jest na tyle duży, że jest sens to robić – rozbijamy CSS na wiele plików…

ALE JAK TO? Przed chwilą pisałeś…

No tak, pisałem, teraz napiszę coś innego.

Metoda wielu plików w którym rozbijamy CSS na części ładowane w zależności od miejsca w którym się znajdujemy. Na przykład część związanej ze stylowaniem formularza komentowania – ładujemy tylko tam, gdzie jest taki formularz.

Proste? Proste, tylko bardzo kosztowne w implementacji, a zysk jest niewielki, dlatego pisałem o skali. Dla naprawdę wielkich serwisów, setki milisekund to coś o co warto walczyć, bo przekłada się to albo na sprzedaż, albo na niższe koszty utrzymania serwerów.

Pisanie uważne

Przy motywach pisanych na zamówienie liczba reguł w pliku CSS zazwyczaj jest mniejsza, ponieważ obsługujemy dokładnie te funkcjonalności, które znajdują się w motywie.

Ale nawet to można napisać w różny sposób. Preprocesory CSS dają niesamowite możliwości: szybko i łatwo kodujemy wygląd, ale wynikowy plik często ma bardzo długie selektory. Zazwyczaj w niczym nie przeszkadzają, ale jest to element na który warto zwrócić uwagę.

Z drugiej strony prepocesory pozwalają minimalizować cały plik. Taki plik zawiera tylko minimalną ilość znaków białych (spacji, tabulatorów, enterów), choć to już mało IMVHO potrzebna opcja, ponieważ wszystkie pliki CSS powinny być w trakcie wysyłki pakowane gzipem … ale to już inny kawałek optymalizacji.

Wersje

Niektóre z wtyczek, ucinają kawałek urla do zasobu z wersją tego zasobu, czyli np. ?v=2.1.0. Co z jednej strony pozwala na lepsze wykorzystanie cache przeglądarki, z drugiej utrudnia propagowanie zmian i z tego powodu uważam coś takiego za błędne i nieprawidłowe.

Podsumowując

• eliminuj zbędny kod
• łącz pliki
• skracaj selektory