Hver WordPress-plugin legger til PHP-kode som kjøres ved sideinnlasting, henter inn skript og stilsett, og noen ganger gjør ekstra databasespørringer. Jo flere plugin-er du har, desto tyngre blir sidene dine. Men problemet er ikke bare antall: selv en enkelt «pratsom» plugin som Contact Form 7 laster sine .css- og .js-filer på alle sider som standard, inkludert sider der det ikke finnes noe skjema i det hele tatt.

CF7-utviklerne erkjenner åpent at plugin-en laster ressurser overalt fordi shortcode-en kan dukke opp hvor som helst. Denne logikken er ikke unik for CF7; de fleste plugin-er fungerer på samme måte. Resultatet: bloggens hjemmeside laster skript for en gallerislider som aldri var der i utgangspunktet.

Den gode nyheten: WordPress lar deg selektivt deaktivere plugin-innlasting kun på sider der de faktisk trengs. Vi dekker begge tilnærminger: programmatisk (ved hjelp av en mu-plugin med option_active_plugins-filteret) og plugin-basert (Plugin Organizer, Perfmatters, Plugin Load Filter). Til slutt måler vi resultatene ved hjelp av nettleserens nettverksmonitor.

💡 Rask oversikt:

• Velg plugin-er basert på tre kriterier: utviklerens omdømme, ytelse under belastning og faktisk nødvendighet
• Programmatisk tilnærming: skriv en PHP-snutt som bruker get_option('active_plugins') for å hente listen over aktive plugin-er og filtrerer dem etter side-URL
• Mu-plugin: plasser filteret i /wp-content/mu-plugins/ slik at det kjøres FØR alle vanlige plugin-er, og deaktiverer unødvendige i farten
• Plugin-tilnærming: Plugin Organizer og Perfmatters gir et visuelt grensesnitt for de samme oppgavene uten å skrive en eneste linje kode
• Mål effekten ved hjelp av Chrome/Firefox DevTools: etter filtrering synker HTTP-forespørslene og lastetiden reduseres merkbart

Tre regler for valg av plugin-er

Før du filtrerer plugin-innlasting, sørg for at plugin-ene på nettstedet ditt faktisk fortjener en plass i wp_options. Tre regler som sparer deg for hodepine og serverressurser.

Installer kun verifiserte plugin-er fra utviklere med dokumentert erfaring. Åpne plugin-siden på WordPress.org og sjekk: antall aktive installasjoner, vurdering, dato for siste oppdatering og antall løste support-saker. En plugin med 100 000+ installasjoner, en vurdering på 4,5+ og en oppdatering i løpet av de siste 3 månedene er et trygt valg.

Foretrekk skalerbare plugin-er. To plugin-er med identisk funksjonalitet kan påvirke hastigheten forskjellig. Sammenlign kandidater ved hjelp av nettleserens inspector (Nettverk-fanen) eller nettbaserte tjenester som Google PageSpeed Insights, Pingdom og GTmetrix; mål lastetid og antall HTTP-forespørsler før og etter installasjon.

Ikke behold dødvekt. Hver ubrukt plugin betyr ekstra PHP-kode i hver forespørsel. Gjennomgå listen over aktive plugin-er jevnlig og fjern dem nettstedet ditt kan leve uten. Hvis en plugin «kan komme til nytte om seks måneder», deaktiver og slett den, og installer en fersk versjon om seks måneder.

Eksempel fra virkeligheten: Contact Form 7

Contact Form 7 er det perfekte testobjektet. Den legger til på hver side:

• style.css for skjemastiler
• scripts.js for validerings- og innsendingslogikk

Selv om en side ikke har noen [contact-form-7]-shortcode, lastes begge filene trofast. Skjermbildet nedenfor viser Chrome DevTools Nettverk-panel, som ikke lyver:

Løsningen: enten endre innlastingslogikken inne i plugin-en (noe som vil ryke ved oppdatering) eller selektivt deaktivere plugin-en for alle sider unntatt den du trenger. Den andre tilnærmingen er mer pålitelig, så la oss fokusere på den.

Trinn 1. Hent listen over aktive plugin-er via PHP

Før filtrering må du forstå hvor WordPress lagrer listen over aktive plugin-er. De ligger alle i wp_options-tabellen, i raden med nøkkelen active_plugins. Du kan hente arrayet med en enkelt get_option-funksjon.

Legg til denne koden i Code Snippets-plugin-en eller i din egen plugin-fil (ikke glem plugin-headeren øverst):

1
<?php
2
/**
3
 * Plugin Name: Active Plugins Lister
4
 */
5
 
6
add_shortcode( 'activeplugins', function() {
7
    $active_plugins = get_option( 'active_plugins' );
8
    $plugins = "";
9
    if ( count( $active_plugins ) > 0 ) {
10
        $plugins = "<ul>";
11
        foreach ( $active_plugins as $plugin ) {
12
            $plugins .= "<li>" . $plugin . "</li>";
13
        }
14
        $plugins .= "</ul>";
15
    }
16
    return $plugins;
17
} );

Lagre filen som active-plugins.php og last den opp til /wp-content/plugins/. Opprett en testside, sett inn shortcoden [activeplugins], så får du en nummerert liste over alle aktive utvidelser i formatet folder/file.php.

Slik ser resultatet ut etter at du har satt inn shortcoden på en side:

Steg 2. Filteret option_active_plugins: hovedverktøyet ditt

Nå til hovedverktøyet: filteret option_active_plugins. Det tilhører filterfamilien option_$option_name og kjøres hver gang WordPress henter en innstillingsverdi fra databasen. Siden aktive utvidelser lagres som innstillingen active_plugins, lar dette filteret deg endre listen i farten: fjerne uønskede utvidelser eller legge til nye.

Her er et minimalt eksempel som programmatisk aktiverer Advanced Custom Fields (forutsatt at utvidelsen allerede er installert):

1
add_filter( 'option_active_plugins', function( $plugins ) {
2
    $myplugin = "advanced-custom-fields/acf.php";
3
    if ( ! in_array( $myplugin, $plugins ) ) {
4
        $plugins[] = $myplugin;
5
    }
6
    return $plugins;
7
} );

Denne koden legger ACF til i listen over aktive utvidelser på hver side. Ikke spesielt praktisk, men prinsippet er tydelig: du kan endre $plugins-listen akkurat som du vil.

Viktig merknad: filteret må kjøre før vanlige utvidelser, ellers vil WordPress lese den ufiltrerte listen først. Det er det mu-plugins er til for.

Steg 3. Lag en mu-plugin for selektiv deaktivering

Must-use-utvidelser ligger i /wp-content/mu-plugins/ og kjøres før alle vanlige utvidelser. Det er akkurat det vi trenger: filteret vårt får kontroll først.

Det er én hake: WordPress' betingelsestagger (is_page(), is_single() og andre) fungerer ikke i mu-plugins fordi forespørselen ikke er analysert ennå, så de returnerer alle false. Du må analysere URL-en manuelt via $_SERVER['REQUEST_URI'].

Her er en ferdig mu-plugin som deaktiverer Contact Form 7 på alle sider unntatt /contact/:

1
$request_uri = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );
2
$is_admin    = strpos( $request_uri, '/wp-admin/' );
3
 
4
if ( false === $is_admin ) {
5
    add_filter( 'option_active_plugins', function( $plugins ) {
6
        global $request_uri;
7
 
8
        $is_contact_page = strpos( $request_uri, '/contact/' );
9
        $myplugin        = "contact-form-7/wp-contact-form-7.php";
10
        $k               = array_search( $myplugin, $plugins );
11
 
12
        if ( false !== $k && false === $is_contact_page ) {
13
            unset( $plugins[ $k ] );
14
        }
15
 
16
        return $plugins;
17
    } );
18
}

La oss bryte det ned linje for linje:

• parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH ) henter forespørselsstien (for eksempel /blog/kak-otkljuchit-plaginy/)
• strpos( $request_uri, '/wp-admin/' ) sjekker om vi er i adminområdet; i så fall gjelder ikke filteret, slik at innstillingssidene for utvidelser forblir tilgjengelige
• array_search( $myplugin, $plugins ) finner CF7 i listen over aktive utvidelser
• unset( $plugins[ $k ] ) fjerner utvidelsen fra listen hvis vi IKKE er på kontaktsiden

Lagre filen, last den opp til /wp-content/mu-plugins/, og tøm hurtigbufferen. Nå skal shortcoden [activeplugins] vise Contact Form 7 bare på /contact/-siden.

Slik ser det samme prinsippet ut for flere utvidelser samtidig. I stedet for array_search med én enkelt utvidelse, bruk en matrise og array_diff:

1
$request_uri = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );
2
$is_admin    = strpos( $request_uri, '/wp-admin/' );
3
 
4
if ( false === $is_admin ) {
5
    add_filter( 'option_active_plugins', function( $plugins ) {
6
        global $request_uri;
7
 
8
        $is_contact_page = strpos( $request_uri, '/contact/' );
9
        $myplugins       = array(
10
            "contact-form-7/wp-contact-form-7.php",
11
            "code-snippets/code-snippets.php",
12
            "query-monitor/query-monitor.php",
13
            "autoptimize/autoptimize.php"
14
        );
15
 
16
        if ( false === $is_contact_page ) {
17
            $plugins = array_diff( $plugins, $myplugins );
18
        }
19
 
20
        return $plugins;
21
    } );
22
}

Funksjonen array_diff returnerer verdier fra den første matrisen som ikke finnes i den andre, akkurat det du trenger for massedeaktivering.

Resultatet er umiddelbart synlig i Nettverk-panelet: Contact Form 7s script.js-fil forsvinner fra ressurslisten på alle sider unntatt kontaktsiden.

Den programmatiske tilnærmingen er fleksibel, men krever kodeendringer for hver nye utvidelse. For dem som foretrekker et visuelt grensesnitt, finnes det ferdige filterutvidelser.

Plugin-basert tilnærming: filtrering uten kode

Plugin Load Filter

Plugin Load Filter er et gratis verktøy for å filtrere utvidelser etter flere betingelser. Det støtter:

• filtrering etter innholdstype (innlegg, sider, egendefinerte innholdstyper)
• filtrering etter innleggsformat
• unntak for Jetpack-moduler
• URL-filtrering for REST API-, Heartbeat-, AJAX- og AMP-forespørsler

Innstillinger for aktivering av filteret etter sidetype:

Etter aktivering konfigurerer administratoren hvilke sider filteret gjelder for via fanen «Filter Activation by Page Type». Minimalistisk og greit.

Plugin Organizer

Plugin Organizer er en veteran blant filtreringsutvidelser med 5-stjerners vurdering. Den gir deg full kontroll over innlasting:

• selektiv deaktivering av utvidelser etter side-URL
• deaktivering etter brukerrolle
• utvidelsesgrupper (aktiver/deaktiver flere samtidig)
• endring av innlastingsrekkefølge for utvidelser

På «Global Plugins»-siden kan du dra og slippe for å deaktivere en utvidelse globalt for hele nettstedet og selektivt reaktivere den på bestemte sider via en metaboks i innleggsredigering. I skjermbildet nedenfor er Contact Form 7 globalt deaktivert:

Og her er den samme metaboksen på redigeringsskjermen for kontaktsiden, som overstyrer globale innstillinger:

Plugin Organizer viser også feilsøkingsinformasjon: hvilke utvidelser som faktisk ble lastet på hver side og hvorfor. Dokumentasjon er tilgjengelig på utviklerens nettsted.

Perfmatters

Perfmatters er et premiumverktøy fra utviklingsteamet hos Kinsta. Hovedfunksjonen, Script Manager, grupperer alle skript og stiler etter utvidelses- eller temanavn.

Du kan deaktivere en plugin helt eller selektivt fjerne enkeltfiler med CSS/JS i den. For nettsteder med komplekse URL-strukturer finnes det skriptdeaktivering via regulære uttrykk.

Tre scenarioer der Perfmatters gir umiddelbare gevinster:

• Plugin for sosiale medier (delingsknapper): deaktivert overalt unntatt i blogginnlegg
• Contact Form 7: deaktivert overalt unntatt på kontaktsiden
• Gutenberg blokkredigeringsstiler (block-library/style.min.css og theme.min.css): fjernet for nettsteder som bruker den klassiske editoren

I en uavhengig test på woorkup.com reduserte deaktivering av unødvendige skript via Perfmatters total lastetid med 20,2%, HTTP-forespørsler på hjemmesiden fra 46 til 30, og sidestørrelsen fra 506,3 KB til 451,6 KB.

Perfmatters er en betalt plugin, og det er berettiget for nettsteder der hastighet direkte påvirker konvertering. For en liten blogg holder Plugin Organizer eller en programmatisk mu-plugin.

Måling av resultater med nettverksmonitoren i nettleseren

Optimalisering uten måling er gjetting. Nettleserens DevTools gir deg et nøyaktig før-og-etter-bilde uten tredjepartstjenester. Enhver moderne nettleser fungerer:

• Chrome DevTools
• Firefox Dev Tools
• Microsoft Edge F12
• Safari Web Inspector

På en test-WordPress-installasjon med 18 aktive plugins målte vi sidehastighet før filtrering (tom cache, Firefox Network Monitor):

Resultat: 255,19 KB, lastetid 1,24 sekunder, 12 forespørsler.

Etter å ha installert Plugin Organizer og globalt deaktivert Contact Form 7, endret kakediagrammet seg:

Målinger: 104,21 KB, lastetid 0,80 sekunder, 8 forespørsler.

Til slutt deaktiverte vi alle ubrukte plugins:

Endelig resultat: 101,98 KB, lastetid 0,46 sekunder, 8 forespørsler.

Sammenligner vi ytterpunktene: ressursstørrelsen falt med mer enn halvparten (fra 255 til 102 KB), lastetiden gikk ned fra 1,24 til 0,46 sekunder, og HTTP-forespørsler falt fra 12 til 8. Tallene taler for seg selv: selektiv deaktivering av utvidelser gir merkbare hastighetsgevinster selv på et lite nettsted, og forringelse av TTFB og LCP påvirker søkerangeringer direkte.

⁉️🤔 Ofte stilte spørsmål

Er en mu-utvidelse obligatorisk, eller kan jeg legge koden i en vanlig utvidelse?

Du kan bruke en vanlig utvidelse, men lastrekkefølgen kan ødelegge alt. Hvis filteret ditt for option_active_plugins kjøres etter at WordPress allerede har lest listen over aktive utvidelser, vil det ikke fungere. En mu-utvidelse er den eneste måten å sikre at filteret ditt får kontroll før alle andre utvidelser. I en vanlig utvidelse er du avhengig av alfabetisk rekkefølge eller kroker som kan endres etter at en annen utvidelse oppdateres.

Hva om jeg ikke kan opprette mu-plugins-mappen på min hosting?

Du kan opprette mappen /wp-content/mu-plugins/ via FTP, vertskontrollpanelets filbehandler eller WP-CLI med kommandoen wp scaffold mu-plugin. Hvis du ikke har filsystemtilgang i det hele tatt, bruk Plugin Organizer: den gjør det samme gjennom sin egen filtreringsmekanisme og krever ikke redigering av serverfiler. De fleste vertsleverandører gir tilgang til wp-content via en filbehandler i kontrollpanelet. Mappetillatelser: 0755.

Vil deaktivering av en utvidelse via filteret påvirke innstillingene dens?

Nei, utvidelsesinnstillinger lagres i databasen (tabellen wp_options) og forblir urørte. Du forhindrer ganske enkelt WordPress fra å laste utvidelsens kode når en spesifikk forespørsel behandles. Alle innstillinger forblir på plass, og ved neste forespørsel der utvidelsen ikke filtreres, lastes den med full funksjonalitet. Deaktivering via option_active_plugins blokkerer spesifikt kodeinnlasting i farten, ikke deaktivering. I administrasjonsområdet forblir utvidelsen aktiv, innstillingene dens berøres ikke, og planlagte oppgaver (WP-Cron) fortsetter å fungere.

Hvordan bekrefter jeg at filteret faktisk fungerer?

Den mest visuelle metoden er Nettverk-panelet i Chrome DevTools (F12 → Nettverk). Åpne det på en side der utvidelsen skal være deaktivert, oppdater med Ctrl holdt nede (tøm hurtigbuffer), og søk etter utvidelsesnavnet eller dens CSS/JS-fil. Hvis det ikke er noen forespørsler, fungerer filteret. Utvidelser som Query Monitor viser også listen over lastede komponenter og deres kjøretid. For Contact Form 7, skriv contact-form-7 i Nettverk-søket; hvis filteret fungerte, vil du ikke se style.css eller scripts.js fra CF7 i listen over lastede ressurser.

Er det noe poeng i å deaktivere utvidelser på et veldig lite nettsted med bare 5-7 utvidelser?

Hvis alle 5 utvidelsene genuint trengs på hver side, nei. Men selv på et lite nettsted er det ofte et par utvidelser som bare fungerer på én side: et kontaktskjema, et porteføljegalleri, en forside-slider. Å deaktivere det paret på andre sider reduserer HTTP-forespørsler merkbart og øker lastehastigheten. Som vi så ovenfor på testinstallasjonen, kutter selv én filtrert utvidelse titalls millisekunder. For et nettsted med 1000+ daglige besøkende summeres disse millisekundene til en merkbar forskjell for både brukeren og Core Web Vitals.

Kode, utvidelse eller Perfmatters: hva du skal velge for din oppgave

Hvis nettstedet ditt har 5 utvidelser og alle genuint trengs på hver side, er ikke denne guiden for deg. Men et typisk WordPress-nettsted har 15-25 aktive utvidelser, hvorav bare 5-7 faktisk fungerer på en gitt side. Resten bruker bare servertid og senker lastingen.

En programmatisk mu-utvidelse er en gratis, lettvektig og fullt kontrollerbar tilnærming, men den krever oppmerksomhet ved hver ny utvidelse. Plugin Organizer er sweet spot-en: visuelt grensesnitt, fleksibilitet og gratis. Perfmatters er valget for kommersielle prosjekter der hvert tiendedels sekund i lastetid konverteres til penger.

Hvis du har akkumulert flere utvidelser enn du trenger, start med en revisjon og opprydding av ubrukte, og ta deretter kontroll over lasting for de som gjenstår. Velg tilnærming basert på komfortnivå og nettstedets belastning, så vil du se forskjellen i din aller første Nettverk-måling. Ikke vent på at utvidelser skal spise opp TTFB-en din.