16 Usability / dostępność stron 7 minut czytania

Optymalizacja strony: CSS i JS

Od ostatnich wpisów z tego cyklu - czyli serii porad na temat optymalizowaniu serwisów internetowych - minęło trochę. Ponad rok. Od tego czasu trochę się zmieniło, tym bardziej, że zapowiadałem, że pojawi się trochę na temat. Nie ma co ukrywać, że Internet bardzo się rozwija: są coraz szybsze łącza, serwery przez co niektórzy, mówiąc wprost, olewają temat. Z drugiej strony coraz bardziej popularny staje się Internet mobilny (pojawiają się telefony z WiFi i nie tylko). Czy prócz zmiany tytułu strony, poprawy semantyki kodu HTML można zrobić coś jeszcze, co sprawi, że nasza strona będzie szybsza, lepsza, lżejsza i w ogóle super?

W brew pozorom tak. I to dużo. Bardzo. Google w swojej filozofii próbuje od bardzo dawno wbić webmasterom do głowy, żeby nie patrzyli na strony tak jak robot. Czyli:

  • czy jest odpowiednie natężenie słów kluczowych,
  • jak wysoki jest PR,
  • skąd jeszcze brać linki,
  • czy linków wewnętrznych nie ma za dużo,
  • czy nie przesadziłem z opisem i słowami kluczowymi w meta tagach,
  • czy wszystkim linkom wychodzącym z mojej strony dać nofollow?

Te i wiele innych pytań zaczynają martwić każdego webmastera, który zaczyna zabawę z SEO a nawet starego wyjadacza (a spotkałem już takich kilku). I to jest błąd. Bo takie zbyt intensywne optymalizowanie prędzej czy później doprowadzi do przeoptymalizowania (over optimalisation) strony i cały nasz wysiłek pójdzie na marne.

Można się tutaj skupić tak na prawdę na dwóch rzeczach.

  1. arkusze stylów,
  2. skrypty JavaScript.

W obu przypadkach chodzi o zmniejszenie ich wagi (objętości). Zarówno pliki CSS i JS można bardzo fajnie kompresować. Dlaczego warto kompresować? Mniejszy czy lżejszy plik szybciej się wczyta użytkownikowi oraz zaoszczędzimy na transferze. Przy mniejszym ruchu nic nie odczujemy np. 100 wejść dziennie, ale już przy 10000 (i więcej) wejściach dziennie już będzie widać jak transfer się nam zmniejsza. Są compresory online plików JS i CSS, dzięki którym można zmniejszyć wagę pliku nawet o 30-40%.

Kolejna rzecz to ilość zapytań do naszej strony. Przeglądarki mają ustawione domyśle wartości maksymalnych odpytań, np. w Firefoxie jest to 6 zapytań dla domeny. Tak więc, jeżeli dołączamy dużo plików CSS i JS powoduje to, że strona się dłużej wczytuje. Bo przy zajętych wszystkich sześciu "kanałach" trzeba poczekać aż co najmniej jeden się "zwolni". Proponowanym tutaj rozwiązaniem jest scalanie (marge'owanie) plików w jeden. Ma to oczywiście swoje plusy i minusy.

Plusem i jednocześnie minusem jest to, że mamy jeden plik JS / CSS przez co użytkownik wysyła np. tylko jedno żądanie o plik a nie jak to bywa w bardziej rozbudowanych serwisach po kilka. Ten minus to fakt, że większy plik może wygenerować więcej transferu. Wszystko tak naprawdę zależy od skomplikowania serwisu i jego wielkości. W przypadku mniejszych serwisów sprawa jest dość prosta. W przypadku bardziej rozbudowanych dobrym zwyczajem jest stworzenie specjalnych subdomen, które będą magazynować pliki CSS i JavaScript. W przypadku mojego bloga mogłoby to być coś takiego: css.shpyo.net i js.shpyo.net. Dzięki temu zapytania rozkładają się o dodatkowe adresy i nie ma "zapychania" się "kanałów".

Pliki JS na sam dół kodu HTML. W przypadku tej "sztuczki" - wrzucanie plików JavaScript na sam dół - spotkałem się z opinią, że jest teraz na to moda. Nie będę mówił, którzy to specjaliści, ale podejrzewam, że modne jest (bardziej?) lenistwo. Ale do rzeczy. Dlaczego warto umieszczać skryptu JS na końcu kodu HTML - przed zamknięciem tagu body? Ano dlatego, że skrypt jest uruchamiany po załadowaniu się całej strony. A co to oznacza dla Internaty odwiedzającego Twoją stronę? To, że strona się szybko wczyta i nie będzie czekał aż JavaScripty skończą się wczytywać w różnych miejscach np. w headzie, w środku czy nawet jakieś zewnętrzne skrypty. To wszystko może denerwować i frustrować Internautę. Dzisiaj większość fajnych skryptów uruchamia się na "onPageLoad" - czyli po wgraniu się całej strony (musi się wgrać cała struktura HTML, CSS i inne JSy). Po za tym, najpopularniejsza biblioteka JS - jQuery - jest samoodpalającym się skryptem, bez względu w którym miejscu zostanie umieszczony. Tak więc po co złościć Twoich odwiedzających? Zawsze będą mogli przejść do konkurencji. Jeżeli jeszcze masz jakieś wątpliwości to odpowiedz sobie na takie oto pytanie: ile razy się Tobie zdarzyło, że musiałeś czekać, aż jakaś informacja na się załaduje do końca?

Ten temat to dopiero wierzchołek góry lodowej i jest tylko krótkim wstępem (jak na ten dość długi wpis). Mam nadzieję tylko, że trochę rozjaśniłem Wam ten temat i jeśli zastosujecie choć część tego co tutaj opisałem to będzie sukces.



Raz w miesiącu e-mail z najlepszymi artykułami

Zdjęcie autora wpisu - Piotr Cichosz

Piotr Cichosz — autor wpisu

Frontend developer. Tworzę zaawansowane systemy webowe w JS. Swoją wiedzę nt. SEO wykorzystuję do rozwijania własnych projektów (z lepszym lub gorszym efektem). Dużo eksperymentuję i staram się określić jak bardzo można nagiąć cierpliwość algorytmów Google (:.

Zobacz podobne wpisy

Komentarze 16

author Marcin Pietrzak www 25.06.2010 11:08:29

Fajny trick z umieszczaniem dodatkowych CSSów i JSów do strony pod osobnymi subdomenami. Wiedziałem coś tam o tych kanałach Firefoxa (inne przeglądarki mają chyba analogiczne rozwiązania, prawda?), ale nigdy nie znałem konkretów ani sztuczek jak sobie łatwo z tym poradzić. Naprawdę ciekawa uwaga :)

Nie zgodzę się troszkę z końcówką, odnośnie momentu wgrywania skryptów. Faktycznie, swego czasu dominowało uruchamianie ich onLoad, czyli gdy wszystkie pliki (CSS, JS... ale także i grafiki) zostały w pełni załadowane. Obecnie skrypty najlepiej uruchamia się w momencie onDOMReady, czyli gdy struktura tagów HTMLa została załadowana w całości (niezależnie od tego, czy zostały już pobrane dodatkowe pliki styli lub grafik). Dzięki temu możemy odpalić jakieś funkcje JS na tyle szybko, aby użytkownik nie zdążył się zorientować :)

Sprostuję też info o jQuery. jQ nie jest samoodpalającym się skryptem. Gdy załadujesz tą bibliotekę nie dzieje się nic. Aby cokolwiek się stało musisz dopisać odpowiednie polecenie, które potem uruchamiasz wtedy gdy jest Ci to potrzebne, np. onLoad, onDOMReady lub w momencie jakiejś interakcji ze strony użytkownika.

Ogólnie wpis porusza ciekawy temat, gratuluję :)

author shpyo www 25.06.2010 11:11:44

@Marcin: Masz rację co do jQuery. Ĺšle się wyraziłem. Chodziło mi o to, że "samoodpalającym" = inicjalizacja :)

author Easy_R www 25.06.2010 11:25:51

fajny art, mozna bylo dopisac cos o css sprites (http://www.onet.pl/_d/d7c1a2f023463e6eb077f4cd1269216f,s_1_0.png)

author Jurgi Filodendryta www 25.06.2010 17:35:10

To ja z pytaniem: czy serwer ma jakiś wpływ na cache'owanie plików przez przeglądarkę? Bo wydaje mi się, że tak. Z wrażeń codziennego używania różnych przeglądarek odniosłem wrażenie, że domyślnie korzystają z cache'owania w różny sposób. Wpływając na ich zachowanie w tej materii można by sporo zbędnego ruchu obciąć.

author Kamil www 25.06.2010 18:55:29

@Jurgi: Tak, serwer ma dużo do powiedzenia w kwestiach buforowania & kompresji obiektów po stronie klienta. Pisałem co nieco o tym na swoim blogu, ale nie będę tutaj spamował (jak chcesz to poczytaj przykładowo o mod_expires w Apache, nagłówku HTTP ETag czy module mod_deflate).

@shpyo: Dobrze, że poruszyłeś temat. Sprawa takich prostych optymalizacji jest naprawdę kwestią kilkunastu minut, a mimo to tak niewielu wykonuje te podstawowe optymalizacje. Kilka linijek kodu może kilkukrotnie zmniejszyć ilość zużywanego transferu (i pobranych kb przez klienta), więc warto o tym pisać do skutku!

Sam też kiedyś co nieco napisałem o tym:
http://blog.kamilbrenk.pl/minimalizacja-zapytan-http/

Pozdrawiam :)

author Lexy www 01.07.2010 12:06:41

To akurat zagadnienie, które ostatnio w szczególności mnie zainteresowało. Bardzo dobry art... mam nadzieję, że będą kolejne na ten temat.

author Marcin www 14.07.2010 12:50:29

Heh niby zawsze wiedziałem że im mniej plików css i js to strona się szybciej ładuje ale i tak przy niewielkich stronach to nie ma większego znaczenia czy są 2 pliki css czy 4 bo i tak zajmują po kilka kilobajtów tylko. Ale artykuł ciekawy i przy większych stronach czy też na blogach może się przydać.

author Tomek www 15.07.2010 14:09:03

Prawie 3 lata temu robiłem takie testy z optymalizacją CSS'ów, a wyniki przedstawiłem we wpisie:
http://nastulak.6rano.pl/2007/10/20/optymalizacja-css/
Nie zawsze uzyska się te 30-40%. To wszystko zależy czy już odpowiednio przygotowaliśmy arkusz - od naszych umiejętności, od złożoności, wielkości arkusza itd.

author Adam www 05.08.2010 13:01:35

Problem jest, że ludzie stosują duże biblioteki z JS, zamiast napisać kawałek kodu samemu. Np. walidacja formularza to 25 linijek JS a ile waży np. jQuery ? Przy dedykowanych kodach nie trzeba optymalizacji.

author Spambot www 08.08.2010 19:31:00

Pare miesięcy temu też sobie optymalizowałem kilka stron głównie bazując na wtyczce do firefoxa Page Speed
również było tam o przeniesieniu nie tylko css i js ale również obrazków na subdomeny
lecz aby działało to poprawnie należy dla subdomeny stworzyć odpowiednie rekordy
w taki sposób aby nie zczytywało cookies
wie ktoś może jaki to trzeba rekord ustawić czy to ma byc rekord cname czy rekord A
oraz może ktoś się orientuje co znaczy skrót CND ?

author Anka www 08.08.2010 19:47:03

Generalnie ciekawy artykuł o tym, że strona powinna szybko się wyświetlać, taka jak np. moja strona www.anka-bizuteria-sklep.pl . Czy te szczegóły techniczne naprawdę są przedmiotem SEO, czy rzemiosło SEO odchodzi do lamusa i są naturalne reguły i Google?

author Warchol www 30.09.2010 11:15:39

Szkoda, że brakuje o css sprites bo to przydatna metoda.

author Adam www 05.08.2010 13:01:35

Problem jest, że ludzie stosują duże biblioteki z JS, zamiast napisać kawałek kodu samemu. Np. walidacja formularza to 25 linijek JS a ile waży np. jQuery ? Przy dedykowanych kodach nie trzeba optymalizacji.

author Spambot www 08.08.2010 19:31:00

Pare miesięcy temu też sobie optymalizowałem kilka stron głównie bazując na wtyczce do firefoxa Page Speed
również było tam o przeniesieniu nie tylko css i js ale również obrazków na subdomeny
lecz aby działało to poprawnie należy dla subdomeny stworzyć odpowiednie rekordy
w taki sposób aby nie zczytywało cookies
wie ktoś może jaki to trzeba rekord ustawić czy to ma byc rekord cname czy rekord A
oraz może ktoś się orientuje co znaczy skrót CND ?

author Anka www 08.08.2010 19:47:03

Generalnie ciekawy artykuł o tym, że strona powinna szybko się wyświetlać, taka jak np. moja strona www.anka-bizuteria-sklep.pl . Czy te szczegóły techniczne naprawdę są przedmiotem SEO, czy rzemiosło SEO odchodzi do lamusa i są naturalne reguły i Google?

author Warchol www 30.09.2010 11:15:39

Szkoda, że brakuje o css sprites bo to przydatna metoda.

Dodaj komentarz