Jestem wielkim fanem “szybkiej sieci” i całej inicjatywy Google do przyspieszania stron i serwisów WWW. Pomijam ciężkie do implementacji dla zwykłego webmastera techniki SPDY, ale cała dozwolona reszta – jak najbardziej. Optymalizacja kodu HTML, CSS czy JavaScript to zadania dla każdego webmastera. Do tego dochodzi oczywiście optymalizacja i oszczędzenia na najcięższych elementach stron WWW – obrazkach.
JPEGmini to technologia oczekująca na patent, pozwalająca na zmniejszenie rozmiarów zdjęć bez pogorszenia ich jakości. Brzmi obiecująco prawda? Najlepsze jest to, że w przeciwieństwie do WebP nie wymaga żadnych dodatków pluginów, obsługiwana jest przez każdą przeglądarkę bo tak naprawdę JPEGmini to zwykły plik typu JPG tylko odpowiednio zoptymalizowany.
Kilka razy już wspominałem o tym, że prędkość ładowany jest bardzo ważna, ale nigdy nie opowiedziałem na pytanie “dlaczego?”. “Słowacki wielkim poeatą był!” – z tym się nie dyskutuje, strona musi być szybka. Sztampowa opinia, większość powtórzy ją bez żadnego wahania. Bo szybciej znaczy lepiej, ale… dlaczego?
Jakiś czas temu Google wyliczyło, że jeżeli strona ładuje się “szybciej” to generuje 20% więcej przychodów. Wszystko idzie więc w kierunku przyspieszania i optymalizacji tego co się da. Są dwa rodzaje operacji jakie możemy wykonać w celu przyspieszenia ładowania strony. Część z nich to zadania server-side, które polegają na optymalizacji generowania strony, przepływu informacji do klienta (kompresja stron, css, JavaScript, cache’owanie zapytań SQL itp, itd). Druga strona to wizualne tricki, które powodują, że strona renderuje się “szybciej” w przeglądarce klienta.
Temat optymalizacji i przyspieszania skryptów, serwerów i komputerów towarzyszy mi od zawsze. Pisałem już trochę o wszelkiego rodzaju mikro optymalizacjach, o cache’owaniu wyników PHP, przyspiesznaiu serwerów poprzez rozwiązania typu eaccelerator, ale jakoś pominąłem podstawowy i ważny aspekt prawie każdego projektu – serwer MySQL.
Optymalizacji ciąg dalszy 🙂 Page Speed Online często doczepia się do ustawienia expiry date dla plików, które mają być długo cache’owane. Generalnie chodzi o to, żeby przeglądarka automatycznie cache’owała nam pliki jak najdłużej sięda – pliki naszego serwisu, które nie często sięzmieniają jak biblioteki CSS czy JS, a nawet niektóre obrazki.
Jak to zrobić jeżeli nasze strony serwuje lighttpd? Z pomocą przychodzi nam mod_expire – moduł przeznaczony dokładnie do tego zadania. Oczywiście nie będziemy się bawić w zbędne wstępy – esencja.
Od jakiegoś czasu ta strona, oraz kilka innych pracuje w chmurze Amazonu . Na moje mikro potrzeby, pracuję tylko z Micro instancją na EC2 – mocy procesora zupełnie wystarcza, wąskim gardłem jest oczywiście RAM – 613MB. Wprawdzie ruch, który generuję w serwisie nie jest specjalnie wysoki, ale wiadomo – RAMu nigdy nie za dużo.
W ramach oszczędności postanowiłem wymienić starego tłustego kota o imieniu Apache, na coś lżejszego i szybszego – Lighttpd . Dodatkowo mod_php zamieniło się na fast_cgi i w sumie to wszystko.
LABjs czyli Loading And Blocking JavaScript to ciekawa bblioteka, która pozwala na ładowanie i blokowanie ładowania JavaScriptów z poziomu samego JavaScritpu 😉 Dzięki czemu teoretycznie zyskujemy na prędkości ładowania się strony, oraz mamy większą kontrole nad naszymy skryptami. Dlaczego teoretycznie ? Bo praktycznie ładowanie JavaScript nie wpływa na “renderowanie” wyglądu strony, natomiast może mieć znaczenie przy projektach, które faktycznie posiadają większą ilość kodu.
