PŚ #2: Zmiana ustawień serwera www

P

Artykuł jest częścią projektu Prędkość Światła, o którym więcej możecie dowiedzieć się tutaj.

Wybór hostingu pod stronę internetową zazwyczaj kończy się na cenie. Im taniej tym lepiej. Nie zawsze jest jednak lepiej. Nadmierny overselling, ataki DDoS na klienta znajdującego się na tym samym serwerze matce czy też jazda na domyślnej konfiguracji serwera marnuje potencjał, który możemy wykręcić od hostingodawcy. O tym jak wybierać firmę z głową opowiem kiedy indziej. Dziś skupimy się na samej konfiguracji.

Za testowy serwis posłuży mi ta sama konfiguracja co poprzednio, wraz z zastosowanymi zmianami z poprzednich wpisów.

PHP 7.1

To, że PHP 7.1 jest szybszy, jest bezdyskusyjne. Każdy kto choć raz migrował serwis na najnowszą wersję PHP’a zgodzi się ze mną, że wydajność wyraźnie czuć. Na blogu ma.ttias.be, zostały przeprowadzone benchmarki, z których wynika, że WordPress na wersji PHP 7.1 jest o 200% szybszy niż, domyślnie włączonej na wielu hostingach 5.6.

ⓒ ma.ttias.be
ⓒ ma.ttias.be

Zatem i my to zróbmy, wejdźmy w panel hostingu i zmieńmy wersję PHP na 7.1… Jest jeden haczyk. Jeśli nasz szablon nie wspiera najnowszej wersji PHP’a, mamy trzy opcje: albo zgłosić się do autora o dostosowanie się do wersji 7.1, własnoręcznie naprawić wyskakujące warningi lub zlecić to freelancerowi. W przypadku wtyczek problemu nie będzie, najwięksi dostawcy wtyk zawsze są up-to-date, natomiast w przypadku niszowych – odpuść. Dziurawe, obciążające, nieaktualne. O tym, dlaczego less is more w przypadku wtyczek wkrótce. Samo przełączenie wersji PHP daje nam całkiem dużo. Screen z wynikiem z narzędzia speedcurve poniżej.

Dla użytkownika końcowego zyskujemy 20% wzrostu wydajności.

 

Kompresja gzip

O gzipie już kiedyś wspominałem na przykładzie Netflixa, który zaoszczędził 43% na łączu wychodzącym w świat. Gzip to nic innego, jak kompresja danych po stronie serwera przed wysłaniem ich do użytkownika. Lekki wzrost zużycia cpu by skompresować dane, w zamian za spore zmniejszenie ruchu na łączu, które kosztuje zdecydowanie więcej niż moc obliczeniowa.

Kompresję gzip także włączymy w panelu hostingu jednym wihajstrem. Efekty? Screen pokazuje różnicę między stanem z samym W3 Total Cache a PHP 7.1 + gzip + W3 Total Cache.

Wydajność po PHP 7.1 i gzip

Testowy blog na stronie głównej ma mało treści, niemniej gzip bardzo dobrze kompresuje nam HTML’a na wyjściu. 39% to przy większych serwisach dobre naście gigabajtów zaoszczędzonego transferu dziennie.

SSL

Szyfrowane połączenie wbrew pozorom warto mieć wszędzie, nie tylko na stronach bankowych czy tam, gdzie podajemy poufne dane. Forum, blog, galeria z kotkami, wszędzie. Let’s Encrypt stworzyło bardzo fajne narzędzie, które pokazuje, jak różni się tempo ładowania elementów strony na http i https.

Certyfikat SSL nie musi być drogi, wiele firm nabija swoich klientów na certyfikaty za tysiące złoty. Owszem, są one przydatne jeśli tworzymy serwis obsługujący dane kart płatniczych itd. W przypadku zwykłych blogów czy innych hobbystycznych stron, darmowy Let’s Encrypt w zupełności wystarcza.

 

Koniecznie dajcie znać, które z powyższych i wy używacie 😉

O autorze

Filip Nowacki

Swoją przygodę z IT rozpoczął mając 13 lat, kiedy to stworzył swoją pierwszą stronę internetową. Obecnie pracuje jako backend & mobile developer, rozwijając kilka ogólnopolskich produktów o zasięgu blisko 15 milionów użytkowników. Prywatnie maniak optymalizacji, testów A/B, motoryzacji i architektury aplikacji.

1 komentarz

  • Witam. Przydatny, techniczny blog ze sporą ilością konkretów – za to należy się pochwała. Co do kwestii SSL i certyfikatu Let’s Encrypt… w Polsce nie jest niestety tak różowo. Większość polskich firm hostingowych posiada panele Direct Admin, które w łatwy sposób umożliwiają wprowadzenie generowania certyfikatu Let’s Encrypt. Jednak tylko niewiele z nich tak zrobiło (np. Unix Storm). Od jakiegoś czasu nie mogę się tego doprosić w skądinąd bardzo dobrym hostingu na Future Host, o innych nie wspominając. Oczywiście możemy sami generować certyfikat Ler’s Encrypt, jednakże jest z tym sporo roboty i chyba nie tędy droga. Podejrzewam, że przyczyną jest wspomniana w artykule chęć zarobku na odsprzedaży komercyjnych certyfikatów. Wprowadzenie HTTP/2 wraz z SSL to naprawdę spory krok naprzód w kwestii wydajności i warto trzymać kciuki, żebyśmy wszyscy szli w tę stronę.