Serwer – o czym pamiętać, by pomóc, a nie przeszkodzić w działaniach SEO
Szybkość to podstawa
autor: Marek Czerwiński
rozmawiał: Jakub Mazurkiewicz
Co jest najważniejsze przy wyborze serwera, jeśli myśli się o tym, żeby strona była dobrze widoczna z poziomu wyszukiwarek?
Wybór serwera nie ma absolutnie żadnego znaczenia, jeśli chodzi o wyszukiwarkę i crawlery. To, w jaki sposób się serwer przedstawia, nie ma wpływu na pozycjonowanie. Można wybrać serwer Apache, można wybrać serwer NGINX czy też wysyłać dane bezpośrednio z serwera aplikacyjnego typu Tomcat lub za pomocą PHP. Dla wyszukiwarki bardzo duże znaczenie ma szybkość renderowania.
Zatem myśląc o serwerze w kontekście SEO, należy skupiać się przede wszystkim na szybkości?
Tak.
A na co powinniśmy zwracać szczególnie uwagę w kontekście hostowania aplikacji?
Jest takie przekonanie, że NGINX jest lepszym wyborem dla SEO, ponieważ ma inaczej skonstruowaną architekturę. Głównie dlatego, że był on zaprojektowany, żeby zapewniać dobrą wydajność, szybkość. Z kolei serwer Apache został stworzony z myślą o udostępnianiu jak największej liczby funkcjonalności, co nie zawsze jest równoznaczne z szybkością. Stąd przekonanie, iż NGINX jest szybszy, choć da się też tak skonfigurować Apache’a czy Apache’a 2, żeby szybko serwował strony, tylko tu potrzeba dużo więcej wiedzy i umiejętności. Jednak NGINX jest defaultowo naprawdę bardzo szybki.
Czyli mówiąc o rozróżnieniu pomiędzy Apache i NGINX, to trochę się odnosi do tego, żeby unikać serwerów z dużą liczbą modułów?
Zgadza się. Im więcej modułów, tym procesy na serwerze są bardziej rozbudowane, a przy każdym requeście więcej ten serwer musi robić. To też nie jest normą, ale najczęściej tak jest. Im coś jest większe, to wiadomo – tym jest wolniejsze. Są również inne serwery WWW, typu lighttpd. Zanim powstał NGINX, to on dzierżył palmę pierwszeństwa w zakresie szybkości, ale później NGINX sporo namieszał w tych statystykach. Deweloperzy, którzy lighttpd stworzyli, mieli przede wszystkim na celu szybkość serwowania strony.
A jak sprawdza się hosting SSD?
Wszystkie strony statyczne WWW albo dynamiczne, czyli np. programy napisane w PHP czy w jakimkolwiek innym języku, są składowane na dysku. Serwer WWW, serwując strony, musi je z dysku odczytać. Dysk SSD nie jest dyskiem magnetycznym, tylko działa jak pamięć i ma o wiele większy czas dostępu. To wpływa bardzo mocno na szybkość. Natomiast trzeba brać pod uwagę to, że serwery WWW są aktualnie tak pisane, że najczęściej serwowane strony, jeżeli nie zmieniają się czasy modyfikacji, są trzymane w pamięci. Często sam system operacyjny trzyma te pliki w pamięci, w cache’u. Zatem wybierając jakikolwiek hosting, najlepiej zrobić testy wydajności i sprawdzić, jak szybko są serwowane strony, porównując hostingi na różnych dyskach. Ale co do zasady serwer będzie czytał szybciej z dysku SSD. To jest ta sama technologia, w jakiej są robione zwykłe pamięci operacyjne, czyli nie ma tam magnetycznego dysku, z którego trzeba odczytać całość i czas dostępu jest wówczas po prostu większy.
Czy lokalizacja serwera ma wpływ na szybkość wczytywania strony?
Dla użytkownika końcowego jak najbardziej. Jeżeli strona jest serwowana dla Polski, to oczywiście warto trzymać ją w serwerowni w Polsce, bo w tym momencie dla użytkowników w Polsce ta szybkość będzie większa. Dla samej wyszukiwarki jednak nie za bardzo ma to znaczenie, ponieważ Google tak naprawdę w każdym kraju ma jakąś serwerownię, z której wypuszcza crawlery i opiera się na geolokalizacji danego serwisu – crawluje go z najbliższej dla danej strony serwerowni.
Dużo wspomina się o CDN jako rozwiązaniu, które może pomóc w działaniach zwiększających szybkość serwowania strony. Czy mógłbyś powiedzieć, czym jest CDN i jak działa?
CDN ma dwa zadania – pierwsze zadanie to cache pozwalający przyśpieszyć ładowanie pewnych stron. Przypuśćmy, że serwis nie ma dysku SSD, tylko dysk magnetyczny typu SATA i ładowanie jest długie. CDN zadziała jako proxy i po pierwszym requeście cache’uje treści statyczne – dynamiczne zresztą też można w nim zdefiniować, ale głównie jest przeznaczony dla zasobów statycznych. Wówczas o wiele szybciej obsługuje ponowne zapytania, ponieważ sam korzysta z dysku SSD. Drugim zadaniem CDN-a jest zabezpieczenie anty-DDoS–owe, czyli pozwalające ochronić aplikację przed atakami. CDN ma serwerownie, podobnie jak Google, na całym świecie i może rozdzielać ruch, którego jeden serwer mógłby nie wytrzymać.
Najczęściej mówi się w przypadku CDN-ów o dwóch rozwiązaniach. Jedno to Cloudflare, a drugie to CloudFront. Jaka jest różnica pomiędzy nimi?
CloudFront to jest usługa AWS–owa (Amazon Web Services). Jeżeli korzysta się z AWS-a do hostowania, to lepiej wybrać CloudFront, ponieważ wszytko wówczas jest u jednego dostawcy – jeden rachunek, jedna faktura, w tej samej serwerowni. Jeśli jednak nie mamy usługi w AWS-ie, to warto skorzystać w Cloudflare’a, który istnieje na rynku dłużej, jest bardziej popularny, a zespół za niego odpowiedzialny ma dużą wiedzę w zakresie CDN. Oba rozwiązania jednak są dokładnie takie same i czy wybierze się jedno, czy drugie, to nie ma znaczenia.
Jakie znaczenie ma wybór języka programowania?
Każdy program jest wolniejszy od statycznego contentu, który po prostu serwer WWW musi odczytać z dysku i wysłać do internetu. Każdy program musi jakieś operacje wykonać, jakiś czas procesora zabrać, jakieś obliczenia zrobić. Natomiast to, za pomocą jakiego języka jest to robione czy też za pomocą której aplikacji, dla przeglądarki nie ma znaczenia, bo ona nie wie, z czego korzystamy, czy ma do czynienia ze statycznym, czy dynamicznym contentem. Dlatego wybór technologii to jest indywidualna kwestia, najlepiej wybrać taką, w której się najlepiej czujemy, najszybciej i najbezpieczniej napiszemy wydajny kod.
Lazy loading jest pomocny w skróceniu oczekiwania użytkownika na serwowaną treść?
Lazy loading to sposób komunikacji. To tzw. opóźnione ładowanie, przeglądarka wysyła request, a my wstrzymujemy odpowiedź do czasu, aż pojawi się dana treść. Zatem jest to sposób obsługi aplikacji, żeby spełniała daną funkcjonalność. Występują też inne, zbliżone formy wymiany informacji, na przykład web sockety, które pozwalają na lepszą komunikację pomiędzy przeglądarką a serwerem, bo w tym momencie ona jest dwukierunkowa, co wpływa na większą interaktywność. Niestety, roboty przeglądarkowe często nie potrafią poprawnie odczytywać contentu przesyłanego za pomocą lazy loadingu czy web socketów – one potrzebują informację: zadanie – odpowiedź i to, co ta odpowiedź ze sobą niesie.
Pokaż mi swój numer IP, a powiem ci, kim jesteś
A kwestia IP i unikalności tego IP ma znaczenie?
Raczej nie. Jeżeli mielibyśmy aplikację lub stronę serwowaną z kilku serwerów, to może się zdarzyć tak, że serwujesz go z kilku numerów IP. Jest to rozwiązanie Round-robin DNS, czyli dla jednego adresu DNS–owego masz przypisane dwa numery IP, dzięki czemu serwujesz stronę z dwóch serwerów. I to jest najprostszy sposób na load balancing. To jednak nie wpływa w żaden sposób od strony technicznej na wyszukiwarki, na indeksowanie i – co za tym idzie – na pozycje.
Problem jednak pojawia się w przypadku IP, kiedy to jest kwestia reputacji. To znaczy, jeżeli na przykład dany serwer serwuje wiele stron i jest jedno IP, a strony na nim umieszczone są wątpliwej jakości…
Czyli hosting współdzielony.
Dokładnie.
Wówczas istotne jest to, czy np. właściciele jednej z takich stron nie praktykują Black Hat SEO. Google potrafi po IP blokować wszystkie strony, które się znajdują na danym adresie.
Hosting współdzielony będzie dotyczyć niewielkich aplikacji. Co jeszcze jest istotne przy dużych projektach? Czy aspekt SLA, dostępności, bezawaryjności powinien być brany pod uwagę?
Jak najbardziej. Zdarzało się, że jeżeli dany serwis nie działał i nie był dostępy dla crawlerów, jeśli nie odpowiadał na requesty, to tracił reputację. Dlatego Cloudflare jest dobrym rozwiązaniem, bo pozwala przez pewien czas serwować stronę statyczną, nawet kiedy dany serwer przestał odpowiadać. W każdym razie dobrze, by serwis miał jak najlepsze SLA i nie znikał z internetu.
Nie tylko cash ma znaczenie. Cache też
Jaką rolę odgrywa w SEO cache’owanie i jakie rozwiązania być polecał? Varnish i Redis to są technologie, które mają tutaj coś do powiedzenia?
Varnish to jest ekwiwalent Cloudflare’a, czyli posiada analogiczną funkcjonalność techniczną jak CDN, tylko jest to robione na lokalnym serwerze. Wówczas serwis działa jako proxy, przy pierwszym requeście odpowiedzi są zapisywane w pamięci operacyjnej i potem każdy następny request zwracany jest z pamięci, czyli po prostu dzięki cache’owaniu wynik jest szybciej serwowany. Najczęściej dotyczy to obrazków i statycznych plików.
Jest to rodzaj technologii, którą się instaluje na serwerze?
Tak, jako osobną usługę, odpowiednio konfiguruje się samego Varnisha i serwer WWW, co powoduje, że ruch przechodzi przez Varnisha i jest cache’owany. Kolejne requesty serwera WWW nie dochodzą już do serwera WWW, tylko Varnish je zwraca, co powoduje, że korzystanie ze strony staje się szybsze. Natomiast Redis wspiera wydajność na poziomie oprogramowania. Pozwala cache’ować w pamięci bardziej obciążające i długotrwałe operacje, wykonywane już przez sam program.
Można powiedzieć, że Varnish jest przeźroczysty dla danej aplikacji, konfiguruje się go obok serwera WWW. Komunikacja między aplikacją a tym narzędziem odbywa się tylko na zasadzie inwalidacji cache’a, czyli wtedy, gdy chcemy zaktualizować pliki trzymane w pamięci. Z kolei w przypadku Redisa komunikacja ma miejsce na poziomie programów napisanych w danym języku. I ona jest napisana explicite przez programistę.
W przypadku Redisa to jest coś, co nazywa się cache’owaniem obiektowym?
Obiektowym cache’em jest Amazon S3. Natomiast by uzyskać ekwiwalent S3, który można samemu zainstalować i uzyskać funkcjonalność object storage, potrzebujemy kilku serwerów. Takie zadanie spełnia na przykład OpenShift, znajdujący się w ofercie Red Hat, a drugi to Swift z OpenStacka.
Często w dyskusjach, zwłaszcza przy rozwiązaniach typu WordPress, jest mowa o memcached…
Memcached to coś pomiędzy Varnishem a Redisem, usługa postawiona obok serwera WWW, ktory cache’uje w pamięci, ale pozwala również korzystać z niej od strony programistycznej, czyli na przykład z poziomu samego PHP cache’ować dane.
Rozumiem, że nie ma świętej zasady dotyczącej cache’owania. Wszystko zależy od serwisu?
Tak, zgadza się. Możesz cache’ować na poziomie proxy, używając Varnisha, możesz cache’ować jakieś elementy, które program oblicza, możesz cache’ować zapytania do bazy danych. Decyzja zapada na etapie profilowania działania danej strony. Programista musi określić, co najlepiej cache’ować, weryfikując wąskie gardła.
SSL, protokoły, nagłówki
Znaczenie dla reputacji strony mają także certyfikaty SSL, czy tutaj miałbyś jakieś sugestie? Jaki to powinien być certyfikat i jak powinien być zainstalowany?
Najistotniejsze jest samo posiadanie ważnego certyfikatu. Certyfikat powinien być podpisany przez zaufane centrum autoryzacyjne, a to oznacza, że należy korzystać z dostawców typu Certum, Thawte, Namecheap, Let’s Encrypt. Trzeba pamiętać, by cały ruch niezaszyfrowany był przekierowywany automatycznie na ruch szyfrowany.
A jak jest z protokołami?
Warto mieć włączoną obsługę najnowszych wersji protokołu, typu HTTP 2 lub HTTP 3, bo wpływa to na reputację danej strony.
Oczywiście sama przeglądarka musi też ten protokół obsługiwać. W nagłówkach requestu jest tak zwana negocjacja protokołu komunikacyjnego. Jeżeli zgodzą się na to i przeglądarka, i serwer, to wówczas jest możliwa komunikacja za pomocą nowszej wersji protokołu.
Jak już jesteśmy przy nagłówkach – jak to z nimi jest, jak powinny być ustawione, żeby wspierały proces indeksacji?
To jest mniej więcej tak, jak z syntaktyką HTML-a i treściami na HTML. Zawsze były jakieś sztuczki, które pozwalały na zwiększenie pozycji. Natomiast Google działa przeciwko takim zabiegom i stoi na stanowisku, że najlepiej, by HTML był ustawiony dobrze syntaktycznie, klarownie, czysto napisany. Dlatego preferowane jest podejście zdroworozsądkowe. Analogicznie z nagłówkami – zatem jeżeli na przykład zmieniamy stronę główną, dodajemy nowy artykuł i pojawia się jego zajawka, to warto w tym momencie zmienić nagłówek last modified. Jeżeli nic nie zmienimy przez jeden dzień, to wówczas nagłówek last modified powinien informować o dacie ostatniej zmiany. Z nagłówkiem expires, który informuje, jak długo użytkownicy mogą cache’ować lokalnie daną stronę, jest dokładnie tak samo. My decydujemy o tym, jak powinien być ustawiony i roboty raczej powinny te informacje respektować, ale należy to robić z głową. Tak samo z robots.txt, ustawiamy to, co chcemy, by bot indeksował i to, czego nie chcemy. Jeśli jednak zaczyna się kombinować, to z reguły kończy się to źle, czyli na przykład karą.
A ustawianie nagłówka expires na datę wsteczną to dobra praktyka?
Ujemny expires, tzw. -1 wg RFC (Request for Comments) można czasem ustawiać, to informacja, że dana treść traci ważność natychmiastowo. Wówczas roboty będą częściej chodziły po stronie. Najlepiej opierać się na ustawianiu wszystkich nagłówków zgodnie z zaleceniami RFC, czyli standardami wytyczonymi przez akademików z początków internetu.
Migracje
Jaki jest wzorcowy proces, kiedy myśli się o przenosinach z jednego serwera na drugi albo od jednego dostawcy hostingu do drugiego? Co robić i w jakiej kolejności, żeby zminimalizować ryzyka?
Należy zadbać, żeby content był cały czas dostępny. Chodzi o to, żeby nie było przerwy w działaniu danego serwisu. I to najlepiej wykonać w ten sposób: trzymamy strony w starej serwerowni, a w nowej serwerowni konfigurujemy serwery, przenosimy content, przenosimy aplikacje, finalnie uruchamiamy całość. W tym momencie serwis działa równolegle, przy czym albo przełączamy domenę ze starego na nowy, albo możemy jeszcze wspomóc się serwerem proxy, który spowoduje, że mamy kontrolę nad tym, na który serwer dostaną się użytkownicy. Nie wiemy bowiem, czy dany użytkownik ma scache’owaną jeszcze odpowiedź na DNS-a i nie wiemy, na który serwer wejdzie. Stąd skonfigurowanie proxy pozwoli precyzyjniej kierować ruchem użytkowników, a co za tym idzie – również crawlerów. Dzięki temu jesteśmy w stanie przełączyć ruch w miarę płynnie. Przy czym zawsze trzeba pamiętać, że proxy powoduje, że troszeczkę opóźniają się requesty (request idzie od użytkownika do nowego serwera, z nowego serwera na stary serwer, ze starego serwera z powrotem na nowy i potem do użytkownika), dlatego najlepiej zrobić całą operację w nocy lub w weekend i wykonać ją szybko.
I po delegacji domeny po prostu ten proxy się wyłącza?
Tak, proxy się włącza tylko na czas zmiany domeny, żeby skierowała ruch na nowy serwer. Zazwyczaj jest to jeden dzień. TTL-ki (Time to Live) domenowe są najczęściej ustawione na 3600 sekund, czyli na godzinę, ale nie wiadomo, jak systemy operacyjne cache’ują domenę, dlatego bezpieczniej jest poczekać jeden dzień i wtedy można uznać, że zmiana DNS-ów została wykonana.
Czy ma się wpływ na TTL?
Tak, można tę opcję zmniejszyć nawet do jednej sekundy. AWS używa takiej usługi jak load balancer, który również korzysta z DNS-ów i one są standardowo ustawione na jedną sekundę, żeby nowe serwery, pojawiające się automatycznie, już po jednej sekundzie były wskazywane przez daną domenę. Ale może się zdarzyć, że dany system operacyjny z jakiegoś powodu nie obsłuży tej zmiany, na co nie mamy wpływu. Natomiast co do zasady – jak najbardziej dobrym rozwiązaniem jest, by tak zwaną TTL-kę danej domeny zmniejszyć na jak najmniejszy czas.
Ale najlepiej stosować obie te metody, czyli zastosować proxy i obniżyć TTL?
Najlepiej to migrację zrobić w bezpieczny sposób, czyli niech stary serwis sobie działa jeden, dwa czy kilka dni, i obserwować, czy jakiś ruch jeszcze w logach serwera się nie pojawia. Jeżeli tak, to trzeba się zastanowić, dlaczego, skoro zmiany zostały wykonane w DNS–ach i w TTL. Chodzi o to, by nie stracić żadnego ruchu, bo a nuż, widelec to może być jakiś crawler.
