Jak zoptymalizować Local WP w Windows, żeby ładował się szybciej

Do klonowania strony lokalnie Local WP jest bardzo dobry. Problem w tym, że czasami zaczyna działać wolno, nawet od samego początku i na mocnych komputerach.

I jasne, kiedy działa wolno, potrafi naprawdę doprowadzić do szału. Bo przecież, oprócz bezpieczeństwa, pracujesz lokalnie po to, żeby było szybciej, a nie po to, żeby czekać trzy sekundy za każdym razem, gdy otwierasz stronę admina.

W projekcie mojej nowej strony właśnie tak było, ale nie chciałem zmieniać narzędzia. Nie chciałem stawiać Dockera, wyrzucać środowiska ani zaczynać od zera. Chciałem, żeby Local WP znów był (bardzo) używalny.

Po przetestowaniu kilku rzeczy to właśnie te pięć kroków naprawdę u mnie zadziałało.

Jest więcej opcji optymalizacji, ale ja trzymałem się tych i teraz mój lokalny setup śmiga jak rakieta.

1. Potwierdzić, że Xdebug był wyłączony

Najpierw sprawdziłem Xdebug.

Xdebug służy do debugowania PHP. Jeśli zamierzasz ustawiać breakpointy, sprawdzać zmienne i robić poważny debugging, świetnie. Po to jest.

Ale jeśli go nie używasz, może dość mocno spowalniać środowisko.

W Local WP sprawdza się to z poziomu karty strony:

Local WP > twoja strona > zakładka Overview / Tools > Xdebug

W moim przypadku był już wyłączony, więc nie musiałem niczego ruszać. Ale z doświadczenia był pierwszym podejrzanym, którego trzeba było wykluczyć.

Zasada jest prosta: jeśli nie debugujesz aktywnie PHP, Xdebug wyłączony.

Tutaj nie było to “rozwiązanie” w moim przypadku, bo już był wyłączony, ale nic nie kosztuje to sprawdzić, zanim człowiek oszaleje przy innych rzeczach.

2. Zmienić domenę z .local na .test

Tę zmianę było czuć.

Miałem stronę z domeną kończącą się na .local (yg.local) i zmieniłem ją na yg.test.

W Local WP robi się to tak:

1. Otwierasz Local WP.
2. Wybierasz stronę.
3. Przechodzisz do zakładki Overview.
4. Szukasz pola Site domain.
5. Kliknij Change.
6. Zmieniasz domenę z .local na .test.
7. Potwierdzasz zmianę.
8. Restartujesz stronę.

Potem wchodzisz pod nowym adresem URL:

https://yg.test

Albo, jeśli nie masz aktywnego SSL w Local:

http://yg.test

Dlaczego to działa? 

Bo .local potrafi sprawiać problemy w niektórych środowiskach przez sposób rozwiązywania na poziomie sieci. .test jest znacznie bardziej przeznaczone do lokalnego developmentu i omija część tej absurdalnej tarczy.

To prosta zmiana, która w moim przypadku pomogła.

3. Wykluczyć foldery Local WP z antywirusa Windows

Kolejne ważne ustawienie.

Jeśli pracujesz na Windows, Windows Defender może stale sprawdzać pliki WordPressa, pluginy, motywy, uploads, bazę danych, logi, cache i wewnętrzne usługi Local.

A wiadomo, WordPress lokalnie przerzuca mnóstwo małych plików. Jeśli antywirus zaczyna sprawdzać wszystko, czego dotyka PHP, MySQL albo nginx, wydajność na tym cierpi.

Oczywiście nie wyłączyłem antywirusa; dodałem po prostu wykluczenia.

W Windows:

1. Otwórz Zabezpieczenia Windows.
2. Wejdź w Ochrona przed wirusami i zagrożeniami.
3. Przewiń do Ustawienia ochrony przed wirusami i zagrożeniami.
4. Kliknij Zarządzaj ustawieniami.
5. Przewiń do Wykluczenia.
6. Kliknij Dodaj lub usuń wykluczenia.
7. Dodaj wykluczenia typu Folder.

Ważny folder to ten od lokalnych stron:

C:UsersTWOJ_UZYTKOWNIKLocal Sites

A także wewnętrzne foldery Local, które zwykle znajdują się w ścieżkach takich jak:

C:UsersTWOJ_UZYTKOWNIKAppDataLocalProgramsLocal

I:

C:UsersTWOJ_UZYTKOWNIKAppDataRoamingLocal

W moim przypadku wykluczenie Local Sites było szczególnie ważne, bo właśnie tam naprawdę znajduje się strona: WordPress, pluginy, motywy, uploads i wszystko, czego Local stale dotyka.

Po dodaniu wykluczeń warto zatrzymać i ponownie uruchomić stronę z poziomu Local WP.

4. Wyłączyć pluginy, których nie potrzebowałem lokalnie

Następny krok był dość oczywisty, ale czasami o nim zapominamy albo wolimy go nie robić, żeby lepiej symulować środowisko produkcyjne.

Są pluginy, które wykonują połączenia zewnętrzne, zadania cykliczne, kontrole bezpieczeństwa, backupy, logi, cache, analizę SEO, integracje z newsletterami, monitoring, optymalizację obrazów i tysiąc innych rzeczy.

W lokalnym środowisku to wszystko może być zbędne, zależnie od tego, co testujesz.

Przejrzałem więc listę pluginów i wyłączyłem te, których w tamtym momencie nie potrzebowałem do pracy.

Pytanie było takie: 

Czy potrzebuję tego pluginu aktywnego do tego, co robię teraz?

Jeśli odpowiedź brzmiała nie, wyłączałem go.

W moim przypadku:

1. Pluginy do backupu.
2. Pluginy Genesis.
3. Pluginy bezpieczeństwa.
4. Pluginy cache.
5. Pluginy analityczne.
6. Pluginy uruchamiające zadania cykliczne

Mniej aktywnych pluginów to mniejsze obciążenie, mniej procesów w tle i mniej rzeczy konkurujących o zasoby.

Mimo wszystko nie zauważyłem tutaj dużej poprawy, więc być może warto zostawić ten krok na koniec, jeśli cała reszta nie wystarczy.

5. Wyczyścić bazę danych z shella Local

Ostatnim krokiem było wyczyszczenie bazy danych.

WordPress bardzo łatwo gromadzi śmieci: rewizje, automatyczne szkice, transients wygasłe, komentarze w koszu, spam, osierocone metadane i resztki pluginów.

Żeby to zrobić, otworzyłem shell strony z Local WP:

Local WP > twoja strona > Open Site Shell

Przed czyszczeniem zrobiłem kopię zapasową bazy danych:

wp db export backup-before-cleanup.sql

Potem uruchomiłem ten blok czyszczący:

wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp post delete $(wp post list --post_status='auto-draft' --format=ids) --force

wp post delete $(wp post list --post_status='trash' --format=ids) --force

wp comment delete $(wp comment list --status=spam --format=ids) --force

wp comment delete $(wp comment list --status=trash --format=ids) --force

wp transient delete --expired

wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL;"

wp db query "DELETE cm FROM wp_commentmeta cm LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id WHERE c.comment_ID IS NULL;"

wp db query "DELETE tm FROM wp_termmeta tm LEFT JOIN wp_terms t ON t.term_id = tm.term_id WHERE t.term_id IS NULL;"

wp db query "DELETE um FROM wp_usermeta um LEFT JOIN wp_users u ON u.ID = um.user_id WHERE u.ID IS NULL;"

wp db optimize

Uwaga na jedną rzecz: to zakłada, że prefiks tabel to wp_.

Jeśli jesteś na Windows i ta składnia zmiennej u ciebie nie działa, użyj bezpośrednio prefiksu, który zostanie zwrócony:

wp db prefix

i podmień go ręcznie.

Ten krok nie jest czymś, co robi się beztrosko na produkcji. Lokalnie, z wcześniejszą kopią zapasową, tak.

Wynik

Po tych pięciu krokach Local WP zaczął działać znacznie lepiej. Logiczne, bo mój Ryzen 7 2700 Pro z NMVE i 24GB jest wyraźnie mocniejszy niż serwer produkcyjny.

Dlatego było dla mnie jasne, że warto poświęcić chwilę.

Teraz działa jak trzeba i zaoszczędziłem sobie wielu chwil.

Podsumowanie byłoby takie:

1. Sprawdzić, czy Xdebug jest wyłączony.
2. Zmienić domenę z .local na .test.
3. Wykluczyć foldery Local WP w Windows Defender.
4. Wyłączyć niepotrzebne pluginy lokalnie.
5. Wyczyścić bazę danych z shella.

Krótko mówiąc, zdjąć balast ze środowiska.

W tym przypadku Local WP nie działa wolno z jednego powodu, tylko przez sumę drobiazgów: rozwiązywanie domeny, antywirus zaglądający do każdego pliku, zbędne pluginy i baza danych pełna resztek.

Nie mierzyłem każdego elementu stoperem, tylko na wyczucie. Dlatego wiem, co u mnie zadziałało.

Teraz mam lokalną kopię, która śmiga jak rakieta, więc skończyły mi się wymówki, żeby pracować na produkcji i nie testować.

A ty, dalej używasz tej samej wymówki?