Slik optimaliserer du Local WP i Windows slik at det laster raskere

For å klone et nettsted lokalt Local WP er veldig bra. Problemet er at det av og til begynner å gå tregt, til og med helt fra starten og på kraftige maskiner.

Og klart, når det går tregt, blir det ganske frustrerende. For poenget med å jobbe lokalt, i tillegg til sikkerheten, er jo å jobbe raskere, ikke å vente tre sekunder hver gang du åpner en adminside.

I prosjektet med det nye nettstedet mitt skjedde dette, men jeg ville ikke bytte verktøy. Jeg ville ikke sette opp Docker, kaste miljøet eller begynne fra null. Jeg ville at Local WP skulle bli (veldig) brukbart igjen.

Etter å ha prøvd flere ting er dette de fem stegene som faktisk fungerte for meg.

Det finnes flere optimaliseringsmuligheter, men jeg holdt meg til disse, og nå går det lokale oppsettet mitt som en kule.

1. Bekrefte at Xdebug var deaktivert

Det første var å sjekke Xdebug.

Xdebug brukes til å debugge PHP. Hvis du skal sette breakpoints, inspisere variabler og gjøre seriøs debugging, perfekt. Det er det det er til.

Men hvis du ikke bruker det, kan det gjøre miljøet ganske mye tregere.

I Local WP sjekkes dette fra nettstedets panel:

Local WP > nettstedet ditt > fanen Overview / Tools > Xdebug

I mitt tilfelle var det allerede deaktivert, så jeg trengte ikke å røre noe. Men av erfaring var det den første mistenkte som måtte utelukkes.

Regelen er enkel: hvis du ikke aktivt debugger PHP, skal Xdebug være deaktivert.

Her var det ikke “løsningen” i mitt tilfelle, siden det allerede var av, men det koster ingenting å sjekke før man blir sprø av andre ting.

2. Endre domenet fra .local til .test

Denne endringen merket jeg.

Jeg hadde nettstedet med et domene som endte på .local (yg.local) og endret det til yg.test.

I Local WP gjør du det slik:

1. Åpne Local WP.
2. Velg nettstedet.
3. Gå til fanen Overview.
4. Finn feltet Site domain.
5. Trykk på Change.
6. Endre domenet fra .local til .test.
7. Bekreft endringen.
8. Start nettstedet på nytt.

Deretter går du inn med den nye URL-en:

https://yg.test

Eller, hvis du ikke har SSL aktivert i Local:

http://yg.test

Hvorfor fungerer det? 

Fordi .local kan skape trøbbel i enkelte miljøer på grunn av hvordan det løses på nettverksnivå. .test er langt mer beregnet på lokal utvikling og unngår noe av den absurde friksjonen.

Det er en enkel endring som hjalp i mitt tilfelle.

3. Utelukke Local WP-mappene i Windows-antiviruset

En annen viktig justering.

Hvis du jobber med Windows, kan Windows Defender stadig skanne WordPress-filene, plugins, temaer, uploads, databasen, logger, cacher og interne Local-tjenester.

Og klart, WordPress lokalt flytter enorme mengder små filer. Hvis antiviruset begynner å inspisere alt som berøres av PHP, MySQL eller nginx, går det utover ytelsen.

Jeg deaktiverte selvfølgelig ikke antiviruset; jeg la bare til unntak.

I Windows:

1. Åpne Windows Sikkerhet.
2. Gå til Virus- og trusselbeskyttelse.
3. Rull ned til Innstillinger for virus- og trusselbeskyttelse.
4. Trykk på Administrer innstillinger.
5. Rull ned til Utelatelser.
6. Trykk på Legg til eller fjern utelatelser.
7. Legg til utelatelser av typen Mappe.

Den viktige mappen er den for lokale nettsteder:

C:UsersDIN_BRUKERLocal Sites

Og også de interne mappene til Local, som vanligvis ligger i stier som:

C:UsersDIN_BRUKERAppDataLocalProgramsLocal

Og:

C:UsersDIN_BRUKERAppDataRoamingLocal

I mitt tilfelle var det spesielt viktig å utelate Local Sites, fordi det er der nettstedet faktisk ligger: WordPress, plugins, temaer, uploads og alt Local stadig berører.

Etter at du har lagt til unntakene, bør du stoppe og starte nettstedet på nytt fra Local WP.

4. Deaktivere plugins jeg ikke trengte lokalt

Neste steg var ganske åpenbart, men noen ganger glemmer vi det eller lar være for å simulere produksjonsmiljøet bedre.

Det finnes plugins som gjør eksterne kall, planlagte oppgaver, sikkerhetssjekker, backups, logger, cacher, SEO-analyser, integrasjoner med newsletters, overvåking, bildeoptimalisering og tusen andre ting.

Alt dette kan være overflødig lokalt, avhengig av hva du tester.

Så jeg gikk gjennom pluginlisten og deaktiverte dem jeg ikke trengte for arbeidet akkurat da.

Spørsmålet var dette: 

Trenger jeg dette pluginet aktivt for det jeg gjør nå?

Hvis svaret var nei, deaktiverte jeg det.

I mitt tilfelle:

1. Backup-plugins.
2. Genesis-plugins.
3. Sikkerhetsplugins.
4. Cache-plugins.
5. Analytics-plugins.
6. Plugins som starter planlagte oppgaver

Færre aktive plugins betyr mindre belastning, færre bakgrunnsprosesser og færre ting som konkurrerer om ressurser.

Likevel så jeg ikke noen stor forbedring her, så det kan være lurt å la dette steget være til slutt hvis alt det andre ikke er nok.

5. Rense databasen fra Local-shell

Det siste steget var å rense databasen.

WordPress samler veldig lett opp rot: revisjoner, automatiske utkast, transients utløpte, kommentarer i papirkurven, spam, foreldreløse metadata og pluginrester.

For å gjøre det åpnet jeg nettstedets shell fra Local WP:

Local WP > nettstedet ditt > Open Site Shell

Før jeg ryddet, tok jeg en sikkerhetskopi av databasen:

wp db export backup-before-cleanup.sql

Deretter kjørte jeg denne oppryddingsblokken:

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

Pass på én ting: dette antar at tabellprefikset er wp_.

Hvis du er på Windows og denne variabelsyntaksen ikke fungerer for deg, bruker du prefikset som returneres direkte:

wp db prefix

og erstatter det manuelt.

Dette steget er ikke noe man gjør lettvint i produksjon. Lokalt, med en tidligere backup, ja.

Resultat

Etter disse fem stegene begynte Local WP å gå ganske mye bedre. Logisk, fordi min Ryzen 7 2700 Pro med NMVE og 24GB er betydelig kraftigere enn produksjonsserveren.

Derfor var det klart for meg at det var verdt å bruke en liten stund.

Nå går det som det skal, og jeg har spart meg for mange små stunder.

Oppsummert blir det:

1. Sjekke at Xdebug er deaktivert.
2. Endre domenet fra .local til .test.
3. Utelukke Local WP-mapper i Windows Defender.
4. Deaktivere unødvendige plugins lokalt.
5. Rense databasen fra shell.

I praksis: ta ballast ut av miljøet.

I dette tilfellet er Local WP ikke tregt av én enkelt grunn, men på grunn av summen av småting: domeneoppløsning, antivirus som ser på hver fil, plugins som ikke trengs og en database full av rester.

Jeg målte ikke hver enkelt ting med stoppeklokke, men på følelsen. Derfor vet jeg hva som fungerte for meg.

Nå har jeg den lokale kopien min som går som en kule, så jeg er tom for unnskyldninger for å jobbe i produksjon og ikke teste.

Og du, bruker du fortsatt den samme unnskyldningen?