Często otrzymuję zapytania dotyczące przyspieszania stron internetowych, bo otwarcie komunikuję, że wykonuję tego typu działania. Przy 95% przypadkach widzę, że przed skontaktowaniem się ze mną, właściciel strony próbował niemal wszystkich możliwych technik, które mógł zastosować samodzielnie bez wiedzy programistycznej / administracyjnej lub zlecił prace optymalizacyjne komuś kto… też jej nie ma.
Wiele moich artykułów można by streścić do jednego zdania: Nie ma nic gorszego niż powolna strona internetowa. Prawda jest taka, że jest coś gorszego – to błędna optymalizacja, która nie dość, że daje iluzję poprawy i maskuje prawdziwe błędy tak naprawdę pogarsza SEO i zabija resztki potencjału jakim strona lub sklep jeszcze dysponuje.
W tej liście wypunktuję rażące błędy, które popełniono tylko dlatego, że ktoś chciał przyspieszyć stronę internetową. Mam bardzo ułatwione zadanie, ponieważ wiele z tych technik, które miałem okazję już zaobserwować na prawdziwych stronach, mogę sobie przypomnieć czytając artykuły na temat przyspieszania stron na innych blogach.
Szaleństwem jest robić wciąż to samo i oczekiwać różnych rezultatów.
Albert Einstein
1. Wklejenie całego kodu CSS metodą inline do kodu strony
Jednym z najbardziej rażących błędów optymalizacyjnych jest wklejenie całego kodu CSS do nagłówka strony. Można tak zrobić w przypadku kodu krytycznego, czyli kilku kilobajtów, które odpowiadają za najważniejsze elementy w obszarze above the fold.
Tymczasem, wiele razy spotkałem się z sytuacją kiedy mnóstwo plików CSS zostało scalonych i dodanych w nagłówku strony w tagach <style> tylko dlatego, że wynik PageSpeed Insights był lepszy o 3 punkty. To powoduje, że przeglądarka nie może skorzystać z najprostszego mechanizmu przyspieszającego stronę – mowa o Cache przeglądarki – i strona choć może uzyskiwać kilka punktów więcej w PageSpeed Insights dla konkretnej podstrony, tak naprawdę działała wolniej w badaniach CrUX, bo z każdym wyświetleniem strony przeglądarka wczytuje CSS na nowo, bez funkcjonującego Cache.
Jak rozwiązać problem?
Jeżeli już usilnie chcesz wyeliminować zasoby blokujące renderowanie sprawdź jak to zrobić w poprawny sposób w artykule: optymalizacja krytycznej ścieżki renderowania.
2. ShortPixel i CDN na zewnętrznej domenie
ShortPixel to usługa do przechowywania i optymalizacji zdjęć, która serwuje treści z wykorzystaniem CDN. Wiele osób wykorzystuje usługę do tych dwóch zadań czyli optymalizacji i wykorzystania sieci CDN. Włączenie tego mechanizmu jest bardzo łatwe i ogranicza się do pobrania i aktywowania wtyczki oczywiście po uprzedniej płatności za możliwość jej wykorzystywania.
Na czym polega problem?
Problem polega na tym, że aby cały ten mechanizm działał, ShortPixel (bez odpowiedniej konfiguracji) przepisuje wszystkie adresy URL obrazków jakie są na stronie. Można to łatwo sprawdzić poprzez sprawdzenie kodu HTML lub za pomocą funkcji zbadaj element:
Aktywując tę wtyczkę, wszystkie zdjęcia zaczynają mieć taki adres:
<img class="img-fluid" src="https://cdn.shortpixel.ai/client/q_glossy,ret_img/https://mansfeld.pl/wp-content/uploads/2020/11/obrazek_optimized.png" alt="Obrazek">
Adres zdjęcia przekierowuje na oryginalny plik no ale nie muszę tłumaczyć jak katastrofalne w skutkach może być to posuniecie, kiedy zdjęcia są istotnym elementem budującym autorytet naszej domeny. Przeniesienie treści na domenę shortpixel.ai powoduje, że z perspektywy kodu HTML nasza domena jest „okradziona” z załączników i od tej pory, za każdym razem kiedy chcemy pokazać grafikę linkujemy do zewnętrznej domeny.
Jak rozwiązać ten problem?
Zintegrować własny CDN z ShortPixelem: https://help.shortpixel.com/article/180-can-i-use-a-different-cdn-with-shortpixel-adaptive-images
Lub poprawnie wdrożyć Google CDN lub Amazon Cloudfront z wykorzystaniem własnej domeny. Opisywałem to w poradnikach:
3. Opóźnienie całego kodu CSS
Eliminacja zasobów blokujących renderowanie spędza sen z powiek deweloperom, którzy chcą uzyskać pełny wynik w badaniach związanych z wydajnością.
Niestety opóźnienie wszystkich stylów CSS powoduje drastyczny wzrost parametru CLS, który jest składową Podstawowych Wskaźników Internetowych. Choć strona uzyskuje lepszy wynik w testach, przechodzenie na kolejne podstrony jest mało komfortowe. Strona „skacze” i wszystkie elementy na oczach użytkownika dopiero po jakimś czasie przyjmują właściwą pozycję i rozmiary. Z dwojga złego wolałbym chyba mieć lekko wolniejszą ale naturalnie wyglądającą stronę.
Jak rozwiązać problem?
Sprawdź jak wydzielić krytyczny CSS i opóźnić ładowanie niekrytycznego kodu CSS w artykule o optymalizacji kodu CSS.
4. DNS prefetch wszystkich możliwych adresów
DNS prefetch został wymyślony po to, aby wstępnie odpytać o adresy serwerów dla zasobów umieszczonych na stronie. W optymalizacji strony kluczową umiejętnością jest sterowanie kolejnością ładowania kolejnych elementów. Jeżeli przed załadowaniem górnej treści strony umieścimy balast DNS prefetch dla zasobów, które wykorzystujemy dopiero na następnych podstronach lub w dolnych sekcjach, cała idea DNS prefetch przestaje mieć jakikolwiek sens.
5. Asynchroniczne ładowanie kluczowych treści
Niektórzy deweloperzy znaleźli „świetny” sposób na oszukiwanie narzędzi badających prędkość ładowania stron, który jest jedną z największych bolączek technicznego SEO, mowa o asynchronicznie ładowanych treściach.
Asynchronicznie ładowana treść to świetna technika optymalizacyjna dla ładowania dodatków np. Chatu, załączników wideo, widgetów, komentarzy a nawet zdjęć. Kiedy jednak wykorzystujemy ją dla kluczowej treści, ta nie może być z łatwością indeksowana przez roboty wyszukiwarki. To, co ładuje się z opóźnieniem przestaje być widoczne dla Google i nie ma najmniejszych szans aby strona się poprawnie pozycjonowała.
6. Zmiana hostingu
Zmiana hostingu na bardziej wydajny lub na taki, który udostępnia dużo większe możliwości konfiguracyjne to bardzo sprytny sposób na poprawę wydajności strony. Czasem to sam hosting jest przyczyną opóźnionych odpowiedzi – można to łatwo zbadać. 100ms to dużo w kontekście ładowania stron a czasem sama infrastruktura przyczynia się do takiego opóźnienia.
Jeżeli jednak przy wyborze nowego dostawcy kierujesz się bezpłatnym miesiącem, słowem „speed” w nazwie pakietu, zniżką z programu afiliacyjnego lub opiniami to pewnie utkniesz na słabszym lub równie słabym hostingu, który prawdopodobnie nie jest w pełni kompatybilny z twoim CMSem. Ów brak kompatybilności objawia się wysokim czasem TTFB, zmiennymi środowiskowymi lub „coś” powoduje opóźnienia przy komunikacji z systemami zewnętrznymi.
Utrzymuj stronę na serwerach Apache lub nginx – dokładnie tak jak to robi większość właścicieli stron na całym świecie zgodnie z zaleceniami w dokumentacji popularnych systemów CMS. Jest to jedyna rzecz, na którą trzeba zwracać uwagę jeżeli zależy nam na szybkiej stronie internetowej.
7. Usunięcie lub pogarszanie jakości treści (zdjęć, filmów)
W przypadku błędów wydajnościowych związanych z zasobami statycznymi, czas ładowania staje się wprost proporcjonalny do ilości treści i ilości funkcjonalności jaka dana strona zapewnia.
Usuwanie zdjęć, filmów, skryptów lub konkretnych funkcjonalności, faktycznie może poprawić czas ładowania ale jest okupione sporym kosztem. To samo dotyczy radykalnego kompresowania lub zmniejszania ich wielkości / jakości. Strona, która składa się z samych bloków tekstu a zdjęcia są pikselowate prawdopodobnie wygląda mniej atrakcyjnie i dostarcza uboższych doświadczeń. Maleje szansa, że strona spełni zakładany przez nas cel.
Obecnie mamy do wykorzystania takie techniki optymalizacyjne, że nie trzeba poświęcać wizualnej jakości zdjęć i nie trzeba rezygnować z filmów. Atrybut srcset, pozwoli serwować kilka rozmiarów dla różnych urządzeń a poprawnie wdrożony natywny lazy load zdjęć, wideo i elementów iframe rozwiązuje problemy z wydajnością w większości przypadków.
Przy optymalizacji zdjęć za pomocą wtyczek, system CMS regeneruje całą bibliotekę, a to zapycha przestrzeń na dysku. Usunięcie starych rozmiarów zdjęć, które są gdzieś podlinkowane ręcznie powoduje błędy 404 tak jak w przypadku usuwania stron, w wyniku czego domena traci zdobyty autorytet. Powielanie różnych rozmiarów utrudnia serwis strony (np. przenoszenie, redesign, optymalziacje) i niepotrzebnie zwiększa koszt hostingu.
8. Cloudflare
Najciekawszy punkt zostawiłem na koniec. Cloudflare udostępnia usługę Reverse Proxy, która może realizować dla nas:
- funkcjonalność CDN,
- zabezpieczać naszą witrynę przed atakami DDoS,
- utrzymywać ciągłość działania witryny w trybie tylko do odczytu w przypadku awarii,
- zachować anonimowość serwera,
- w pewnych przypadkach przyspieszyć naszą witrynę.
Najpopularniejsza technika wdrażania CloudFlare polegająca na edycji adresów DNS jest łatwa do przeprowadzenia ale wiąże się z pewnymi problemami.
Po pierwsze ukrywana jest lokalizacja serwera. Jeżeli zależało nam na lokalizacji adresu IP w konkretnym kraju wdrażając Cloudflare rezygnujemy z korzyści jaką daje nam lokalizacja serwera pod kątem SEO. Po drugie, zabezpieczenia w tej technologii często mylnie zalicza naturalnych użytkowników jako „intruzów”, co powoduje, że dla części internautów strona może być niedostępna.
Sam nie raz miałem przypadek, gdzie Cloudflare zaliczył mnie do bota i mówiąc delikatnie podziękował mi za wizytę.
Po trzecie, należy zrozumieć, że Cloudflare to kolejny węzeł w komunikacji a to paradoksalnie wydłuża czas ładowania. Jest to spotęgowane na stronach dynamicznych np. sklepach internetowych. Zwykły Cache bazujący na lokalnym systemie plików może działać dużo szybciej. Cloudflare uniemożliwia też wykorzystać prostą technikę optymalizacyjną związaną z przepisywaniem adresów zdjęć po stronie serwera (z jpg/png na webp). Ten kod w .htaccess nie będzie działać jeżeli korzystasz z Cloudflare:
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule \.(jpe?g|png)$ %{REQUEST_FILENAME}.webp [L]Działania deweloperskie też są utrudnione, ponieważ ciągle widzimy zapisaną kopię strony. Cloudflare często jest wykorzystywany w przestępczości do maskowania prawdziwego adresu IP serwera i jego lokalizacji co nie wpływa pozytywnie na autorytet przydzielonego nam losowo adresu IP. Nie można też w żaden sposób wykorzystać własnego, dedykowanego IP.
Dla jakich stron powstał CloudFlare?
Głównie dla takich, gdzie bezpieczeństwo i zapewnienie działania jest dużo ważniejsze od niuansów SEO i wydajności. CloudFlare to narzędzie stworzone z myślą o większych portalach informacyjnych, gdzie nie ma możliwości wykorzystania zwykłego mechanizmu Cache bazującego na systemie plików.
Jeżeli chcemy korzystać z Cloudflare na malutkiej stronie trzeba zgłębić zawansowane sposoby na integrację Cloudflare z nasza stroną aby sytuacja nie była typowym przejściem z deszczu pod rynnę. Najlepiej jest wykorzystać popularne zasobniki treści z CDN oferowane w Google Cloud lub Amazon AWS.
9. Zmiana wersji PHP
Zmiana wersji PHP na nowszą to korzystne działanie jednak nie zawsze jest to możliwe. Pakowanie się w tonę problemów tylko dlatego, że chcemy odrobinę przyspieszyć działanie strony jest mało racjonalne z punktu widzenia optymalizacji. Jeżeli korzystasz ze starej wersji PHP pomyśl o stworzeniu nowej wersji strony lub sklepu. Dostosowanie twojej obecnej strony do najnowszej wersji PHP może kosztowo przewyższać stworzenie całkowicie nowej i profesjonalnej witryny. Po zmianie wersji problemy mogą być ukryte lub może nie funkcjonować mały szczegół. Niektóre problemy są ukryte by za jakiś czas zaatakowały ze zdwojoną siłą.
Aktualizacja wersji PHP nie przyspieszy znacząco strony, która korzysta z Cache. Większa wydajność interpretera szybciej będzie generować stronę tylko przy wyłączonym Cache, bardziej komfortowe może być zarządzanie stroną (ponieważ szybciej będzie działał panel).
10. Wdrażanie AMP tylko do celów przyspieszenia
AMP to ciekawy projekt. Prowadzenie strony wymaga poznania całego frameworka i ekosystemu stron AMP. Niestety, jak na razie nadaje się do stron/portali typowo informacyjnych, których modelem zarabiania są reklamy. AMP ma po prostu zbyt wiele wad aby można było z niego korzystać tylko dla rozwiązania problemów z szybkością. Czytaj więcej: strony AMP – zalety i wady.
Testowałem AMP przez długi okres na stronie, którą właśnie odwiedzasz. Surowy wygląd i brak możliwości zastosowania niestandardowych skryptów JS znacznie utrudniał prowadzenie strony a wszelkie aktualizacje pojawiały się ze sporym opóźnieniem. Brak możliwości integracji z zewnętrznymi usługami i masa ograniczeń dyskwalifikuje AMP do wykorzystywania na stronie firmowej lub w sklepie internetowym, która w swoim założeniu ma ściągać klientów i zarabiać. Dobrym rozwiązaniem może być stworzenie strony od zera zgodnej z AMP tym bardziej jeżeli technologia ta będzie się rozwijać.
Włączanie wersji AMP za pomocą wtyczki uważam za totalne nieporozumienie. Psuje spójność identyfikacji marki i utrudnia dostosować wygląd strony do własnych potrzeb. Moja obecna strona jest szybsza bez włączonego AMP.
Podsumowanie
Artykuł napisałem dla przestrogi. Niefortunna kreatywność specjalistów od przyspieszania stron i wtyczki do optymalizacji to największe przeszkody w zachowaniu dobrej kondycji naszej strony. Stosowanie wtyczek optymalizujących z losową kombinacją ustawień, ukrywa błędy, utrudnia audyt i zwiększa koszt działań polegających na prawdziwej optymalizacji.
Kiedy coś nam dolega lub mamy problemy w dziedzinie, w której nie jesteśmy specjalistami szukamy zazwyczaj specjalisty. W przypadku choroby idziemy do lekarza, regulamin i umowy pisze prawnik a instalację elektryczną naprawia elektryk. Nawet stary samochód oddajemy do mechanika nie mówiąc o pralce czy zmywarce. Dlaczego zatem nie zastosować tego sprawdzonego schematu działania w kontekście sklepów i stron internetowych?
Nadia pisze: 
August 
Oskar 
Odpowiedz lub skomentuj