Optymalizacja bloga WordPress w celu zmniejszenia obciążenia serwera. Identyfikujemy przyczynę zwiększonego obciążenia hostingu

Witam, drodzy czytelnicy bloga. Wesołych świąt!

Przez ten czas (około pół godziny) panel administracyjny wyświetla błąd 502 i choć witryna jest dostępna dla odwiedzających, strony otwierają się dość wolno (od 5 do 15 sekund). Gdyby na blogu nie zastosowano buforowania, wystąpiłby błąd 502. Jedyne, co pomaga, to albo dwukrotne ponowne uruchomienie serwera, albo głupie czekanie, aż wszystko samo się rozwiąże.

Poza tym chwilami wysokie obciążenia Wyszukiwanie na stronie nie działa i komentarze nie są wysyłane, ale to drobne rzeczy. Ogólnie rzecz biorąc, sytuacja, jak rozumiesz, jest nieprzyjemna, choć nie krytyczna. Wydaje się to znośne, ale jest denerwujące – okropne.

Ogólnie rzecz biorąc, WordPress wymaga oka i oka. Tak, silnik jest darmowy, jednocześnie profesjonalny i po prostu szalony, ale wszelkiego rodzaju złe ekscesy, nie, nie, a nawet się prześlizgują. Tutaj. Tym razem moją uwagę również przykuło „coś nowego”. Były to trzy linijki kodu (a raczej trzy hiperłącza do usług) ponownie w nagłówku strony generowanej przez WordPressa:

Po krótkim googlowaniu zdałem sobie sprawę, że „to” pojawiło się w WordPressie 4.4 i było do czegoś potrzebne (nadal nie mam pojęcia do czego – jeśli wiesz, wyjaśnij). Ponieważ „to” pojawiło się niedawno, w Google nie można było usunąć bardzo wielu przepisów na usuwanie, a to, co zostało znalezione, działało jakoś krzywo (pierwszy link został usunięty, ale dwa pozostałe nie i zaczęły prowadzić do tej samej strony, kod z których było otwarte).

Generalnie postanowiłem odłożyć to na razie do czasu wyjaśnienia sytuacji i pojawienia się recept na „odcięcie niepotrzebnych procesów”. Tak, jeszcze raz, jeśli jest na temat, to powiedz mi, bo te linki naprawdę mnie irytują. Przynajmniej do czego są potrzebne i czy niszczą promocję bloga. Ale tutaj na razie się wycofałem.

Dodatkowo w kodzie źródłowym pojawił się również bardzo zauważalny blok:

Pamiętam, że był tam już wcześniej. Pamiętam, że podobno już wcześniej wiedziałam, skąd to się wzięło, ale teraz, choć bardzo się starałam, nie mogłam sobie przypomnieć ani nawet złapać, skąd to „piękno” się wzięło w nagłówku bloga (było też na innych blogach ). Zawahałem się trochę psychicznie i wpatrzyłem się w słowo emoji w kodzie. Niedawno pisałem. Poszukałem trochę w Google i byłem przekonany, że tak - ten kod pomaga wyświetlić Strony WordPressa te same emotikony emoji.

Ponieważ emotikony emoji Wyniki uzyskałam najwyżej w dwóch, trzech artykułach, więc postanowiłam usunąć tę hańbę, dlatego szukałam przepisu w Internecie. Rozwiązaniem, jak zawsze w takich przypadkach, było dodanie filtrów z folderu motywu WordPress, którego używasz. Generalnie znajdujemy w nim punkt końcowy jakiejś funkcji (średnik) i dodajemy kilka linijek niezrozumiałego (dla mnie), ale całkiem działającego kodu:

Remove_action("wp_head", "print_emoji_detection_script", 7); usuń_akcję("admin_print_scripts", "print_emoji_detection_script"); usuń_akcję("wp_print_styles", "print_emoji_styles"); usuń_akcję("admin_print_styles", "print_emoji_styles"); usuń_filter("źródło_treści", "wp_staticize_emoji"); usuń_filter("comment_text_rss", "wp_staticize_emoji"); usuń_filter("wp_mail", "wp_staticize_emoji_for_email");

To jest najbardziej całkowite wyłączenie Obsługa emoji w WordPress. Jeśli chcesz, zostaw to w panelu administracyjnym. To wszystko, po tym było przyjemne uczucie czystości kodu z różnych rzeczy.

Na stronach, na których korzystałem z emoji, musiałem nieco poprawić tekst. Właśnie otworzyłem te artykuły do edycji w panelu administracyjnym i już na samym początku (at Edytor HTML, a nie wizualny) dodał właśnie ten kod, który został usunięty z nagłówka wszystkich stron:

window._wpemojiSettings = ("baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":"..min.js?ver=4.4") ); !function(a,b,c)(funkcja d(a)(var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline ="top",d.font="600 Arial 32px","flag"===a?(d.fillText(String.fromCharCode(55356,56806,55356,56826),0,0),c.toDataURL( ).length>3e3):("prosty"===a?d.fillText(String.fromCharCode(55357,56835),0,0):d.fillText(String.fromCharCode(55356,57135),0,0 ),0!==d.getImageData(16,16,1,1).data)):!1)funkcja e(a)(var c=b.createElement("script");c.src=a, c.type="text/javascript",b.getElementsByTagName("head").appendChild(c))var f,g;c.supports=(simple:d("simple"),flag:d("flaga" ),unicode8:d("unicode8"),c.DOMReady=!1,c.readyCallback=funkcja() (c.DOMReady=!0),c.supports.simple&&c.supports.flag&&c.supports.unicode8|| (g=funkcja())(c.readyCallback()),b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):( a .attachEvent("onload",g),b.attachEvent("onreadystatechange",function())("complete"===b.readyState&&c.readyCallback()))),f=c.source||() ,f .concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji))))(okno,dokument,okno._wpemojiSettings); img.wp-smiley, img.emoji ( display: inline !ważne; obramowanie: brak !ważne; box-shadow: brak !important; wysokość: 1em !ważne; szerokość: 1em !ważne; margines: 0.07em !ważne; Vertical-align: -0,1em !ważne; tło: brak !ważne; dopełnienie: 0 !ważne; )

To tyle, otrzymałem satysfakcję z choć częściowego rozwiązania problemu z czystością kod źródłowy i kontynuował swoje rutynowe czynności (pisanie artykułów i inne bzdury).

Jak przyszła realizacja

Jednak następnego dnia wkradły się wątpliwości – od dłuższego czasu nie było żadnych błędów. Wygląda na to, że pracuję z witryną od dłuższego czasu, ale 502 nie pojawia się w panelu administracyjnym. Nie sposób było uwierzyć w cud, bo już dziesięć razy zaczynałem świętować zwycięstwo, a kolejne powieszenie sprowadziło mnie z powrotem na ziemię.

Jednak po odczekaniu trochę przypomniałem sobie, że szukając rozwiązania na usunięcie obsługi emoji, przypomniałem sobie, że ten kod pojawiał się w WordPressie począwszy od wersji 4.2, a wyszedł dopiero wiosną, kiedy zacząłem mieć problemy. Jest całkiem prawdopodobne, że właśnie o to chodzi Aktualizacja WordPressa aż do następnej wersji i stał się powodem pojawienia się błędu z czasami dużym obciążeniem.

W każdym razie, jeśli chodzi o czas i fakt, że problem nie pojawia się po usunięciu kodu obsługi emoji, można było to zrobić pewne wnioski. Zrobiłam je i napisałam ten post. Jeśli problem pojawi się ponownie, tuż poniżej pojawi się P.S. z żalem za zmarnowany czas (przez Ciebie na czytanie i przeze mnie na pisanie).

Zdaniem dziennikarzy decyzja ta okazała się naprawdę niezręczna co najmniej patrząc z mojej niezwykle niskiej mentalnej dzwonnicy. Gdzie jest logika? Nie wiem, ale i tak miło, że choć przez przypadek, incydent techniczny, który dręczył mnie od dłuższego czasu, został mniej więcej pomyślnie rozwiązany. W tym celu pozwól mi odejść. Dziękuję za uwagę i jeszcze raz życzę Wesołych Świąt.

Powodzenia! Do zobaczenia wkrótce na stronach bloga

Więcej filmów możesz obejrzeć, przechodząc do „);”>

Możesz być zainteresowany

stracony lewe menu w panelu administracyjnym WordPress po aktualizacji. Skąd pobrać WordPress - tylko z oficjalnej strony wordpress.org
Instalacja WordPressa w szczegółach i zdjęciach, logując się do panelu administracyjnego WP i zmieniając hasło Pusta strona podczas przeglądania dużych postów (artykułów) w WordPress
Zmniejszenie zużycia pamięci w WordPressie podczas tworzenia stron - wtyczka WPLANG Lite do podmiany pliku lokalizacyjnego
Jak się zalogować Administrator WordPressa, a także zmienić login i hasło administratora, które otrzymałeś podczas instalacji silnika

Cześć cześć. Często blogerzy i webmasterzy stają przed takim problemem, że prędzej czy później ich projekty zaczynają strasznie zwalniać. Znacząco zwiększa obciążenie Procesor hostingowy, A tradycyjne metody W ogóle nie pomaga w rozwiązaniu. A dzisiaj chciałbym Ci powiedzieć, co zrobić, jeśli Twoja witryna WordPress działa wolno i jak w tym przypadku zmniejszyć obciążenie serwera.

W większości przypadków znaczne zawieszenia i spowolnienia witryny zaczynają się zupełnie nieoczekiwanie i dlatego naturalnie zaczyna się panika. W stanie strachu blogerzy zaczynają „wybierać” swoją witrynę, próbując uratować ją przed tym nieprzyjemnym problemem. Ale najczęściej takie „ratowanie” kończy się niepowodzeniem, prowadząc nawet do rozbiórki miejsca bez możliwości przywrócenia.

Jest to rzeczywiście bardzo godne ubolewania, zwłaszcza jeśli blog ma więcej niż rok i zgromadził wiele interesujących i przydatne artykuły, a liczby na liczniku odwiedzin z każdym dniem cieszą coraz bardziej. Nie chciałbyś znaleźć się w tak okropnej sytuacji? W takim razie masz szczęście. Chciałbym Cię teraz chronić przed złymi rzeczami i nauczyć, co zrobić, jeśli WordPress się zawiesi.

Zaledwie kilka dni temu skontaktował się ze mną jeden bloger i biznesmen informacyjny, którego wielu zna bardzo dobrze - Dmitry Zverev, skontaktował się ze mną z prośbą o przyjrzenie się poważnemu jąkaniu jego bloga. Oczywiście zgadzam się, to jest moja praca, zwłaszcza dlaczego nie pomóc dobremu człowiekowi? 🙂

Dmitry przesłał mi więc wszystkie dane ze strony i hostingu, a ja zacząłem je analizować. Wyobrażać sobie, Średnia prędkość Czas ładowania strony wyniósł aż 13 sekund.

Trudno, prawda? Co mogę powiedzieć, oprócz takiej „szybkości”, dostępność strony była kiepska, czasami strona otwierała się co drugi raz. Jednym słowem uległ katastrofalnej awarii i odmówił pełnej pracy. A najciekawsze było to, że przy logowaniu do panelu administracyjnego problemów było jeszcze więcej!

To wzbudziło moje zainteresowanie jeszcze bardziej, ponieważ nigdy wcześniej nie spotkałem się z czymś takim! „No cóż, spróbujmy, im trudniej, tym ciekawiej” – pomyślałem i zabrałem się do pracy.

Przede wszystkim zacząłem analizować te aktywowane i sprawdzać, które z nich najczęściej ładują witrynę. Analizę przeprowadziłem za pomocą wtyczki o nazwie P3. Jeśli ktoś chce dowiedzieć się o nim więcej, niech subskrybuje aktualizacje bloga. Na pewno napiszę o tym w którymś z kolejnych artykułów.

W ten sposób odkryłem 2 wtyczki, które ładowały bloga częściej niż inne, są to LeadPages i Galeria NextGEN. Ale po ich wyłączeniu i wyczyszczeniu pamięci podręcznej absolutnie nic się nie zmieniło. A potem zaczęła się zabawa. Zacząłem kopać coraz głębiej, żeby znaleźć prawdziwą przyczynę tej hańby :)

Po kilku eksperymentach i testach doszedłem do wniosku, że przyczyną problemu może być hosting. Napisałem do wsparcia Jino, ale nigdy nie otrzymałem jasnej odpowiedzi ani pomocy. Dlatego mogłem polegać tylko na sobie i swoim wieloletnim doświadczeniu.

I tak po dwóch dniach i wielu próbach, w tym zupełnie bezużytecznych, prędkość stała się następująca:

Poza tym ustały ciągłe awarie, a hosterzy przestali narzekać na wzrost Obciążenie procesora. Brawo! To o co zabiegałem, osiągnąłem – misja wykonana.

Ale co dokładnie zrobiłem i jak udało mi się wygrać? Chodźmy po kolei.

Zmniejszenie obciążenia serwera

1. Na początek polecam przeczytać jeden z moich pierwszych artykułów na temat zwiększania szybkości ładowania stron internetowych za pomocą. W tym artykule dowiesz się, jak przeprowadzić wysokiej jakości optymalizację witryny i skutecznie ją przyspieszyć, aby mogła ona działać w pełni. W tym artykule również to pokazuję najlepsze usługi aby sprawdzić prędkość.

Ale czasami te wskazówki nie wystarczą, na przykład, jak w przypadku Dmitrija. Po wykonaniu wszystkich kroków przyspieszających z tego artykułu, strona zaczęła otwierać się jeszcze gorzej, a hosterzy zaczęli dosłownie blokować do niej dostęp z powodu znacznego przeciążenia. Dlatego konieczne było wykonanie innych działań.

2. Często hamulce pojawiają się z powodu skryptu o nazwie WP-Cron. Ten skrypt wbudowany w WordPress odpowiada za planowanie zadań. Na przykład publikowanie artykułów według czasu, automatyczne czyszczenie kosze, kreacja kopia zapasowa za pomocą wtyczki itp.

Wszystko wydaje się w porządku, wszystko jest fajne i tak dalej, ale faktem jest, że Cron tworzy bardzo Ciężki ładunek na .A czasami hostingi nie wytrzymują takiego obciążenia i blokują dostęp do strony. W takim przypadku musisz wyłączyć ten skrypt a obciążenie zostanie znacznie zmniejszone.

Ale powinieneś zrozumieć, że działania, w których wykonujesz tryb automatyczny przestań działać, będziesz musiał to zrobić ręcznie. Ale nie ma w tym absolutnie nic skomplikowanego.

Istnieje kilka sposobów wyłączenia WP-Cron. Faktem jest, że część z nich (tak jak miało to miejsce w moim przypadku) może nie zadziałać, ale inne mogą.

1 sposób. Przejdź do katalogu głównego swojej witryny poprzez FTP, na przykład poprzez FileZilla, i otwórz tam plik o nazwie wp-config.php i dodaj nową linię:

Zdefiniuj('DISABLE_WP_CRON', prawda);

Wskazane jest dodanie go po linii:

Zdefiniuj('WPLANG', 'ru_RU');

Następnie zapisz plik i ciesz się, skrypt powinien zostać wyłączony.

Ale jeśli tak się nie stanie, musisz skorzystać z następujących opcji.

Metoda 2. Ponownie w katalogu głównym witryny musisz otworzyć plik o nazwie wp-cron.php, znajdź linię:

Ignore_user_abort(true);

i skomentuj go (wyłącz) za pomocą dwóch ukośników. Dane wyjściowe powinny wyglądać następująco:

//ignore_user_abort(true);

Zapisujemy plik, a cron jest wyłączony.

3. Następnie musisz włączyć kompresję zlib, która pozwala znacznie przyspieszyć działanie witryny w wyniku przetwarzania i kompresji kod php. Przede wszystkim musisz napisać do hostera i dowiedzieć się, czy masz włączoną funkcję zlib, czy nie. Jeśli jest podłączony, świetnie, ale jeśli nie, włącz go. Następnie przejdź do pliku header.php i wstaw na samą górę następujący kod:

Zapisujemy plik i odczuwamy znaczny wzrost prędkości.

4. Po czym bardzo ważna jest optymalizacja bazy danych za pomocą wtyczki. Przejdź do panelu administracyjnego, otwórz zakładkę „Wtyczki” - „Dodaj wtyczkę” i w wyszukiwarce wpisz „WP-Optimize”, naciśnij Enter i zainstaluj pierwszą wtyczkę.

Teraz nasza baza danych jest zoptymalizowana, a to kolejny plus w kierunku przyspieszenia witryny.

5. Teraz naszym zadaniem jest ochrona bloga przed atakami Ddos, ponieważ... To właśnie takie ataki często stają się przyczyną „łamania mózgu” witryny. W tym celu po pierwsze polecam zainstalować wtyczkę o nazwie iThemes Security, o jej skonfigurowaniu opowiem w następnym artykule, a po drugie ważne jest, aby zastosować blokowanie podejrzanych gości za pomocą .htaccess.

Nie będę teraz wyjaśniał jak szukać takich podejrzanych i złośliwych, bo to temat na osobny artykuł, ale podzielę się z Wami listą adresów IP, które udało mi się przez jakiś czas zebrać. To oni będą musieli zostać zablokowani.

Dzień dobry, drodzy czytelnicy bloga. Dzisiaj chcę porozmawiać o tym, jak zmniejszyć obciążenie serwera hostingowego utworzonego przez . Innymi słowy, zoptymalizujemy ten silnik, aby zmniejszyć obciążenie serwera hosta.

Ale wiesz, jak nazywa się twój projekt i nie jest konieczne uzyskiwanie dostępu do bazy danych podczas otwierania którejkolwiek z jego stron. Dlatego też, gdy już podejmiesz ostateczną decyzję o wyborze szablonu, możesz bezpiecznie zastąpić w jego plikach sekcje kodu realizujące zapytania do bazy danych konkretne nazwy, ścieżki itp. ().

W ten sposób zmniejszymy liczbę wywołań do bazy WP podczas ładowania którejkolwiek ze stron bloga i to nie mniej. Przejdźmy teraz od teorii do konkretów i zobaczmy co tak naprawdę da się poprawić.

Najpierw musisz uzyskać dostęp do plików motywu za pośrednictwem FTP. Są w folderze:

/wp-content/themes/nazwa_twojego_motywu

Zacznijmy od tego wspomnianego już powyżej – HEADER. Myślę, że znasz już Filezillę, a dostęp FTP do hosta nie jest dla Ciebie niczym nowym. Jeśli nie, to na górze znajduje się pole wyszukiwania i wystarczy wpisać tam słowo „filezilla” lub „notatnik”, aby uzyskać jak najwięcej pełna informacja dla tych dwóch niezwykle przydatnych programów.

HEADER implementuje całkiem sporo wywołań baz danych, które można łatwo zastąpić danymi statycznymi lub całkowicie usunąć. Na samej górze prawdopodobnie zobaczysz następujący fragment kodu:

zapytania w ciągu kilku sekund.

W rezultacie po załadowaniu strony, na samym dole (w obszarze stopki) zobaczysz ile zostało wykonanych wywołań do bazy danych:

Powodzenia! Do zobaczenia wkrótce na stronach bloga

Więcej filmów możesz obejrzeć, przechodząc do „);”>

Możesz być zainteresowany

Po aktualizacji lewe menu zniknęło w panelu administracyjnym WordPress
Tworzymy przyciski do dodawania do sieci społecznościowych i zakładki dla bloga WordPress (bez wtyczek i skryptów)
Zmniejszenie zużycia pamięci w WordPressie podczas tworzenia stron - wtyczka WPLANG Lite do podmiany pliku lokalizacyjnego Emotikony w WordPressie - jakie kody emotikonów wstawić, a także wtyczka Qip Smiles (piękne emotikony do komentarzy) Jak automatycznie dodać atrybut Alt do tagów Img swojego bloga na WordPress (jeśli ich nie ma)
Hyper Cache - włącz wtyczkę buforującą w WordPress, aby zoptymalizować blog WP i zmniejszyć jego obciążenie na serwerze hostingowym

Minął okres około 30 dni, nie ma już problemów w działaniu witryny i nie ma dużego obciążenia serwera, procesor nie jest już obserwowany. Teraz opowiem Wam, jak sobie poradziłam z okresowym dużym obciążeniem WordPressa na procesorze i serwerze.

Wszystko zaczęło się całkowicie spontanicznie i z każdym dniem odpowiedź serwera stawała się coraz dłuższa. Następnie w pewnym momencie w panelu webmasterów Yandex pojawiło się odpowiednie krytyczne powiadomienie. W którym na prawie 40 - 50 stronach serwisu wskazano długą odpowiedź serwera. Wszystko w porządku.

Treść artykułu: Duże obciążenie procesora serwera przez witrynę WordPress – główne objawy tego problemu

U mnie problem pojawił się zupełnie spontanicznie i w różnych okresach czasu. 100% obciążenie procesora serwera wynikało z przejść między stronami witryny. Około drugiej strony nastąpił gwałtowny skok wydajności procesora serwerowego. Chciałbym zauważyć, że w tej chwili pamięć RAM praktycznie nie ma wahań. A liczba procesów jest zupełnie nieznaczna i nie powinna tak obciążać procesora serwera.

Główne charakterystyczne oznaki obciążenia pracą, których doświadcza wielu webmasterów, to:

Zwiększenie limitu obciążenia procesora na serwerze hostingowym.
WordPress zaczął powodować niedopuszczalne obciążenie procesora.
Wartości szczytowe, poważne przeciążenie procesora na hostingu.
Długa odpowiedź serwera, zmienna wartość waha się od 5 do 30 sekund.
Nadmierne obciążenie pojawia się samoistnie, w różnych okresach czasu.
Strona zwalnia, strony prawie się nie ładują lub proces ten zajmuje bardzo dużo czasu.
Witryna ulega awarii na najwyższych poziomach.
WP tworzy długą odpowiedź serwera, strona nie jest stabilna. Podczas szczytowych wzrostów wydajności procesora pamięć RAM działa w normalnym, stabilnym trybie.
Liczba procesów, na które ma to wpływ i które są wykonywane w okresach wzrostu, jest minimalna.
Dostęp do partii strumieniowych i połączenia związane z Nginx lub Apache są minimalne.
Anomalia ta występuje kilka razy dziennie, w różnych odstępach czasu. Kończy się tak szybko, jak się zaczęło.

Dokładnie to samo stało się z moją witryną przez miesiąc. Dobrym przykładem mogą być następujące obrazy:

Jak widać, liczba zaangażowanych procesów jest minimalna. Pamięć RAM utrzymuje się na stałym poziomie, biorąc pod uwagę otwartą przeglądarkę i ogromną liczbę stron. Ale wszystkie rdzenie procesora pracują pod krytycznym obciążeniem i początkowo nie można w ogóle zrozumieć przyczyny.

Jakich metod próbowałem pokonać krytyczne obciążenie procesora?

Najczęstszą rzeczą jest to, że byłem winny wtyczek WP i braku pamięci. Chociaż szczerze mówiąc, silnik zużywa tylko 16 MB pamięci z dopuszczalnych 512 MB, które przeznaczyłem. Co właściwie próbowałem:

Wykonałem pełną aktualizację Debiana, a następnie wyczyściłem cały system.
Usunięto 99% zapisanych wersji baz danych na VestaCp.
Dwadzieścia razy przeglądałem pliki konfiguracyjne w VestaCp w poszukiwaniu błędów.
Znalazłem dużą liczbę logów systemowych na serwerze pocztowym Exim (całkowicie usuniętych).
Sprawdziłem witrynę pod kątem wirusów (nie ma ich).
Zrobiłem śledzenie witryny, sprawdziłem prędkość połączenia internetowego.
Na stronie wyłączyłem zapisywanie wersji rekordów, nie robiłem nic więcej na stronie. Strona jest zoptymalizowana pod kątem 98% powodów, dla których warto ją sprawdzić.

Po wszystkich podjętych krokach problem nie został rozwiązany. W ciągu miesiąca utrzymywały się wzrosty i szczytowe obciążenia krytyczne WP na procesorze serwera.

Jaki dokładnie był problem przeciążenia WP na procesorze i jak go rozwiązałem?

Problemem był błąd WP Cron. Około cztery miesiące temu zainstalowałem wtyczkę, która uniemożliwia aktualizację silnika, motywów i wtyczek. Pierwszym wywołaniem, jak rozumiem, były błędy w logach serwera witryny adresowane do wp-cron.php. Błąd polegał na przydzieleniu pamięci dla procesu, a raczej na niewystarczającej ilości pamięci. Kiedy przypomniałam sobie tę sytuację, od razu ją zauważyłam.

Co mi pomogło:

Zainstalowałem wtyczkę WP Crontrol - harmonogram zadań wp cron. Radzę zainstalować go natychmiast, bardzo dobre rozwiązanie.
Po instalacji zaobserwowałem szczytowe obciążenie około 900 identycznych zdarzeń, które, jak rozumiem, odnoszą się do obrazów.

Najprostszym rozwiązaniem jest zresetowanie wszystkich zdarzeń wp cron do ich pierwotnego stanu, odbywa się to w plikufunctions.php. Wystarczy w ciągu kilku sekund wstawić go na samym początku pliku pod zapytaniami.

Powyższa opcja wyświetli informację o liczbie wywołań bazy danych oraz czasie ładowania strony. Pamiętaj, że informacje będą widoczne tylko dla Ciebie. Oznacza to, że będzie wyświetlany tylko wtedy, gdy jesteś autoryzowany na stronie. Będzie to wyglądać mniej więcej tak:

Oczywiście możesz bawić się stylami, tłumaczyć „zapytania w” i „sekundy”, ale jest to opcjonalne. Osobiście i tak jestem zadowolony ze wszystkiego.

Optymalizacja szablonu WordPress

Optymalizacja szablonu lub motywu sprowadza się do zmniejszenia liczby wywołań do bazy danych. Ponieważ szablony są tworzone tak, aby były uniwersalne, programiści starają się wszystko zautomatyzować. Wszystko to odbywa się dla wygody użytkowników. Ale jeśli już wymyśliłeś motyw, którego będziesz używać, możesz już zacząć go optymalizować. Chodzi o to, aby standardowy kod PHP z wywołaniami do bazy danych zastąpić statycznym. Zrobimy to w dwóch plikach – nagłówku i stopce witryny. Zacznijmy od pierwszego.

Optymalizacja nagłówka.php

1. Znajdź kod

i zmień ją na nazwę swojego bloga. Mam to

Strona internetowa - tworzenie i promocja stron internetowych, blogów, zarabianie na stronie internetowej.

2. Kod odpowiedzialny za wyświetlanie opisu zostaje zastąpiony kodem statycznym.

3. Linia odpowiedzialna za wysyłanie kodowania.