Jak uporządkować CSS na przykładzie naszego bloga

Skoro pracujemy nad nową, lepszą wersją lubik.info, pomyślałem, że warto dzielić się z Wami spostrzeżeniami podczas prac nad szablonem strony. Skoro tak, to na pierwszy ogień bierzemy arkusz stylów.

Budowanie strony na WordPress to czynność, która jest dosyć trywialna jak na dzisiejsze czasy. Szukamy szablonu, instalujemy go, konfigurujemy wtyczki i działamy. Generalnie nie ma w tym nic nadzwyczajnego jeśli nie musimy modyfikować kodu szablonu czy wtyczki – tu pojawiają się schody.

Z własnego doświadczenia wiem, że często drobne zmiany na stronie dokonywane są na bieżąco – dopisujemy dodatkowe style do pliku CSS, które nadpisują te stare. Komentujemy te, które chcemy wyrzucić „bo przecież kiedyś mogą się przydać”. Nie dodajemy do kodu żadnego szerszego komentarza – wrzucamy trzy linijki i działa. Co więcej – często dodatkowy kod dopisujemy poprzez wbudowany edytor WordPressa, który nie dość, że nie jest zbyt wygodny, to jeszcze nie dostarcza żadnych narzędzi do przeszukiwania, czy organizacji struktury pliku. Niestety jest to prosta droga do zrobienia sieczki ze swojej strony.

Biorąc pod uwagę fakt, że Sebastian uwielbia eksperymentować z różnego rodzaju efektami, a obecny szablon ma już przeszło rok, jego kod jest w stanie jakim jest. Trzy pliki (nie wliczam tu plików CSS należących do wtyczek). 8283 linie kodu, z których duża część to puste wiersze i puste selektory (takie, które nie zawierają żadnych atrybutów), część kodu skompresowana, a część nie. Do tego dołóżmy 79 wywołań media-query definiujących 22 różnych szerokości ekranu. To wszystko sprawia, że praca z takim stylem jest bardzo utrudniona. Pingdom wskazał makabryczne statystyki strony głównej bloga:

Chcąc w pracy bazować na obecnym szablonie, który jest w tak opłakanym stanie obowiązkowo należy wyczyścić takie pliki. Jak należy podejść do tego problemu?

1. Pozbywamy się niepotrzebnych plików

Niestety bardzo często jest tak, że chcąc stworzyć zależności pomiędzy CSS, a szablonem, dzielimy styl na kilka plików, które są ładowane w zależności od podstrony. Analizując kod, dotarliśmy do jednego pliku, który jest generalnie kopią drugiego, więc niemal bez wahania (z CSS nigdy nie można być niczego pewnym) usunęliśmy go. Dzięki temu zaoszczędziliśmy 45KB miejsca na dysku, a pewnie i niektóre podstrony będą ładować jeden zamiast dwóch plików.

2. Usuwamy wszystkie puste linie.

Punkt ten jest chyba oczywisty. Problemem może być tu fakt, że ciężko przejść tak długie pliki i ręcznie usuwać każdy napotkany pusty wiersz. By zautomatyzować ten proces, posłużyłem się edytorem Sublime Text 2, który pozwala wykorzystywać wyrażenia regularne podczas przeszukiwania plików.

Dzięki wyrażeniu „^[ \t]*\n” byłem w stanie zastąpić każdą pustą linię (także te zawierające tabulację) w pliku pustym ciągiem znaków, co skutkowało usunięciem zbędnych pustych przestrzeni. Na dole grafiki możecie zobaczyć, że wyrażenie, które wyszukiwało puste linie zostało dopasowane do 2547 miejsc – aż tyle „wolnego miejsca” zawierał jeden z plików. Powodzenia z usuwaniem tego manualnie ;) Klik i załatwione.

Wykorzystując inne wyrażenia z pewnością można uzyskać jeszcze lepsze efekty – ogranicza nas tylko wyobraźnia i znajomość składni regex. Ja ograniczyłem się jedynie do wyrzucenia pustych miejsc.

3. Doprowadzamy do ładu media-queries

Przyznam szczerze, że tego etapu bałem się najbardziej. Jeden nieostrożny ruch i cała strona może się rozjechać. Problemem szablonu było przede wszystkim nieuporządkowanie w tym zakresie – analizując styl, miałem wrażenie, że media queries są wtrącane w sposób losowy. Postanowiłem zebrać je na końcu pliku i uporządkować według rozmiarów.

W trakcie przenoszenia całych bloków media query, okazało się, że rozmiary podawane w tych klauzulach powtarzają się. Wniosek był jeden – należy zmniejszyć ich liczbę poprzez scalenie bloków dotyczących tych samych rozmiarów ekranu. Na każdym „wchłoniętym” odwołaniu do szerokości ekranu zaoszczędzamy dwie linie kodu oraz kilka bajtów rozmiaru pliku.

Niestety po scaleniu ze sobą tych samych media-query, okazało się, że niektóre selektory powtarzały się, a niekiedy nawet nawzajem wykluczały(!) np. gdy dany element był najpierw ukrywany, a następnie nadawany był mu styl zawierający kilka innych atrybutów. Jest to kolejne miejsce do optymalizacji i odchudzenia naszych plików CSS.

Teoretycznie duża liczba media queries nie wpływa bezpośrednio na wydajność strony. Jedynym widocznym wpływem takiego niedopatrzenia jest wzrost rozmiaru pliku CSS, który jest ładowany na stronie, a dopiero ten bezpośrednio wpływa na szybkość witryny. Jeśli chodzi o zmniejszenie liczby obsługiwanych szerokości ekranu, to nie wiele mogłem zrobić. Wygląd strony w pewnym stopniu zmieni się, a to pociągnie za sobą pewne wymogi jeśli chodzi o media queries. Mimo wszystko jestem pewien, że je mocno ograniczymy i w ten sposób zyskamy na wydajności.

Niestety w przypadku naszego bloga, media queries zostały ułożone w tak specyficzny sposób, że zmiana ich umiejscowienia w arkuszu doprowadziła do tego, że strona się rozjechała i pracę z czyszczeniem należało rozpocząć od początku. W końcu dałem za wygraną. To wcale nie takie proste ;)

Podsumowując

Mimo silnej chęci dojścia do ładu z plikami CSS na blogu, nie udało mi się z nimi wygrać. Sprowadziłem kod do dwóch plików zawierających około 4000 linii i dałem za wygraną. Niemniej jednak uważam, że powyżej opisane podejście można zastosować do wszystkich stron. Powinno sprawdzić się w przypadku nieco mniej zabałaganionego kodu. Miłej zabawy z czyszczeniem życzę, a tymczasem idę porozmawiać z Sebastianem i wyłożyć mu jak się powinno dbać o czysty kod ;)

Autor: Konrad Przydział