
🚫 Så här inaktiverar du selektivt WordPress-tillägg på specifika sidor och inlägg
Varje WordPress-plugin lägger till PHP-kod som körs vid sidladdning, drar in skript och stilmallar och ibland gör extra databasfrågor. Ju fler plugin du har, desto tyngre blir dina sidor. Men problemet är inte bara antalet: även ett enda "pratsamt" plugin som Contact Form 7 laddar sina .css- och .js-filer på varenda sida som standard, inklusive sidor där inget formulär alls finns.
CF7-utvecklarna erkänner öppet att pluginet laddar resurser överallt eftersom shortcoden kan dyka upp var som helst. Den logiken är inte unik för CF7; de flesta plugin fungerar på samma sätt. Resultatet: din bloggs startsida laddar skript för ett bildspel som aldrig fanns där från början.
Den goda nyheten: WordPress låter dig selektivt stänga av plugin-laddning enbart på sidor där de faktiskt behövs. Vi går igenom båda tillvägagångssätten: programmatiskt (med ett mu-plugin och filtret option_active_plugins) och plugin-baserat (Plugin Organizer, Perfmatters, Plugin Load Filter). På slutet mäter vi resultaten med webbläsarens nätverksmonitor.
💡 Snabb översikt:
- Välj plugin utifrån tre kriterier: utvecklarens rykte, prestanda under belastning och faktiskt behov
- Programmatisk metod: skriv ett PHP-utdrag som använder
get_option('active_plugins')för att hämta listan över aktiva plugin och filtrerar dem efter sidans URL - Mu-plugin: placera filtret i
/wp-content/mu-plugins/så att det körs FÖRE alla vanliga plugin och inaktiverar onödiga i farten - Plugin-metod: Plugin Organizer och Perfmatters ger ett visuellt gränssnitt för samma uppgifter utan att du behöver skriva en enda rad kod
- Mät effekten med Chrome/Firefox DevTools: efter filtrering sjunker antalet HTTP-anrop och laddtiden minskar märkbart
Tre regler för att välja plugin
Innan du filtrerar plugin-laddning, se till att pluginarna på din webbplats faktiskt förtjänar en plats i wp_options. Tre regler som sparar dig huvudvärk och serverresurser.
Installera bara verifierade plugin från utvecklare med track record. Öppna plugin-sidan på WordPress.org och kontrollera: antal aktiva installationer, betyg, datum för senaste uppdatering och antal lösta supportärenden. Ett plugin med 100 000+ installationer, betyg 4,5+ och en uppdatering inom de senaste 3 månaderna är ett säkert val.

Föredra skalbara plugin. Två plugin med identisk funktionalitet kan påverka hastigheten olika. Jämför kandidater med webbläsarens inspector (Nätverk-fliken) eller onlinetjänster som Google PageSpeed Insights, Pingdom och GTmetrix; mät laddtid och antal HTTP-anrop före och efter installation.
Behåll inte dödvikt. Varje oanvänt plugin innebär extra PHP-kod i varje anrop. Gå regelbundet igenom din lista över aktiva plugin och ta bort dem din webbplats klarar sig utan. Om ett plugin "kan komma till användning om ett halvår", avaktivera och radera det, och installera sedan en ny version om ett halvår.
Verkligt exempel: Contact Form 7
Contact Form 7 är det perfekta testobjektet. Det lägger till på varje sida:
style.cssför formulärstilarscripts.jsför validerings- och inskickningslogik
Även om en sida inte har någon [contact-form-7]-shortcode laddas båda filerna troget. Skärmbilden nedan visar Chrome DevTools nätverkspanel, som inte ljuger:

Lösningen: antingen modifiera laddningslogiken inuti pluginet (vilket går sönder vid uppdatering) eller selektivt inaktivera pluginet för alla sidor utom den du behöver. Det andra tillvägagångssättet är mer tillförlitligt, så låt oss fokusera på det.
Steg 1. Hämta listan över aktiva plugin via PHP
Innan du filtrerar behöver du förstå var WordPress lagrar listan över aktiva plugin. De finns alla i tabellen wp_options, i raden med nyckeln active_plugins. Du kan hämta arrayen med en enda get_option-funktion.
Lägg till den här koden i pluginet Code Snippets eller i din egen plugin-fil (glöm inte plugin-huvudet högst upp):
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 } );
Spara filen som active-plugins.php och ladda upp den till /wp-content/plugins/. Skapa en testsida, infoga shortcoden [activeplugins], så får du en numrerad lista över alla aktiva tillägg i formatet folder/file.php.

Så här ser resultatet ut efter att du har infogat shortcoden på en sida:

Steg 2. Filtret option_active_plugins: ditt huvudverktyg
Nu till huvudverktyget: filtret option_active_plugins. Det tillhör filterfamiljen option_$option_name och körs varje gång WordPress hämtar ett optionsvärde från databasen. Eftersom aktiva tillägg lagras som inställningen active_plugins låter det här filtret dig modifiera arrayen i farten: ta bort oönskade tillägg eller lägga till nya.
Här är ett minimalt exempel som programmatiskt aktiverar Advanced Custom Fields (förutsatt att tillägget redan är installerat):
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 } );
Den här koden lägger till ACF i listan över aktiva tillägg på varje sida. Inte särskilt praktiskt, men principen är tydlig: du kan modifiera $plugins-arrayen hur du vill.
Viktigt att notera: filtret måste köras före vanliga tillägg, annars läser WordPress den ofiltrerade listan först. Det är vad mu-plugins är till för.
Steg 3. Skapa en mu-plugin för selektiv inaktivering
Must-use-plugins ligger i /wp-content/mu-plugins/ och körs före alla vanliga tillägg. Det är precis vad vi behöver: vårt filter får kontroll först.
Det finns en hake: WordPress villkorsfunktioner (is_page(), is_single() och andra) fungerar inte i mu-plugins eftersom förfrågan inte har tolkats än, så de returnerar alla false. Du måste analysera webbadressen manuellt via $_SERVER['REQUEST_URI'].
Här är en färdig mu-plugin som inaktiverar Contact Form 7 på alla sidor utom /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 }
Låt oss bryta ner den rad för rad:
parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH )extraherar sökvägen (till exempel/blog/kak-otkljuchit-plaginy/)strpos( $request_uri, '/wp-admin/' )kontrollerar om vi är i adminpanelen; i så fall tillämpas inte filtret, vilket gör att tilläggets inställningssidor förblir tillgängligaarray_search( $myplugin, $plugins )hittar CF7 i arrayen med aktiva tilläggunset( $plugins[ $k ] )tar bort tillägget från listan om vi INTE är på kontaktsidan
Spara filen, ladda upp den till /wp-content/mu-plugins/ och rensa cachen. Nu bör shortcoden [activeplugins] visa Contact Form 7 endast på sidan /contact/.
Så här ser samma princip ut för flera tillägg samtidigt. Istället för array_search med ett enskilt tillägg använder du en array och 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 }
Funktionen array_diff returnerar värden från den första arrayen som inte finns i den andra, precis vad du behöver för massinaktivering.
Resultatet syns direkt i Nätverkspanelen: Contact Form 7:s fil script.js försvinner från resurslistan på alla sidor utom kontaktsidan.

Den programmatiska metoden är flexibel men kräver kodändringar för varje nytt tillägg. För den som föredrar ett visuellt gränssnitt finns det färdiga filtertillägg.
Pluginbaserad metod: filtrering utan kod
Plugin Load Filter
Plugin Load Filter är ett gratisverktyg för att filtrera plugins utifrån flera villkor. Det stöder:
- filtrering efter innehållstyp (inlägg, sidor, anpassade innehållstyper)
- filtrering efter inläggsformat
- undantag för Jetpack-moduler
- URL-filtrering för REST API-, Heartbeat-, AJAX- och AMP-anrop

Inställningar för att aktivera filtret per sidtyp:

Efter aktivering konfigurerar administratören vilka sidor filtret gäller för via fliken "Filter Activation by Page Type". Minimalistiskt och rakt på sak.
Plugin Organizer
Plugin Organizer är en veteran bland filtreringsplugins med högsta betyg. Det ger dig full kontroll över inläsningen:
- selektiv inaktivering av plugins per sid-URL
- inaktivering per användarroll
- plugingrupper (aktivera/inaktivera en grupp på en gång)
- ändra inläsningsordning för plugins

På sidan "Global Plugins" kan du dra och släppa för att globalt inaktivera ett plugin för hela webbplatsen och selektivt återaktivera det på specifika sidor via en metabox i inläggsredigeraren. I skärmbilden nedan är Contact Form 7 globalt inaktiverat:

Och här är samma metabox på kontaktsidans redigeringsskärm, som åsidosätter globala inställningar:

Plugin Organizer visar även felsökningsinformation: vilka plugins som faktiskt laddades på varje sida och varför. Dokumentation finns på utvecklarens webbplats.
Perfmatters
Perfmatters är ett premiumverktyg från Kinstas utvecklingsteam. Dess huvudfunktion, Script Manager, grupperar alla skript och stilmallar efter plugin- eller temanamn.

Du kan inaktivera en plugin helt eller selektivt ta bort enskilda CSS/JS-filer i den. För sajter med komplexa URL-strukturer finns skriptinaktivering via reguljära uttryck.
Tre scenarier där Perfmatters ger omedelbara vinster:
- Sociala medier-plugins (delningsknappar): inaktiverade överallt utom på blogginlägg
- Contact Form 7: inaktiverad överallt utom på formulärsidan
- Gutenberg block editor-stilar (
block-library/style.min.cssochtheme.min.css): borttagna för sajter som använder den klassiska editorn
I ett oberoende test på woorkup.com minskade den totala laddningstiden med 20,2% genom att inaktivera onödiga skript via Perfmatters, HTTP-förfrågningarna på startsidan gick från 46 till 30, och sidstorleken från 506,3 KB till 451,6 KB.

Perfmatters är en betalplugin, och den är motiverad för sajter där hastighet direkt påverkar konvertering. För en liten blogg räcker Plugin Organizer eller en programmatisk mu-plugin.
Mäta resultat med webbläsarens nätverksmonitor
Optimering utan mätning är gissningsarbete. Webbläsarens DevTools ger dig en exakt före-och-efter-bild utan tredjepartstjänster. Vilken modern webbläsare som helst fungerar:
På en test-WordPress-installation med 18 aktiva plugins mätte vi sidhastigheten före filtrering (tom cache, Firefox nätverksmonitor):

Resultat: 255,19 KB, laddningstid 1,24 sekunder, 12 förfrågningar.
Efter att ha installerat Plugin Organizer och globalt inaktiverat Contact Form 7 ändrades cirkeldiagrammet:

Mätvärden: 104,21 KB, laddningstid 0,80 sekunder, 8 förfrågningar.
Slutligen inaktiverade vi alla oanvända plugins:

Slutresultat: 101,98 kB, laddtid 0,46 sekunder, 8 förfrågningar.
Om vi jämför ytterligheterna: resursstorleken minskade med mer än hälften (från 255 till 102 kB), laddtiden sjönk från 1,24 till 0,46 sekunder och HTTP-förfrågningarna minskade från 12 till 8. Siffrorna talar för sig själva: selektiv inaktivering av tillägg ger märkbara hastighetsvinster även på en liten sajt, och försämring av TTFB och LCP påverkar sökrankningen direkt.
⁉️🤔 Vanliga frågor
Är ett mu-tillägg obligatoriskt, eller kan jag lägga koden i ett vanligt tillägg?
Du kan använda ett vanligt tillägg, men laddningsordningen kan förstöra allt. Om ditt
option_active_plugins-filter körs efter att WordPress redan har läst listan över aktiva tillägg fungerar det inte. Ett mu-tillägg är det enda sättet att garantera att ditt filter får kontroll före alla andra tillägg. I ett vanligt tillägg är du beroende av alfabetisk ordning eller krokar som kan ändras efter att något annat tillägg uppdateras.
Vad gör jag om jag inte kan skapa mappen mu-plugins på mitt webbhotell?
Du kan skapa mappen
/wp-content/mu-plugins/via FTP, webbhotellets filhanterare eller WP-CLI med kommandotwp scaffold mu-plugin. Om du inte har någon filsystemåtkomst alls, använd Plugin Organizer: det gör samma sak genom sin egen filtreringsmekanism och kräver inte att du redigerar serverfiler. De flesta webbhotell ger åtkomst till wp-content via en filhanterare i kontrollpanelen. Mapprättigheter: 0755.
Påverkar det tilläggets inställningar om jag inaktiverar det via filtret?
Nej, tilläggets inställningar lagras i databasen (tabellen
wp_options) och förblir orörda. Du hindrar helt enkelt WordPress från att ladda tilläggets kod när en specifik förfrågan behandlas. Alla inställningar ligger kvar, och vid nästa förfrågan där tillägget inte filtreras laddas det med full funktionalitet. Inaktivering viaoption_active_pluginsblockerar specifikt kodladdning i farten, inte avaktivering. I adminområdet förblir tillägget aktivt, dess inställningar rörs inte och schemalagda uppgifter (WP-Cron) fortsätter att fungera.
Hur verifierar jag att filtret faktiskt fungerar?
Den mest visuella metoden är Nätverk-panelen i Chrome DevTools (F12 → Nätverk). Öppna den på en sida där tillägget ska vara inaktiverat, uppdatera med Ctrl nedtryckt (töm cache) och sök efter tilläggets namn eller dess CSS/JS-fil. Om det inte finns några förfrågningar fungerar filtret. Tillägg som Query Monitor visar också listan över laddade komponenter och deras exekveringstid. För Contact Form 7, skriv
contact-form-7i nätverkssökningen; om filtret fungerade ser du intestyle.cssellerscripts.jsfrån CF7 i listan över laddade resurser.
Finns det någon poäng med att inaktivera tillägg på en mycket liten sajt med bara 5-7 tillägg?
Om alla 5 tillägg verkligen behövs på varje sida, nej. Men även på en liten sajt finns det ofta ett par tillägg som bara fungerar på en sida: ett kontaktformulär, ett portföljgalleri, en startsideslider. Att inaktivera det paret på andra sidor minskar HTTP-förfrågningarna märkbart och snabbar upp laddningen. Som vi såg ovan på testinstallationen, kapar även ett enda filtrerat tillägg tiotals millisekunder. För en sajt med 1 000+ dagliga besökare blir de millisekunderna en märkbar skillnad för både användaren och Core Web Vitals.
Kod, tillägg eller Perfmatters: vad ska du välja för din uppgift
Om din sajt har 5 tillägg och alla verkligen behövs på varje sida är den här guiden inte för dig. Men en typisk WordPress-sajt drar in 15-25 aktiva tillägg, varav endast 5-7 faktiskt arbetar på en given sida. Resten förbrukar bara servertid och saktar ner laddningen.
Ett programmatiskt mu-tillägg är en gratis, lättviktig och fullt kontrollerbar metod, men den kräver uppmärksamhet vid varje nytt tillägg. Plugin Organizer är den gyllene medelvägen: visuellt gränssnitt, flexibilitet och gratis. Perfmatters är valet för kommersiella projekt där varje tiondels sekund i laddtid omvandlas till pengar.
Om du har samlat på dig fler tillägg än du behöver, börja med en granskning och rensning av oanvända, och ta sedan kontroll över laddningen för de som återstår. Välj din metod baserat på bekvämlighetsnivå och sajtbelastning, så ser du skillnaden i din allra första nätverksmätning. Vänta inte på att tilläggen ska äta upp din TTFB.



