Local WP in Windows optimaliseren zodat het sneller laadt

Om een website lokaal te klonen Local WP is erg goed. Het probleem is dat het soms traag begint te worden, zelfs vanaf het eerste moment en op krachtige machines.

En natuurlijk, als het traag is, word je er behoorlijk gek van. Want je werkt lokaal niet alleen om veiligheidsredenen, maar ook om sneller te zijn, niet om drie seconden te wachten telkens wanneer je een adminpagina opent.

Bij het project voor mijn nieuwe website gebeurde dat bij mij, maar ik wilde niet van tool veranderen. Ik wilde geen Docker opzetten, de omgeving niet weggooien en niet vanaf nul beginnen. Ik wilde dat Local WP weer (heel) bruikbaar werd.

Na verschillende dingen te hebben geprobeerd, zijn dit de vijf stappen die voor mij echt werkten.

Er zijn nog meer optimalisatieopties, maar ik heb me aan deze gehouden en nu loopt mijn lokale omgeving als een trein.

1. Controleren dat Xdebug uitgeschakeld was

Het eerste wat ik deed was controleren Xdebug.

Xdebug dient om PHP te debuggen. Als je breakpoints gaat zetten, variabelen wilt inspecteren en serieus wilt debuggen, prima. Daar is het voor.

Maar als je het niet gebruikt, kan het de omgeving behoorlijk vertragen.

In Local WP controleer je dit vanuit het sitepaneel:

Local WP > je site > tab Overview / Tools > Xdebug

In mijn geval was het al uitgeschakeld, dus ik hoefde niets aan te raken. Maar uit ervaring was het de eerste verdachte die ik moest uitsluiten.

De regel is simpel: als je PHP niet actief aan het debuggen bent, Xdebug uitgeschakeld laten.

Hier was het in mijn geval niet “de oplossing”, omdat het al uit stond, maar het kost niets om dit te controleren voordat je gek wordt van andere dingen.

2. Het domein wijzigen van .local naar .test

Deze wijziging was wel merkbaar.

Ik had de site met een domein dat eindigde op .local (yg.local) en heb het gewijzigd naar yg.test.

In Local WP doe je dat zo:

1. Open Local WP.
2. Selecteer de site.
3. Ga naar het tabblad Overview.
4. Zoek het veld Site domain.
5. Klik op Change.
6. Wijzig het domein van .local naar .test.
7. Bevestig de wijziging.
8. Start de site opnieuw.

Daarna ga je naar de nieuwe URL:

https://yg.test

Of, als je geen SSL actief hebt in Local:

http://yg.test

Waarom werkt het? 

Omdat .local in sommige omgevingen problemen kan geven door de manier waarop het op netwerkniveau wordt opgelost. .test is veel meer bedoeld voor lokale ontwikkeling en voorkomt een deel van die absurde frictie.

Het is een eenvoudige wijziging die in mijn geval hielp.

3. De Local WP-mappen uitsluiten in de Windows-antivirus

Nog een belangrijke aanpassing.

Als je met Windows werkt, kan Windows Defender voortdurend de WordPress-bestanden aan het scannen zijn, plugins, thema’s, uploads, database, logs, caches en interne diensten van Local.

En natuurlijk verplaatst WordPress lokaal enorm veel kleine bestanden. Als de antivirus alles gaat inspecteren wat wordt aangeraakt door PHP, MySQL of nginx, dan lijdt de performance daaronder.

Natuurlijk heb ik de antivirus niet uitgeschakeld; ik heb alleen uitsluitingen toegevoegd.

In Windows:

1. Open Windows-beveiliging.
2. Ga naar Virus- en bedreigingsbeveiliging.
3. Scroll naar Instellingen voor virus- en bedreigingsbeveiliging.
4. Klik op Instellingen beheren.
5. Scroll naar Uitsluitingen.
6. Klik op Uitsluitingen toevoegen of verwijderen.
7. Voeg uitsluitingen van het type Map toe.

De belangrijke map is die van de lokale sites:

C:UsersJOUW_GEBRUIKERLocal Sites

En ook de interne mappen van Local, die meestal in paden staan zoals:

C:UsersJOUW_GEBRUIKERAppDataLocalProgramsLocal

En:

C:UsersJOUW_GEBRUIKERAppDataRoamingLocal

In mijn geval was het uitsluiten van Local Sites vooral belangrijk, omdat daar de website echt staat: WordPress, plugins, thema’s, uploads en alles wat Local voortdurend aanraakt.

Na het toevoegen van de uitsluitingen is het verstandig de site vanuit Local WP te stoppen en opnieuw te starten.

4. Plugins uitschakelen die ik lokaal niet nodig had

De volgende stap was vrij vanzelfsprekend, maar soms vergeten we hem of doen we het liever niet om de productieomgeving beter te simuleren.

Er zijn plugins die externe oproepen doen, geplande taken uitvoeren, beveiligingscontroles, backups, logs, caches, SEO-analyses, nieuwsbriefintegraties, monitoring, beeldoptimalisatie en nog duizend andere dingen.

Dat alles kan lokaal overbodig zijn, afhankelijk van wat je aan het testen bent.

Dus heb ik de pluginlijst bekeken en de plugins uitgeschakeld die ik op dat moment niet nodig had om te werken.

De vraag was deze: 

Heb ik deze plugin actief nodig voor wat ik nu aan het doen ben?

Als het antwoord nee was, schakelde ik hem uit.

In mijn geval:

1. Back-upplugins.
2. Genesis-plugins.
3. Beveiligingsplugins.
4. Cacheplugins.
5. Analytics-plugins.
6. Plugins die geplande taken starten

Minder actieve plugins betekent minder belasting, minder achtergrondprocessen en minder dingen die om resources concurreren.

Hoe dan ook, ik zag hier geen grote verbetering, dus misschien kun je deze stap beter tot het einde bewaren als al het andere niet genoeg is.

5. De database opschonen vanuit de Local-shell

De laatste stap was het opschonen van de database.

WordPress verzamelt heel gemakkelijk rommel: revisies, automatische concepten, transients verlopen items, reacties in de prullenbak, spam, verweesde metadata en pluginresten.

Om dat te doen, opende ik de site-shell vanuit Local WP:

Local WP > je site > Open Site Shell

Voordat ik ging opschonen, maakte ik een back-up van de database:

wp db export backup-before-cleanup.sql

Daarna voerde ik dit opschoonblok uit:

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

Let op één ding: dit gaat ervan uit dat het tabelvoorvoegsel wp_ is.

Als je op Windows zit en die variabelesyntaxis niet werkt, gebruik dan rechtstreeks het voorvoegsel dat wordt teruggegeven:

wp db prefix

en vervang het handmatig.

Deze stap is niet iets om zomaar in productie te doen. Lokaal, met een voorafgaande back-up, wel.

Resultaat

Na deze vijf stappen begon Local WP behoorlijk beter te draaien. Logisch, want mijn Ryzen 7 2700 Pro met NMVE en 24GB is aanzienlijk krachtiger dan de productieserver.

Daarom was het voor mij duidelijk dat het de moeite waard was er even tijd aan te besteden.

Nu draait het zoals het hoort en heb ik mezelf heel wat momentjes bespaard.

Samengevat:

1. Controleren dat Xdebug is uitgeschakeld.
2. Het domein wijzigen van .local naar .test.
3. Local WP-mappen uitsluiten in Windows Defender.
4. Onnodige plugins lokaal uitschakelen.
5. De database opschonen vanuit de shell.

In feite: ballast uit de omgeving halen.

In dit geval is Local WP niet traag door één enkele oorzaak, maar door de optelsom van kleine dingen: domeinresolutie, antivirus die elk bestand bekijkt, overbodige plugins en een database vol resten.

Ik heb ze niet allemaal met een stopwatch gemeten, maar op gevoel. Daarom weet ik wat voor mij werkte.

Nu heb ik mijn lokale kopie die als een trein loopt, dus ik heb geen excuses meer om in productie te werken en niet te testen.

En jij, gebruik je nog steeds dezelfde smoes?