Dlaczego Twoja witryna WordPress jest tak powolna i poręczny przewodnik, jak przyspieszyć działanie

Chciałem rozpocząć ten post od poinformowania, że NIE jest to kolejny ogólny artykuł „Jak przyspieszyć działanie WordPressa”.

Nie będę zwracał niczego, co już można znaleźć w sieci. Nie powiem ci, że powinieneś zainstalować wtyczkę buforującą, włączyć kompresję, zminimalizować css/js itp….

W końcu powinieneś już wiedzieć, jak to zrobić. A jeśli nie, możesz znaleźć te ogólne informacje na setkach innych blogów.

Zamiast tego ten artykuł zawiera wszystko, co niestandardowe/pół-niestandardowe, które zaimplementowałem w ciągu ostatniego miesiąca, aby przyspieszyć mój własny blog WordPress i zasadniczo zapobiec nieuczciwemu dostępowi do awarii mojego serwera.

A powodem, dla którego jest to „mało znane”, jest to, że techniki, które opiszę, będą bardzo specyficzne dla Twojego bloga, w zależności od zaobserwowanych wzorców ruchu.

Uwaga: Jeśli masz powolnego bloga i naprawdę nie chcesz zajmować się żadnymi technicznymi aspektami przyspieszenia witryny, prawdopodobnie powinieneś zarejestrować się w usłudze takiej jak WP Engine .

Ci faceci specjalizują się w hostingu WordPress i zadbają o to, aby Twój blog działał tak szybko, jak to możliwe. Ale oczywiście ma to swoją cenę. Powinieneś je sprawdzić, jeśli ten post Ci przerasta :)

W każdym razie, zanim wyjaśnię Ci, jak i dlaczego zrobiłem to, co zrobiłem na moim blogu, musisz zrozumieć kilka podstawowych pojęć dotyczących WordPressa i pamięci podręcznej, które opiszę poniżej.

Kilka interesujących faktów dotyczących WordPressa

Załóżmy, że już zastosowałeś się do wszystkich wskazówek dotyczących przyspieszenia WordPressa. Twój blog jest pełen energii. Webpagetest.org informuje, że Twój blog jest szybki jak diabli. Wszystko w porządku, prawda? Niekoniecznie .

Kiedyś myślałem dokładnie tak samo o moim blogu. W końcu stosuję większość standardowych protokołów przyspieszania. Używam bardzo niewielu wtyczek, a mój blog wydaje się dość szybki w normalnym użytkowaniu z perspektywy czytelnika (sieci reklamowe spowalniają mój blog, więc ładuję reklamy na końcu).

Ale potem zacząłem analizować moje wykresy wykorzystania procesora i często zauważałem okresy dużego obciążenia serwera pomimo niskiego lub umiarkowanego poziomu ruchu. Zdarzało się, że mój serwer przez dłuższy czas stał się bezużyteczny lub nie odpowiadał.

Uwaga, jedynym powodem, dla którego zacząłem zwracać uwagę na te statystyki, było to, że jakiś czas temu prowadziłem sklep internetowy na tym samym serwerze, co mój blog. I od czasu do czasu klienci narzekają, że sklep działa bardzo wolno. Kiedy w końcu zacząłem kopać, odkryłem, że mój zoptymalizowany, w pełni buforowany blog WordPress rzuca mój serwer na kolana!

Morał historii? To, że test szybkości pokazuje, że Twój blog jest szybki, niekoniecznie oznacza, że ​​wszystko jest w porządku.

Oto kilka zabawnych faktów na temat WordPressa i wtyczek do buforowania, takich jak WP Super Cache i W3 Total Cache, o których powinieneś wiedzieć.

• Odpowiedzi WordPress 404 są powolne . Za każdym razem, gdy twój blog uzyskuje dostęp do strony, która nie istnieje, twój biedny serwer musi załadować WordPress, uruchomić kilka kodów php, wykonać kilka zapytań MySQL, a następnie wypluć niestandardową stronę WordPress 404. Jest to zadanie wymagające dużej ilości zasobów, a buforowanie nie pomoże.
• Twoja wtyczka buforująca nie działa zbyt dobrze, gdy w adresie URL znajdują się parametry GET. Na przykład zauważyłem, że mój blog zwalniał do indeksowania za każdym razem, gdy wysyłałem wiadomość na moją listę e-mailową. Teoretycznie z buforowaniem plików statycznych mój serwer powinien być prawie niezwyciężony.

  Ale ponieważ Aweber wstawia parametry śledzenia w adresie URL, żaden z moich plików nie jest superbuforowany. W rezultacie WordPress musi wygenerować zupełnie nowy plik pamięci podręcznej (nawet jeśli już istnieje), spakować go i wysłać za każdym razem. Najgorsze jest to, że te buforowane pliki są używane tylko raz, co powoduje marnowanie zasobów serwera

• Nieuczciwe dostępy są powolne. Ponieważ nieuczciwe dostępy wymagają domyślnie załadowania WordPressa, zły bot lub robot, który zdecyduje się na spamowanie Twojej witryny złymi żądaniami, może dość łatwo usunąć Twojego bloga.
• Twoja wtyczka pamięci podręcznej może mieć błąd lub niezgodność ze sposobem konfiguracji bloga . Na przykład przez 3 lata myślałem, że WP Super Cache postępuje słusznie, dopóki nie zacząłem oglądać moich logów i zauważyłem błąd w kodzie. Ze względu na sposób, w jaki wszystko skonfigurowałem, miałem problem, w którym WP Super Cache zbyt często opróżniał moją pamięć podręczną.

Kluczową kwestią, którą staram się poruszyć z powyższymi punktami, jest to, że za każdym razem , gdy na Twoim blogu ma miejsce niestandardowy dostęp, zużywa on wiele zasobów serwera, bez względu na to, jak masz konfigurację bloga WordPress. I to właśnie tego typu dostępy rzucą Twój serwer na kolana, a nie zwykły ruch.

Wykrywanie nieuczciwych dostępów

Pierwszym kluczem do optymalizacji bloga WordPress jest zrozumienie wzorców ruchu, które otrzymuje Twój blog. Założę się, że 99% użytkowników WordPressa tego nie robi. Zamiast tego ślepo śledzą i instalują różne wtyczki i zakładają, że wszystko działa poprawnie. Nie czuj się źle, byłem taki sam.

Więc pierwszym krokiem jest ustalenie, co się do cholery dzieje. Można to zrobić na wiele sposobów, ale najłatwiejszym sposobem jest użycie trybu debugowania zapewnianego przez wtyczkę WP SuperCache. Co robi ten tryb? Zasadniczo za każdym razem, gdy dostęp jest obsługiwany bezpośrednio przez WordPress (wymagający dużej ilości zasobów), pojawi się on w dzienniku WP Super Cache. Oto jak włączyć ten tryb.

W zakładce debugowania wtyczki WP Super Cache, po prostu kliknij pole wyboru „Włączone debugowanie” i gotowe!

Po włączeniu rejestrowania możesz kliknąć link „plik dziennika”, który wskaże Ci plik z informacjami o ruchu WordPress. Będzie wyglądać podobnie do poniższego tekstu.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

Należy zauważyć, że za każdym razem, gdy widzisz coś w tym dzienniku, jest to zła rzecz, ponieważ oznacza to, że WordPress musi działać. A ponieważ WordPress jest świnią zasobów, chcesz, aby wykonywał jak najmniej pracy.

Czego szukać w dziennikach

Dzienniki WP Super Cache są świetne, ponieważ informują o wszystkim, co się dzieje. Ale sama ilość informacji może być przytłaczająca, chyba że wiesz, czego szukać. Oto, na co powinieneś zwrócić uwagę w tych dziennikach.

• Błędy 404 – w zasadzie są to dostępy do stron, które nie istnieją w Twoim blogu. Każdy dostęp 404 obsługiwany przez WordPress zajmuje dużo zasobów serwera, więc jeśli to możliwe, chcesz je zdusić w zarodku
• Dostęp jednorazowy – są to żądania, które powodują, że serwer buforuje i kompresuje strony, które będą używane tylko raz (więcej na ten temat później)
• Dziwne wybuchy ruchu – zazwyczaj są to boty, które jednocześnie uderzają w Twojego bloga
• Dziwne zachowanie pamięci podręcznej – Czy twoje pamięci podręczne są opróżniane, kiedy powinny? Czy wszystko jest prawidłowo buforowane w każdych okolicznościach?

Po utrzymywaniu dziennika ruchu na moim blogu przez okres 2 tygodni odkryłem wiele nieefektywności, które opiszę poniżej.

Boty waliły w moje archiwa

Pierwszą rzeczą, jaką zrobiłem, było sprawdzenie dzienników mojego serwera pod kątem okresów dużego obciążenia procesora. Następnie przeanalizowałem moje dzienniki super pamięci podręcznej dokładnie w tych samych okresach, aby sprawdzić, czy dzieje się coś zabawnego. Okazuje się, że mniej więcej co drugi dzień przychodziła grupa botów i uderzała we wszystkie strony archiwum mojego bloga w tym samym czasie!

Ponieważ te strony archiwum nie są domyślnie buforowane, kilka równoczesnych dostępów wystarczyło, aby zwiększyć obciążenie mojego serwera i spowolnić działanie. A od czasu do czasu powodowało to nawet awarię mojego serwera.

Więc przyjrzałem się bliżej mojemu wynikowi HTML i zauważyłem, że mam kilka linków do archiwum jako część mojego nagłówka WordPress. Dlatego boty i inne roboty sieciowe przychodzą i próbują przeglądać archiwa.

Po długim przeglądaniu Google zauważyłem, że kilku innych webmasterów ma podobne problemy.

Gdy wielokrotnie widzimy problemy z ładowaniem Twojej witryny, pojawia się duża liczba trafień na adresy IP serwerów proxy, a teoria jest taka, że ​​te serwery proxy buforują Twoją witrynę i trafiają na wszystkie linki do archiwum. Wiele adresów IP, które widzimy, gdy Twoja witryna powoduje problemy z ładowaniem, to korporacyjne, edukacyjne i rządowe/wojskowe adresy proxy, które wydają się wstępnie pobierać treści, gdy ktoś uzyskuje dostęp do witryny.

Rozwiązanie: Sprawdź, czy masz instrukcję php „wp_get_archives” w kodzie nagłówka swojego bloga i usuń ją. Po usunięciu tego małego fragmentu wszystkie moje dostępy do archiwum zniknęły.

Boty uzyskiwały dostęp do nieistniejących plików

Drugą ważną rzeczą, jaką zauważyłem, było to, że istniała grupa botów, które uzyskiwały dostęp do plików na moim serwerze, które nie istniały. Problem polega na tym, że za każdym razem, gdy następuje dostęp do pliku, twój serwer musi załadować WordPress, wykonać wiązkę kodu PHP, a następnie wydać stronę 404.

Rozwiązaniem tego problemu jest edycja pliku .htaccess (Google to jeśli nie wiesz co to jest) i dodanie następujących linii.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(robots\.txt|sitemap\.xml(\.gz)?)
RewriteCond %{REQUEST_FILENAME} \.(css|js|html|htm|rtf|rtx|svg
|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc
|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|
m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf
|png|pot|pps|ppt|pptx|ra|ram|rar|swf|tar|tif|tiff|wav|wma|wri|
xla|xls|xlsx|xlt|xlw|zip)$ [NC]
Przepisz regułę .* – [L]

Po wstawieniu tych wierszy do pliku .htaccess serwer WWW najpierw sprawdzi, czy plik istnieje. Jeśli nie, wyda odpowiedź 404 BEZ ładowania WordPressa.

Boty uzyskiwały dostęp do adresów URL, które nie istniały

Niefortunne w sposobie pisania WordPressa jest to, że jeśli istnieje dostęp do artykułu, który nie istnieje w Twojej bazie danych, Twój serwer będzie musiał załadować WordPressa, wykonać kilka kodów PHP i wykonać kilka wyszukiwań MySQL przed wysłaniem 404 odpowiedź.

Jeśli przyjrzysz się uważnie swoim dziennikom, prawdopodobnie zauważysz pewne wzorce dostępu, które możesz wykluczyć, zanim dotrą do WordPressa.

Na przykład zauważyłem, że kilka botów uzyskiwało dostęp do mojej witryny za pomocą adresu URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . I za każdym razem mój serwer ładował WordPressa i wysyłał odpowiedź 404.

Więc zamiast prosić WordPressa o obsługę tych żądań, dodałem następujące wiersze do mojego pliku .htaccess

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} www\.facebook\.com/plugins [NC]
Przepisz regułę .* 404.html [L,R=404]

W powyższych wierszach mój serwer WWW szuka „www.facebook.com/plugins” w adresie URL i natychmiast wysyła odpowiedź 404 bez ładowania WordPressa. Przeglądając swoje dzienniki, znajdziesz wiele nieuczciwych dostępów, takich jak ten, który opisałem powyżej. Napisz regułę .htaccess dla każdego, a te dostępy nie będą już obciążać Twojego serwera.

Boty uderzały w moje linki do komentarzy

Pamiętasz, kiedy mówiłem Ci, że adresy URL z parametrami GET są inaczej obsługiwane przez wtyczkę buforującą? Odkryłem, że było mnóstwo botów, które waliły w moje artykuły z ustawionym parametrem „odpowiedz na komentarz”.

Kiedy tak się dzieje (w zależności od ustawień buforowania), wordpress zostaje załadowany, a plik z pamięci podręcznej/zip jest obsługiwany, nawet jeśli prawdopodobnie nigdy więcej nie będzie dostępny. To marnowanie zasobów.

Przykład zaczerpnięty z mojego dziennika
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

Rozwiązaniem jest przekierowanie wszystkich botów i crawlerów z tymi parametrami GET na główną stronę artykułu. Oto kod, który dodałem do mojego pliku .htaccess.

RewriteCond %{QUERY_STRING} odpowiedz docom
RewriteCond %{HTTP_USER_AGENT} ^(.*)(bot|crawl|spider|slurp) [NC]
Przepisz regułę .* https://mywifequitherjob.com%{REQUEST_URI}? [L]

Ten kod szuka parametru GET „replytocom”, a następnie usuwa ten parametr z końcowego adresu URL przed przedstawieniem dostępu do WordPressa.

Roboty indeksujące uzyskiwały dostęp do postów bez końcowego ukośnika

Nie jestem pewien, dlaczego tak się dzieje, ale zauważyłem grupę robotów indeksujących, które wydawały się legalnie próbować uzyskać dostęp do artykułów na moim blogu bez końcowego ukośnika w adresie URL.

Jak być może wiesz, ale nie musisz, adres URL w postaci http://twojblog.com/article/ różni się od adresu w postaci http://twójblog.com/article .

W rezultacie, gdy napotkany zostanie adres URL bez końcowego ukośnika, WordPress musi wkroczyć, uruchomić kilka kodu PHP, a następnie wydać przekierowanie 301 do artykułu z końcowym ukośnikiem. Aby usunąć WordPress z obrazu, możesz po prostu wstawić następującą regułę do pliku .htaccess.

# Dodaj końcowy ukośnik
RewriteCond %{REQUEST_FILENAME} !-f
PrzepiszCond %{REQUEST_URI} !(.*)/$
PrzepiszCond %{QUERY_STRING} !.*=.*
Przepisz regułę ^(.*)$ $1/ [L,R=301]

Dodając końcowy ukośnik, wysyłasz przekierowanie 301 do właściwego adresu URL, zanim trafi on do WordPressa, co pozwoli zaoszczędzić zasoby procesora.

Znalazłem błąd w WP Super Cache

W przeciwieństwie do większości ludzi nie mam zainstalowanego bloga WordPress w katalogu głównym mojego katalogu public_html. Ponadto strona główna mojego bloga nie jest również stroną z moimi wpisami. Kiedy masz swój blog skonfigurowany w taki sam sposób, jak ja, istnieje błąd w WP Super Cache, w którym wszystkie pliki pamięci podręcznej mogą zostać przedwcześnie usunięte, nawet jeśli wstępnie załadujesz pamięć podręczną.

Nie jestem pewien, czy autor wtyczki jest świadomy tego problemu, ale w zasadzie odkryłem, że za każdym razem, gdy do mojego bloga zostanie wysłany komentarz spamowy, cała moja pamięć podręczna zostanie błędnie opróżniona. Ponieważ przez cały czas otrzymuję spam z komentarzami i śledzeniem, moja pamięć podręczna była stale opróżniana, co sprawiło, że pamięć podręczna była znacznie mniej wydajna.

Spędziłem więc weekend na debugowaniu tego problemu i wreszcie opracowałem obejście. Jeśli ktoś z was ma te same problemy, daj mi znać, a pokażę ci moją poprawkę. Morał tej historii polega na tym, aby nigdy nie zakładać, że twoja wtyczka buforująca po prostu działa. Musisz zajrzeć do dzienników!

Wyłącz wtyczki intensywnie korzystające z procesora

Nawet jeśli wykonałeś wszystkie powyższe kroki, nie można odfiltrować wszystkich nieuczciwych dostępów, zanim dotrą do Twojego bloga WordPress.

Dlatego zawsze będziesz otrzymywać trafienia do swojej witryny, które nie będą skutecznie obsługiwane. Nie da się tego obejść.

Ale ważne jest, aby zdać sobie sprawę, że najprawdopodobniej nie będziesz miał problemu z przepustowością, będziesz miał problem z procesorem.

W rezultacie (i może to być sprzeczne z intuicją) tak naprawdę nie chcesz robić niczego wymagającego procesora, takiego jak „minifikowanie” lub „kompresowanie” swoich stron w locie. Minifikacja i kompresja pomagają zwiększyć przepustowość kosztem użycia procesora.

Ostatnią rzeczą, którą chcesz robić, jest minimalizowanie i buforowanie nieuczciwych dostępów. W rzeczywistości prawdopodobnie powinieneś rozważyć nie minimalizowanie lub kompresowanie adresów URL za pomocą parametrów GET.

Co najważniejsze, nie powinieneś używać w swojej witrynie żadnych wtyczek obciążających procesor. WP-Engine ma świetną listę wtyczek intensywnie korzystających z procesora, których prawdopodobnie powinieneś unikać.

Przeglądając moją listę wtyczek, zauważyłem, że używam wtyczki „podobne posty”. A kiedy spojrzałem na kod źródłowy, byłem zbulwersowany, gdy odkryłem, że wtyczka robiła pełne porównania tekstowe, aby znaleźć podobne artykuły, co jest głównym obciążeniem procesora i nie jest skalowalne.

Jak tylko znajdę odpowiedni zamiennik, ta wtyczka zdecydowanie trafia do kosza.

Morał historii

Tylko dlatego, że internetowy test prędkości mówi, że Twój blog jest szybki, nie ma większego znaczenia w ogólnym schemacie rzeczy.

Nie zrozum mnie źle. Szybkość ładowania strony jest ważna dla wyszukiwarek i stałych klientów, ale musisz również liczyć się z nieuczciwym dostępem, który może ominąć pamięć podręczną i rzucić serwer na kolana.

Więc nie instaluj na ślepo pamięci podręcznej i innych wtyczek przyspieszających. Poświęć trochę czasu na przeanalizowanie ruchu i napisz jak najwięcej reguł .htaccess, aby zminimalizować pracę, którą musi wykonać WordPress. Powodzenia!