Jak zwiększyć wydajność dynamicznej strony www?

Każdy właściciel rozwijającej się strony internetowej, staje z czasem przed problemem zbyt niskiej wydajności serwera, która to hamuje dalszy rozwój strony. Rozwiązania są w sumie 3, albo pozostawimy sprawę tak jak jest i w rezultacie albo serwer całkowicie odmówi posłuszeństwa, albo nasi ciężko zdobyci użytkownicy zaczną odpływać z racji nie działającej dobrze strony, drugie już nieco lepsze, ale też i nie tanie, to zmienić hosting na znacznie wydajniejszy. Pozwoli to na pewno przynajmniej na jakiś czas odgonić problem. Użytkownicy tzw chmury mają tu ten komfort, że nie muszą w sumie niczego przenosić, dopłacają tylko do hostingu za określony procent dodatkowej „mocy” serwera „chmury”, W pozostałych przypadkach niestety trzeba się liczyć z tym, że dane, często obszerne bazy, będziemy musieli przenieść na inny, lepszy sprzęt. Trzeci sposób, najlepszy z mojego punktu widzenia, to optymalizacja projektu. I na tym nieco chciałbym się skupić w tymże artykule. Zakładam, że projekt korzysta z popularnych technologii, wykorzystując apache, php, mysql, html, css, js. Co możemy zatem zrobić, by nasza strona nie działała jak muł pasiasty?

  • Na początek dobrze jest skupić się na rozmiarze plików projektu, począwszy od *.php, poprzez *.css, *.js , wideo oraz grafik. Oczywiście dążymy do tego, by zachować funkcjonalność i wygląd danego pliku przy jak najmniejszym rozmiarze.
  • Łączymy pliki tego samego rodzaju w jeden. Pozwoli to zmniejszyć ilość wywołań serwera przy pojedynczym połączeniu, użytkownik zamiast wysyłać setki żądań o pobranie poszczególnych plików js, css, grafik, wysyła tylko kilka.
  • Optymalizujemy kod PHP, funkcje, etc. Przy krytycznie niskiej wydajności warto pomyśleć też np o przejściu na język obiektowy lub gotowe, sprawdzone frameworki.
  • Włączamy kompresję dla plików. Pliki styli, czy js, można przecież wysłać do przeglądarki także w formie spakowanej gzipem! Efekt ten sam, a po spakowaniu – tekst często zajmuje kilkakrotnie mniej miejsca.
  • Włączamy kompresję w PHP. Tu musimy rozważyć najpierw, czy dany projekt będzie wydajniejszy, jeśli go przed wysłaniem spakujemy, czy też wyślemy od razu bez kompresji. Włączenie kompresji nie zawsze przyśpiesza projekt, można tu także nieco poeksperymentować np pakując tylko część kodu, a część wysyłać normalnie.
  • Optymalizujemy działanie bazy danych. Dość szerokie to zagadnienie, do dyspozycji mamy sporo narzędzi i trików, jednym z najprostszych sposobów zwiększenia szybkości działania bazy jest wprowadzenie indeksów, pozbycie się nadmiarowości w tabelach, przeredagowanie zapytań na wydajniejsze. Częsty błąd to stosowanie w nadmiarze klauzuli JOIN, pobieranie w nadmiarze danych, a potem zbędne odsiewanie przez php, wykluczające się warunki po WHERE, zbyt duża ilość połączeń do bazy, eliminujemy nadmiar zapytań poprzez np łączenie różnych pobrań w jedno, itp.
  • Cache’owanie wyników zapytań do bazy danych. Generalnie chodzi o zmniejszenie ilości wywołań bazy danych w przypadku, kiedy mamy do czynienia z identyczną strukturą zapytania wykonywaną wielokrotnie, np przez różnych użytkowników. Wówczas wynik zapytania można zapisać do pliku, następnie przy kolejnym wywołaniu skryptu, nie pobieramy już danych z bazy i je potem formatujemy przez php, a wczytujemy już gotowy plik wygenerowany w pierwszym zapytaniu z pominięciem już zapytania do bazy. Nieco chyba zamotane zdanie, ale generalnie chodzi o to, aby powtarzające się sformatowane dane zapisać do gotowego pliku i potem już nie maglować ciągle w tym samym temacie bazki. Co więcej, bazy danych także same w sobie obsługują cache. Przynajmniej MySQL taką właściwość posiada. Więcej na ten temat może niebawem.
  • Blokada zbędnego ruchu na serwerze także potrafi dać stronie niezłego kopa. Możemy to zrobić programowo w PHP odmawiając określonym hostom dostępu, lub lepiej w .htaccess lub httpd.conf. Ewentualnie w pliku robots, ale to bardziej na zasadzie sugestii, niż nakazu.
  • Zmiana kolejności ładowania się plików styli i js. Zaleca się, aby pliki „konstrukcyjne” dla strony załadować możliwie najwcześniej, a pliki sterujące interfejsem, wprowadzające interaktywność, lub np obsługę reklam, statystyk, załadować na samym końcu. Dzięki temu po wejściu na stronę użytkownik niemal od razu zobaczy ładującą się stronę.
  • Koniecznie pozbywamy się także błędów składni html i css, im strona poprawniejsza, tym naturalnie przeglądarka jest w stanie lepiej ją zinterpretować, zrozumieć, załadować. Częsty błąd, to ładowanie na stronę nie istniejących już plików, nie określenie rozmiaru grafik, zła kolejność „domykaczy” znaczników, itp.
  • Unikamy ładowania dużych plików z własnego serwera. Np filmy możemy z powodzeniem wysłać na YouTube lub inny, szybki serwer magazynujący wideo i dopiero z takiego źródła go pobierać. Duże pliki są niestety problemem na serwerach niższej klasy, które w ogólnie dostępnych pakietach, mają niestety dość wąską przepustowość.
  • W plikach tekstowych pozbywamy się zbędnych znaków, zbędnych spacji, tabulacji, enterów. Nawet puste znaki użyte w nadmiarze sprawiają, że pliki rosną. Nie musimy także robić tego ręcznie, w sieci są gotowe narzędzia, które w locie oczyszczą nasze pliki. Co więcej, możemy to także zrobić we własnym zakresie pół automatycznie np pisząc odpowiednią funkcję w PHP, która to sprawi, że z tekstu zostaną wycięte wszystkie niepotrzebne znaki. Obróbce z powodzeniem możemy poddać niemal wszystkie pliki tekstowe.
  • Jako, że niemal każdy projekt używa jquery, staramy się zatem używać jak najnowszej wersji, wersji skompresowanej, oraz testujemy wariant z zewnętrznym źródłem tego pliku, jak i z lokalnym. Wybieramy oczywiście szybszy.
  • Możemy także skorzystać z gotowych narzędzi, które za nas przeprowadzą podobną analizę. Większość dobrych jest niestety płatna. Zaś z darmowych i całkiem dobrych można wykorzystać np pagespeed od google. Narzędzie o tyle ciekawe, że analizuje wydajność w 2 wariantach – urządzenie mobilne i urządzenie stacjonarne, zaś znalezione problemy sortuje i grupuje począwszy od krytycznych aż po delikatne ostrzeżenia. Jeśli już ktoś zapragnie być na ostro w zgodzie z obowiązującymi standardami, można także odpalić walidator W3C i sprawdzić stronę, css, itp na różne sposoby. Nawet dobrze napisana strona często ma błędy i nie jeden webmaster przez to narzędzie nie mógł spokojnie spać 😉
  • Stosujemy monitoring strony w postaci statystyk. Z jednej strony, niestety, użycie dodatkowego kodu statystyk, sprawia, że strona jest odrobinę wolniejsza, dlatego zaleca się, aby załączać je na samym końcu kodu przed sekcją </body></html>, z drugiej zaś strony, dostarczają nam niezbędnych informacji na temat, kto i skąd nas odwiedza, na jakich urządzeniach, w jakim czasie, z jakich źródeł, itp. Wyciągnięcie wniosków z dobrych statystyk nie jest trudne, a dzięki temu możemy odpowiednio dostosować nasz projekt, by działał jeszcze wydajniej. Spokojnie można polecić np www.google.com/analytics. Pamiętajmy jednak, że owe statystyki dostarczają szczegółowych informacji na temat danej witryny nie tylko nam. Jeśli próbujemy w jakikolwiek sposób manipulować nieuczciwie pozycją strony w wyszukiwarce google, owe statystyki, przeglądarka chrom, czy google toolbar są mocno nie zalecane. 🙂 Ale My przecież jesteśmy uczciwi, więc korzystamy 😉 .
  • Zanim przerobimy css na mały kotlet, możemy także je nieco przerobić, by zmniejszyć ilość użytych znaków np poprzez wykorzystanie dziedziczenia. Dla wielu obiektów część parametrów może być identyczna, więc warto je wydzielić do osobnej klasy, aby nie powielać tego samego kodu wielokrotnie. Naturalnie wywalamy także całkowicie zbędny, niepotrzebny i nic nie robiący kod.

Jak mi się coś przypomni, to dopiszę. Część punktów postaram się także rozwinąć w kolejnych artykułach. Ten zaś miał za zadanie wskazać tylko metody.