For mange WordPress-plugins

#Nettstedet vi overtok

For mange plugins varsler sjelden om seg selv. Ingen enkelt plugin er skurken. Nettstedet fungerer, tregt, helt til noen måler det og finner at kostnaden er kumulativ: hvert plugin legger til spørringer, skript, stiler, en oppdateringsplikt og en bit angrepsflate, og tretti av dem sammen gjør et enkelt innholdsnettsted om til noe som bruker nesten åtte sekunder på å tegne opp.

#Den verste synderen var en visningsteller

Det største enkeltproblemet var ikke en tung page builder eller et bilde. Det var en visningsteller. Nettstedet telte artikkelvisninger ved å øke en verdi i wp_postmeta ved hver innlasting, synkront, inne i forespørselen. wp_postmeta er en generell nøkkel-verdi-tabell som WordPress leser fra konstant; den er ikke bygd for høyfrekvent skriving ved hvert besøk. Latt stå, hadde nettopp denne ene mekanismen vokst wp_postmeta til 322 MB av databasen på 705 MB.

Skaden er ikke bare disk. En oppblåst, varm wp_postmeta bremser en stor andel av normale WordPress-spørringer, fordi så mye av systemet leser fra den. Så en funksjon ingen tenkte på, et visningstall, beskattet stille hver side. Å fjerne den synkrone skrivingen og telle visninger riktig brakte den tabellen tilbake til en fornuftig størrelse og tok last av hver forespørsel.

#For mange plugins er også en sikkerhetshistorie

Antall plugins kostet ikke bare hastighet. Det utvidet angrepsflaten på de forutsigbare måtene:

• Et åpent xmlrpc.php-endepunkt, en klassisk vektor for brute force og forsterkning.
• PHP-feil vist i produksjon, som lekket serverstier (informasjonslekkasje).
• Plugins med kjente sårbarheter, fordi forlatte eller ikke-oppdaterte plugins slutter å bli lappet.

Derfor er det å kutte antall plugins et sikkerhetstiltak, ikke bare et ytelsestiltak. Hvert plugin du fjerner er kode du ikke lenger må stole på, overvåke og oppdatere. Det er den samme logikken som ligger bak en ordentlig WordPress-sikkerhetsrevisjon: mindre flate, færre veier inn.

#Hva som faktisk fikset det

Utbedringen var ujålete og effektiv:

• Vurder hvert plugin mot hva det faktisk gjorde, fjern så overlappene og de forlatte, og erstatt små plugin-oppgaver med noen linjer temakode.
• Skriv om visningstelleren slik at den ikke lenger skriver til wp_postmeta ved hver forespørsel, noe som lot databasen krympe igjen.
• Flytt over 1.5 GB statiske PDF-er fra applikasjonsserveren til Cloudflare R2 objektlagring, slik at VPS-en ikke serverte store filer den ikke hadde noe med å servere.
• Legg til en Redis-objektcache slik at gjentatte spørringer treffer minnet i stedet for databasen, og avlast VPS-en med 3 vCPU.
• Steng xmlrpc.php, slå av feilvisning i produksjon og bring de gjenværende pluginene opp til lappede versjoner.

Ingenting av dette er smart. Det er disiplin anvendt på en stack som ikke hadde noen, og det er hoveddelen av hva ekte Core Web Vitals-arbeid viser seg å være når man ser forbi laboratoriescoren.

#Hvorfor AI-assisterte byggeprosjekter stadig gjenskaper dette

For mange plugins fantes før AI. Men AI-assistenter gjør det verre på en bestemt måte: når svaret på hvert krav er “installer et plugin for det”, samler gjelden seg raskere, fordi å foreslå et plugin er minste motstands vei for en assistent akkurat som for en person i tidsnød. Du ender med den samme 30-plugin-stacken, bare satt sammen på en ettermiddag. Derfor sitter denne teardownen inne i vårt bredere arbeid med redning av AI-bygde nettsider: enten for mange plugins kom fra en person eller en prompt, er oppryddingen identisk, vurder, fjern, erstatt med målrettet kode og mål.

#Ordliste

• wp_postmeta - en sentral WordPress-tabell som lagrer nøkkel-verdi-metadata for innlegg; lest svært ofte, så å blåse den opp bremser hele nettstedet.
• Objektcache (Redis) - et lager i minnet som holder resultatene av gjentatte databasespørringer slik at de ikke treffer databasen hver gang.
• Objektlagring (Cloudflare R2) - lagring for statiske filer som PDF-er og bilder, servert uavhengig av applikasjonsserveren.
• LCP (Largest Contentful Paint) - hvor lang tid det tar før det største synlige elementet tegnes opp; et sentralt mål på opplevd lastehastighet.

#Konklusjonen

Hvis WordPress-nettstedet ditt har drevet forbi et dusin eller to plugins, er kostnaden nesten aldri én åpenbar synder. Det er opphopningen, pluss en eller to stille mekanismer, en visningsteller, en uindeksert logg, et synkront API-kall, som gjør ekte skade i bakgrunnen. Løsningen er å telle pluginene, finne mekanismen som skriver ved hver forespørsel, og flytte den tunge statiske vekten av applikasjonsserveren. Et nettsted på 7.7 sekunder er ikke håpløst. Det er som regel en stack ingen har revidert, noe som er et helt annet og mye billigere problem enn det ser ut som.