Så optimerar du Local WP i Windows så att det laddar snabbare

För att klona en webbplats lokalt Local WP är väldigt bra. Problemet är att det ibland börjar gå långsamt, till och med från första stund och på kraftfulla datorer.

Och visst, när det går långsamt blir man ganska frustrerad. För tanken är ju att du, förutom säkerheten, arbetar lokalt för att det ska gå snabbare, inte för att vänta tre sekunder varje gång du öppnar en adminsida.

I projektet med min nya webbplats hände det mig, men jag ville inte byta verktyg. Jag ville inte sätta upp Docker, kasta miljön eller börja om från noll. Jag ville att Local WP skulle bli (mycket) användbart igen.

Efter att ha testat flera saker är det här de fem steg som verkligen fungerade för mig.

Det finns flera andra optimeringsalternativ, men jag höll mig till dessa och nu går min lokala miljö som tåget.

1. Bekräfta att Xdebug var avstängt

Det första var att kontrollera Xdebug.

Xdebug används för att debugga PHP. Om du ska sätta breakpoints, inspektera variabler och göra seriös debugging är det perfekt. Det är det verktyget är till för.

Men om du inte använder det kan det sakta ner miljön ganska mycket.

I Local WP kontrolleras det från webbplatsens panel:

Local WP > din webbplats > fliken Overview / Tools > Xdebug

I mitt fall var det redan avstängt, så jag behövde inte röra något. Men av erfarenhet var det den första misstänkta saken att utesluta.

Regeln är enkel: om du inte aktivt debuggar PHP ska Xdebug vara avstängt.

Här var det inte “lösningen” i mitt fall, eftersom det redan var avstängt, men det kostar inget att kontrollera innan man blir galen på annat.

2. Byta domänen från .local till .test

Den här ändringen märktes.

Jag hade webbplatsen med en domän som slutade på .local (yg.local) och ändrade den till yg.test.

I Local WP gör du så här:

1. Öppna Local WP.
2. Välj webbplatsen.
3. Gå till fliken Overview.
4. Leta upp fältet Site domain.
5. Klicka på Change.
6. Byt domänen från .local till .test.
7. Bekräfta ändringen.
8. Starta om webbplatsen.

Därefter går du in med den nya URL:en:

https://yg.test

Eller, om du inte har SSL aktiverat i Local:

http://yg.test

Varför fungerar det? 

För att .local kan strula i vissa miljöer på grund av hur det löses på nätverksnivå. .test är mycket mer avsett för lokal utveckling och undviker en del av den där absurda friktionen.

Det är en enkel ändring som hjälpte i mitt fall.

3. Undanta Local WP-mappar i Windows antivirus

En annan viktig justering.

Om du arbetar med Windows, kan Windows Defender hela tiden granska WordPress-filerna, plugins, teman, uploads, databasen, loggar, cache och Locals interna tjänster.

Och visst, WordPress lokalt flyttar mängder av små filer. Om antiviruset börjar inspektera allt som rörs av PHP, MySQL eller nginx, påverkas prestandan.

Jag stängde förstås inte av antiviruset, utan lade till undantag.

I Windows:

1. Öppna Windows-säkerhet.
2. Gå till Virus- och hotskydd.
3. Bläddra ner till Inställningar för virus- och hotskydd.
4. Klicka på Hantera inställningar.
5. Bläddra ner till Undantag.
6. Klicka på Lägg till eller ta bort undantag.
7. Lägg till undantag av typen Mapp.

Den viktiga mappen är den för lokala webbplatser:

C:UsersDIN_ANVANDARELocal Sites

Och även Locals interna mappar, som vanligtvis finns i sökvägar som:

C:UsersDIN_ANVANDAREAppDataLocalProgramsLocal

Och:

C:UsersDIN_ANVANDAREAppDataRoamingLocal

I mitt fall var det särskilt viktigt att undanta Local Sites, eftersom det är där webbplatsen faktiskt finns: WordPress, plugins, teman, uploads och allt som Local ständigt rör vid.

Efter att ha lagt till undantagen är det bra att stoppa och starta webbplatsen igen från Local WP.

4. Inaktivera plugins jag inte behövde lokalt

Nästa steg var ganska uppenbart, men ibland glömmer vi det eller låter bli för att bättre simulera produktionsmiljön.

Det finns plugins som gör externa anrop, schemalagda uppgifter, säkerhetskontroller, backups, loggar, cache, SEO-analys, newsletter-integrationer, övervakning, bildoptimering och tusen andra saker.

Allt det där kan vara onödigt lokalt, beroende på vad du testar.

Så jag gick igenom pluginlistan och inaktiverade de jag inte behövde för arbetet just då.

Frågan var denna: 

Behöver jag ha detta plugin aktivt för det jag gör just nu?

Om svaret var nej inaktiverade jag det.

I mitt fall:

1. Backup-plugins.
2. Genesis-plugins.
3. Säkerhetsplugins.
4. Cache-plugins.
5. Analytics-plugins.
6. Plugins som startar schemalagda uppgifter

Färre aktiva plugins betyder mindre belastning, färre bakgrundsprocesser och färre saker som konkurrerar om resurser.

Ändå såg jag ingen stor förbättring här, så det kanske är bättre att lämna detta steg till slutet om allt annat inte räcker.

5. Rensa databasen från Locals shell

Det sista steget var att rensa databasen.

WordPress samlar lätt på sig skräp: revisioner, automatiska utkast, transients utgångna, kommentarer i papperskorgen, spam, föräldralös metadata och pluginrester.

För att göra det öppnade jag webbplatsens shell från Local WP:

Local WP > din webbplats > Open Site Shell

Innan jag rensade gjorde jag en backup av databasen:

wp db export backup-before-cleanup.sql

Sedan körde jag detta rensningsblock:

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

En sak att se upp med: detta antar att tabellprefixet är wp_.

Om du är på Windows och den variabelsyntaxen inte fungerar för dig, använd prefixet som returneras direkt:

wp db prefix

och ersätt det manuellt.

Det här steget är inget man ska göra lättvindigt i produktion. Lokalt, med föregående backup, ja.

Resultat

Efter dessa fem steg började Local WP gå betydligt bättre. Logiskt, eftersom min Ryzen 7 2700 Pro med NMVE och 24GB är betydligt kraftfullare än produktionsservern.

Därför var det tydligt för mig att det var värt att lägga en liten stund.

Nu går det som det ska och jag har sparat många små stunder.

Sammanfattningen skulle vara:

1. Kontrollera att Xdebug är avstängt.
2. Byta domänen från .local till .test.
3. Undanta Local WP-mappar i Windows Defender.
4. Inaktivera onödiga plugins lokalt.
5. Rensa databasen från shell.

I grund och botten: ta bort ballast från miljön.

I det här fallet är Local WP inte långsamt av en enda orsak, utan på grund av summan av små saker: domänupplösning, antivirus som tittar på varje fil, plugins som inte behövs och en databas full av rester.

Jag mätte inte varje sak med stoppur, utan på känsla. Därför vet jag vad som fungerade för mig.

Nu har jag min lokala kopia som går som tåget, så jag har inga ursäkter kvar för att arbeta i produktion och inte testa.

Och du, använder du fortfarande samma ursäkt?