Slik fjerner du WordPress-bloat uten risiko

WordPress er et kraftsenter, men “én størrelse passer alle”-standardene betyr at det ofte leveres med bagasje som de fleste moderne prosjekter ikke trenger. Gjennom årene har jeg finjustert et spesifikt sett med kodesnutter for å fjerne overflødig “fett” uten å gå på bekostning av kjerneopplevelsen.

Denne guiden er ikke bare en liste over ting du kan slette; det er en strategisk tilnærming til ytelse. Den er inspirert av Terence Edens utmerkede liste, som jeg har paret med mine egne produksjonstestede løsninger. Hvert hook-navn nedenfor er kontrollert mot kildekoden til WordPress 7.1.3 (gjeldende versjon 12. oktober 2026, ifølge versjonssjekken på api.wordpress.org), og kodesnuttene som viste seg å være utdaterte, feil eller skadelige, er merket som det. Vil du heller overlate jobben til andre, se våre tjenester innen WordPress-utvikling.

#Hvorfor fjerne last i WordPress

Hvorfor bry seg om noen få små skript? Fordi de summerer seg opp. Hver unødvendige linje er en potensiell konflikt, en liten rendering-forsinkelse eller en bortkastet byte.

Hva vi målretter:

• DOM-størrelse, Fjerning av ubrukte inline-stiler.
• HTTP-overhead, Dequeuing av skript som ikke burde være der.
• Sikkerhetsflate, Deaktivering av utdaterte protokoller som XML-RPC.
• Core Web Vitals, Direkte påvirkning på LCP og CLS ved å fjerne elementer som blokkerer renderingen.

[!IMPORTANT] Vær forsiktig: Ikke alt som kalles “bloat” er ubrukelig. Hvis du er avhengig av de spesifikke stilene i den klassiske editoren eller av innebygde emojier for eldre nettlesere, kan det hende at noen av disse fiksene ikke passer for deg. Test alltid i et testmiljø først.

#Hvordan kjøre et komplett WordPress-optimaliseringsskript

Legg til følgende i temaets functions.php-fil, eller helst i en mu-plugin (se siste seksjon) slik at koden overlever et temabytte. Hver seksjon er kommentert med forklaringer og kildelenker.

#1. Fjern classic theme styles

WordPress legger til “classic-theme-styles” i temaer som ikke har en theme.json-fil. Kjernen legger den bare i køen når wp_theme_has_theme_json() returnerer false, så et blokktema eller et klassisk tema med theme.json laster den aldri. Hvis ditt tema gjør det, fjern den:

//  Fjern obligatorisk classic theme.
function disable_classic_theme_styles() {
    wp_deregister_style( "classic-theme-styles" );
    wp_dequeue_style(    "classic-theme-styles" );
}
add_action( "wp_enqueue_scripts", "disable_classic_theme_styles" );

#2. Fjern emoji-støtte

WordPress skriver ut et lite deteksjonsskript, og bare når nettleseren ikke kan vise nyere emojier, laster den et større skript som bytter ut emoji-tegn med SVG-bilder. Hvis publikummet ditt bruker oppdaterte nettlesere, er dette unødvendig:

//  Fjern WP Emoji.
//  https://www.denisbouquet.com/remove-wordpress-emoji-code/
remove_action( "wp_head",             "print_emoji_detection_script", 7 );
remove_action( "wp_print_styles",     "print_emoji_styles"              );
remove_action( "admin_print_scripts", "print_emoji_detection_script"    );
remove_action( "admin_print_styles",  "print_emoji_styles"              );
//  Tøm SVG-basis-URL-en som sendes til emoji-innstillingene.
add_filter( "emoji_svg_url", "__return_false" );

//  Stopp emoji-erstatning med bilder i RSS / Atom Feeds
//  https://danq.me/2023/09/04/wordpress-stop-emoji-images/
remove_filter( "the_content_feed", "wp_staticize_emoji" );
remove_filter( "comment_text_rss", "wp_staticize_emoji" );

#3. Deaktiver automatisk tekstformatering

WordPress “teksturiserer” innholdet: rette anførselstegn blir typografiske, og ASCII -- / --- blir lange tankestreker (U+2013 / U+2014). Det ødelegger kodeeksempler og bryter en ASCII-bindestrek-policy (- eller --, ingen lange strek-glyfer i kilden). Slå det av på teknisk innhold:

//  Fjern automatisk formatering.
//  https://css-tricks.com/snippets/wordpress/disable-automatic-formatting/
remove_filter( "the_content",  "wptexturize" );
remove_filter( "the_excerpt",  "wptexturize" );
remove_filter( "comment_text", "wptexturize" );
remove_filter( "the_title",    "wptexturize" );

//  Flere formateringsfiltre.
add_action("init", function() {
    remove_filter( "the_content", "convert_smilies", 20 );
    foreach ( array( "the_content", "the_title", "wp_title", "document_title" ) as $filter ) {
        remove_filter( $filter, "capital_P_dangit", 11 );
    }
    remove_filter( "comment_text", "capital_P_dangit", 31 );
    //  KUN for nettsteder med klassisk editor: denne linjen stopper all blokkrendering.
    remove_filter( "the_content",  "do_blocks", 9 );
}, 11);

Merk: Filteret capital_P_dangit er WordPress’ måte å autokorrigere Wordpress (med liten p) til WordPress. Det er aggressivt og noen ganger uønsket.

[!WARNING] Når do_blocks fjernes fra the_content, blir blokkmarkup ikke lenger tolket. Dynamiske blokker (query loop, siste innlegg, navigasjon) viser ingenting. Behold den linjen bare på et nettsted der alle innleggene er skrevet i den klassiske editoren.

#4. Fjern Gutenberg-stiler og -skript

Hvis du bruker et egendefinert tema og ikke er avhengig av Gutenbergs frontend-stiler, fjern dem. På et blokktema skal du ikke gjøre det: de globale stilene bærer hele designet fra theme.json.

//  Fjern Gutenberg Styles.
//  https://wordpress.org/support/topic/how-to-disable-inline-styling-style-idglobal-styles-inline-css/
remove_action( "wp_enqueue_scripts", "wp_enqueue_global_styles" );
//  Kjernen kobler den også til wp_footer med prioritet 1 for klassiske temaer.
remove_action( "wp_footer", "wp_enqueue_global_styles", 1 );

//  Fjern Gutenberg redigeringswidgets.
//  Fra https://wordpress.org/plugins/classic-widgets/
//  Hindrer blokkeditoren i å styre widgets i Gutenberg-utvidelsen.
add_filter( "gutenberg_use_widgets_block_editor", "__return_false" );
//  Hindrer blokkeditoren i å styre widgets.
add_filter( "use_widgets_block_editor", "__return_false" );

//  Fjern Gutenberg Block Library CSS fra lasting på frontend.
//  https://smartwp.com/remove-gutenberg-css/
function remove_wp_block_library_css() {
    wp_dequeue_style( "wp-block-library"       );
    wp_dequeue_style( "wp-block-library-theme" );
}
add_action( "wp_enqueue_scripts", "remove_wp_block_library_css", 100 );

#5. Fjern header meta tags

Rydd opp i <head>-seksjonen din ved å fjerne unødvendige meta-tagger:

//  Fjern shortlink.
//  https://stackoverflow.com/questions/42444063/disable-wordpress-short-links
remove_action( "wp_head", "wp_shortlink_wp_head" );

//  Fjern RSD.
//  https://wpengineer.com/1438/wordpress-header/
remove_action( "wp_head", "rsd_link" );

//  Fjern ekstra feed-lenker.
//  https://developer.wordpress.org/reference/functions/feed_links/
add_filter( "feed_links_show_comments_feed", "__return_false" );
add_filter( "feed_links_show_posts_feed",    "__return_false" );

//  Fjern api.w.org-lenke.
//  https://wordpress.stackexchange.com/questions/211467/remove-json-api-links-in-header-html
remove_action( "wp_head", "rest_output_link_wp_head" );
//  https://wordpress.stackexchange.com/questions/211817/how-to-remove-rest-api-link-in-http-headers
//  https://developer.wordpress.org/reference/functions/rest_output_link_header/
remove_action( "template_redirect", "rest_output_link_header", 11, 0 );

#6. Fjern bildeforbedringer

WordPress legger til attributtene srcset, sizes, loading, decoding og fetchpriority på bilder. Hvis du håndterer disse selv, fjern dem, men les bildeseksjonen lenger ned først, for disse attributtene beskytter LCP og CLS:

//  Fjern WordPress tvungen bildestørrelse
//  https://core.trac.wordpress.org/ticket/62413#comment:40
add_filter( "wp_img_tag_add_auto_sizes", "__return_false" );

//  Fjern <img>-forbedringer
//  https://developer.wordpress.org/reference/functions/wp_filter_content_tags/
remove_filter( "the_content",  "wp_filter_content_tags", 12 );

//  Stopp omskriving av http:// URLer for hoveddomenet.
//  https://developer.wordpress.org/reference/hooks/wp_should_replace_insecure_home_url/
remove_filter( "the_content", "wp_replace_insecure_home_url", 10 );

//  Fjern attachment-ting
//  https://developer.wordpress.org/news/2024/01/building-dynamic-block-based-attachment-templates-in-themes/
remove_filter( "the_content", "prepend_attachment" );

//  Fjern blokkfilter
remove_filter( "the_content", "apply_block_hooks_to_content_from_post_object", 8 );

#7. Fjern nettlesersjekk og andre admin-funksjoner

//  Fjern nettlesersjekk fra Admin-dashbordet.
//  https://core.trac.wordpress.org/attachment/ticket/27626/disable-wp-check-browser-version.0.2.php
if ( !empty( $_SERVER["HTTP_USER_AGENT"] ) ) {
    add_filter( "pre_site_transient_browser_" . md5( $_SERVER["HTTP_USER_AGENT"] ), "__return_null" );
}

//  Fjern hovercards på kommentarlenker i admin-området.
//  https://wordpress.org/support/topic/how-to-disable-mshots-service/#post-12946617
add_filter( "akismet_enable_mshots", "__return_false" );

#Hva mer bør du fjerne fra WordPress

Utover teknikkene ovenfor, her er mine egne løsninger for ytterligere optimalisering:

#8. Deaktiver XML-RPC

Hvis du ikke bruker eksterne apper til å poste til WordPress, slå av XML-RPC-metodene som krever innlogging, og pingback-metodene sammen med dem. Filteret xmlrpc_enabled alene slår ikke av endepunktet (detaljer nedenfor):

// Deaktiver XML-RPC-metoder som krever autentisering
add_filter( 'xmlrpc_enabled', '__return_false' );

// Fjern pingback-metodene, som ellers forblir åpne
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

// Fjern XML-RPC-lenke fra head
remove_action( 'wp_head', 'rsd_link' );

#9. Fjern jQuery Migrate

Moderne WordPress-temaer og -plugins trenger sjelden jQuery Migrate. Hvis nettstedet ditt fungerer uten det, fjern det:

function remove_jquery_migrate( $scripts ) {
    if ( ! is_admin() && isset( $scripts->registered['jquery'] ) ) {
        $script = $scripts->registered['jquery'];
        if ( $script->deps ) {
            $script->deps = array_diff( $script->deps, array( 'jquery-migrate' ) );
        }
    }
}
add_action( 'wp_default_scripts', 'remove_jquery_migrate' );

#10. Deaktiver oEmbed

Hvis ingen andre nettsteder trenger å bygge inn innleggene dine, slå av leverandørsiden av oEmbed. Innbygging av YouTube og andre registrerte leverandører i dine egne innlegg fungerer fortsatt, fordi WordPress bare kjører oppdagelse for URL-er som ikke står på den innebygde leverandørlisten:

// Fjern oEmbed-oppdagelseslenker
remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
remove_action( 'wp_head', 'wp_oembed_add_host_js' );

// Fjern oEmbed REST API-endepunkt
remove_action( 'rest_api_init', 'wp_oembed_register_route' );

// Deaktiver oEmbed auto-oppdagelse
add_filter( 'embed_oembed_discover', '__return_false' );

#11. Utsett JavaScript-lasting

Legg til defer på ikke-kritiske skript for bedre ytelse. Filteret nedenfor er den gamle metoden og ignorerer avhengighetsreglene som kjernen har brukt siden WordPress 6.3; seksjonen om lastestrategi lenger ned viser den støttede måten:

function add_defer_attribute( $tag, $handle ) {
    // Skript som IKKE skal utsettes
    $scripts_to_not_defer = array( 'jquery-core' );

    if ( in_array( $handle, $scripts_to_not_defer ) || str_contains( $tag, ' defer' ) ) {
        return $tag;
    }

    return str_replace( ' src', ' defer src', $tag );
}
add_filter( 'script_loader_tag', 'add_defer_attribute', 10, 2 );

#Hvordan måle effekten av å slanke WordPress

Etter å ha implementert disse endringene, test nettstedet ditt med:

1. Google PageSpeed Insights, Sjekk dine Core Web Vitals
2. GTmetrix, Detaljert waterfall-analyse
3. WebPageTest, Flere testlokasjoner og tilkoblingshastigheter

Du bør se:

• Redusert sidestørrelse (færre CSS/JS-bytes)
• Færre HTTP-forespørsler
• Bedre Largest Contentful Paint (LCP) når en fjernet ressurs blokkerte renderingen

Serverens responstid (TTFB) flytter seg knapt, fordi ingen av disse kodesnuttene endrer hvordan PHP bygger siden. Det er et hurtigbufferlag som flytter TTFB.

#Hva en standardinstallasjon av WordPress 7.1 laster

Før du fjerner noe, er det nyttig å vite hva hver funksjon koster. Størrelsene nedenfor er målt på filene i den offisielle wordpress-7.1.3.zip: rå byte på disk og størrelsen etter gzip på nivå 9, som ligger nær det en server sender over nettet.

To tall skiller seg ut. jQuery pluss Migrate er det tyngste et klassisk tema vanligvis leverer, så å kutte jQuery fra din egen temakode sparer mer enn alle justeringene av head-tagger til sammen. Og stilarket på 140 KB for blokkbiblioteket lastes ikke lenger i sin helhet på en standardinstallasjon: blokktemaer har siden WordPress 5.9 bare lastet stilene til blokkene som finnes på siden, og siden 6.9 slår kjernen på den samme lastingen ved behov for klassiske temaer gjennom wp_load_classic_theme_block_styles_on_demand(), så lenge utdatabufferen for malen er aktiv. Et tema reserverer seg ved å returnere false fra filtrene should_load_separate_core_block_assets og should_load_block_assets_on_demand.

For å se hva en bestemt side faktisk laster, bruk nettleseren. Åpne Network-fanen i Chrome DevTools, last inn på nytt med hurtigbufferen slått av, filtrer på ditt eget domene og sorter etter størrelse. Lighthouse i det samme DevTools-panelet viser ubrukt CSS og JavaScript per fil. WP-CLI hjelper ikke her: et wp eval-kall rendrer aldri en mal, så skript- og stilkøene det skriver ut, er tomme. En footer-hook som logger, fungerer:

// Logg hver handle i køen ved visning av frontend-sider (kun staging).
add_action( 'wp_footer', function () {
    if ( is_admin() ) {
        return;
    }
    foreach ( wp_scripts()->queue as $handle ) {
        error_log( 'script: ' . $handle . ' ' . wp_scripts()->registered[ $handle ]->src );
    }
    foreach ( wp_styles()->queue as $handle ) {
        error_log( 'style: ' . $handle . ' ' . wp_styles()->registered[ $handle ]->src );
    }
}, 999 );

#Hvilke WordPress-funksjoner du bør slå av, funksjon for funksjon

Skriptet ovenfor er hurtigversjonen. Nedenfor får hver funksjon den sammenhengen du trenger for å avgjøre om den hører hjemme på nettstedet ditt.

#Hva classic theme styles er og hva de koster

WordPress 6.1 la til et lite stilark som gir klassiske temaer fornuftige standarder for blokkmarkup, for eksempel avstand for knapp- og filblokker. Det veier 291 byte og legges i køen av wp_enqueue_classic_theme_styles() bare når det aktive temaet ikke har theme.json. Fjern det på et klassisk tema med egen blokk-CSS. La det stå på klassiske temaer som er avhengige av at kjernens blokkmarkup ser riktig ut uten ekstra arbeid, og ikke bry deg om det på blokktemaer, der det aldri lastes.

#Hvorfor WordPress laster et emoji-skript

Emoji-funksjonen gjør to jobber: den tester om nettleseren kan tegne nyere emojier, og hvis den ikke kan det, laster den wp-emoji-release.min.js for å erstatte tegnene med bilder fra s.w.org. I WordPress 7.1.3 er testen et inline type="module"-skript som skrives ut i footeren, så det blokkerer ikke lenger renderingen, og resultatene mellomlagres i sessionStorage. Et lite inline-stilark for img.emoji følger med. Å fjerne wp_print_styles-handlingen virker fortsatt: wp_enqueue_emoji_styles() sjekker etter den handlingen og hopper over inline-CSS-en når den er borte.

Filteret emoji_svg_url setter nå bare SVG-basis-URL-en i emoji-innstillingene. Eldre guider brukte det til å fjerne en DNS-prefetch til s.w.org; wp_resource_hints() i 7.1.3 legger ikke lenger til det hintet, så linjen er ufarlig, men sparer ikke lenger et oppslag. Behold emoji-støtten hvis besøkende skriver i kommentarer eller forum fra gamle enheter der skriftene mangler nyere emojier. Den komplette versjonen dekker også e-post og den klassiske editoren:

function disable_emojis_completely() {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
    remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
    remove_action( 'admin_print_styles', 'print_emoji_styles' );
    remove_action( 'embed_head', 'print_emoji_detection_script' );
    remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
    remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
    remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
    add_filter( 'tiny_mce_plugins', function ( $plugins ) {
        return array_diff( $plugins, array( 'wpemoji' ) );
    } );
}
add_action( 'init', 'disable_emojis_completely' );

#Hva wptexturize endrer i innholdet ditt

wptexturize() gjør rette anførselstegn om til typografiske, -- og --- til tankestrek og lang tankestrek, og tre punktum til et ellipsetegn. På teknisk innhold ødelegger den kortkoder, HTML- og PHP-fragmenter som leserne kopierer. Hele funksjonen kan slås av med ett filter i stedet for å fjerne den fra hver hook:

add_filter( 'run_wptexturize', '__return_false' );

Behold den bare på redaksjonelle nettsteder som vil ha typografiske anførselstegn og aldri publiserer kode.

#Hva capital_P_dangit-filteret gjør

capital_P_dangit() erstatter Wordpress med WordPress. I titler erstatter den hver forekomst; i innhold og kommentarer bare etter et mellomrom, et anførselstegn, > eller (. Den rører ikke URL-er, fordi en skråstrek foran ordet ikke gir treff. Den reelle risikoen er kode: et eksempel som inneholder Wordpress etter et mellomrom, blir endret uten at du merker det.

#Hvilke stiler og skript blokkeditoren legger til

På frontend bidrar blokkeditoren med wp-block-library (blokk-CSS-en), wp-block-library-theme (meningsbærende temastiler) og de inline global-styles som genereres fra theme.json. wp-components hører til editorskjermene, så å fjerne den fra køen på frontend gjør ingenting. Eldre kodesnutter fjerner også wp_global_styles_render_svg_filters fra wp_body_open; den funksjonen ble avviklet i 6.3.0 og er ikke lenger koblet til. Fjern blokk-CSS bare på nettsteder som ikke rendrer blokker på frontend. På et blokktema fjerner du temaets design når du fjerner de globale stilene.

#Hvilke head-tagger WordPress legger til, og hvilke du bør fjerne

En standard wp_head i 7.1.3 skriver blant annet ut:

<meta name="generator" content="WordPress 7.1.3" />
<link rel="shortlink" href="https://example.com/?p=123" />
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://example.com/xmlrpc.php?rsd" />
<link rel="https://api.w.org/" href="https://example.com/wp-json/" />
<link rel="alternate" type="application/json" href="https://example.com/wp-json/wp/v2/posts/123" />

To fjerninger som fortsatt dukker opp i mange guider, gjør ingenting på nåværende versjoner: wlwmanifest_link ble avviklet i 6.3.0 og skrives ikke lenger ut, og adjacent_posts_rel_link_wp_head har ikke vært brukt av kjernen siden 5.6.0. En oppdatert opprydding er kortere:

add_action( 'init', function () {
    remove_action( 'wp_head', 'wp_generator' );
    remove_action( 'wp_head', 'wp_shortlink_wp_head' );
    remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
    remove_action( 'wp_head', 'rsd_link' );
} );

#Hva WordPress legger til på bilder

wp_filter_content_tags() legger til srcset og sizes, width og height der de mangler, loading="lazy" på bilder under folden, samt decoding="async" og fetchpriority="high" på det sannsynlige LCP-bildet. Filteret wp_img_tag_add_auto_sizes kom i 6.7.0, ikke tidligere. Å fjerne disse funksjonene gjør som regel CLS og LCP dårligere, altså det motsatte av målet, så gjør det bare når et CDN eller din egen markup setter alle sammen. For å slå av bare lazy loading:

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

#Hvordan nettlesersjekken i dashbordet fungerer

wp_check_browser_version() spør api.wordpress.org om administratorens nettleser er utdatert, og mellomlagrer svaret som en site transient i én uke, med en MD5 av brukeragenten som nøkkel. Det er én ekstern forespørsel per nettleser per uke, ikke én per visning av en adminside. PHP-versjonssjekken fungerer på samme måte, men transient-nøkkelen er php_check_ pluss en MD5 av PHP_VERSION, ikke av brukeragenten, så kodesnutter som filtrerer pre_site_transient_phpcompat_, gjør ingenting:

add_filter( 'pre_site_transient_php_check_' . md5( PHP_VERSION ), '__return_null' );

Behold den sjekken med mindre noen andre overvåker PHP-versjonen, for det er advarselen som forteller nettstedseiere at PHP-versjonen deres ikke lenger har støtte.

#Hva xmlrpc_enabled-filteret egentlig slår av

XML-RPC er protokollen for ekstern publisering bak eldre mobilklienter, skrivebordseditorer og pingbacks. Filternavnet antyder en hovedbryter, men kildekoden til WordPress 7.1.3 sier noe annet i docblocken til wp_xmlrpc_server::set_is_enabled():

“I motsetning til det navnet antyder, styrer ikke dette filteret om XML-RPC er fullt aktivert; det styrer bare om XML-RPC-metoder som krever autentisering, for eksempel til publisering, er aktivert.”

WordPress 7.1.3, docblocken til wp_xmlrpc_server::set_is_enabled() i class-wp-xmlrpc-server.php (egen oversettelse)

Etter add_filter( 'xmlrpc_enabled', '__return_false' ) svarer altså xmlrpc.php fortsatt, og pingback.ping virker fortsatt. Pingbacks er delen som misbrukes til reflektert trafikk, og system.multicall lar én forespørsel bære mange innloggingsforsøk, noe filteret faktisk stopper fordi de metodene krever autentisering. Kodesnutten i seksjon 8 fjerner i tillegg pingback-metodene gjennom xmlrpc_methods. HTTP-headeren X-Pingback sendes bare på enkeltinnlegg som tillater pings, så når du stenger pings (se seksjonene nedenfor), forsvinner den også. For å ta endepunktet helt ned, avvis xmlrpc.php på webserveren; sjekk deretter alle utvidelser og apper som publiserer eksternt, for de slutter å virke.

#Hva jQuery Migrate brukes til

jQuery Migrate gjenoppretter jQuery-API-er som ble fjernet i senere jQuery-versjoner, og logger advarsler når gammel kode kaller dem. WordPress registrerer jquery-handlen som et alias for jquery-core pluss jquery-migrate, og det er derfor kodesnutten i seksjon 9 endrer avhengighetslisten i stedet for å fjerne en fil fra køen. Før du fjerner det i produksjon, last nettstedet på staging med define( 'SCRIPT_DEBUG', true );, som får WordPress til å levere den uminifiserte jquery-migrate.js som kjernen beholder for feilsøking, og les konsollen etter JQMIGRATE-advarsler om avviklede kall. Ikke kall wp_deregister_script( 'jquery-migrate' ) på frontend; enhver utvidelse som oppgir jquery-migrate som avhengighet, mister da sitt eget skript, fordi WordPress ikke skriver ut et skript når en avhengighet mangler.

#Hvordan oEmbed fungerer i WordPress

oEmbed har to sider. Som forbruker gjør WordPress en innlimt YouTube- eller Vimeo-lenke om til en spiller ved hjelp av den innebygde leverandørlisten; det fortsetter å virke etter kodesnutten i seksjon 10. Som leverandør skriver nettstedet ditt ut oppdagelseslenker og leverer /wp-json/oembed/1.0/embed, slik at andre WordPress-nettsteder kan bygge inn innleggene dine. Skriptet wp-embed (710 byte gzippet) legges bare i køen på sider som inneholder en slik innleggsinnbygging. To linjer som dukker opp i eldre kode for å “slå av embeds”, bør ikke kopieres: å fjerne wp_filter_oembed_result fra oembed_dataparse slår av renselsen som kjernen bruker på HTML fra leverandører som ikke står på den klarerte listen, og TinyMCE-utvidelsen wpembed finnes ikke lenger, så å filtrere den ut av tiny_mce_plugins gjør ingenting.

#Hvordan begrense REST API uten å ødelegge blokkeditoren

REST API svarer på /wp-json/ og er det blokkeditoren, nettstedseditoren og mange utvidelser bruker. Den offisielle håndboken for REST API er tydelig i sine ofte stilte spørsmål:

“Du bør ikke deaktivere REST API; det vil ødelegge funksjonalitet i WordPress-administrasjonen som er avhengig av at API-et er aktivt.”

WordPress REST API Handbook, Frequently Asked Questions (egen oversettelse)

Det håndboken tilbyr i stedet, er å kreve autentisering gjennom filteret rest_authentication_errors. Innloggede redaktører kan fortsatt jobbe, mens anonyme forespørsler får 401:

add_filter( 'rest_authentication_errors', function( $result ) {
    // Hvis en tidligere autentiseringssjekk er brukt,
    // send resultatet videre uendret.
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

    // Ingen autentisering er utført ennå.
    // Returner en feil hvis brukeren ikke er logget inn.
    if ( ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_not_logged_in',
            __( 'You are not currently logged in.' ),
            array( 'status' => 401 )
        );
    }

    // Vår egen autentiseringssjekk skal ikke påvirke
    // forespørsler fra innloggede brukere
    return $result;
});

Dette ødelegger alle frontend-funksjoner som kaller /wp-json/ for anonyme besøkende: skjemaer som sendes via REST, søke- eller filterwidgets som henter JSON, en headless frontend, og andre nettsteder som bygger inn innleggene dine gjennom oEmbed-endepunktet. Et smalere alternativ er å skjule enkeltruter med filteret rest_endpoints, for eksempel brukerendepunktet som lister forfatternes slugs. Test alle skjemaer og interaktive blokker mens du er logget ut etter endringen.

#Hvordan justere Heartbeat API i WordPress

Heartbeat er en pollingløkke i heartbeat.js som sender en forespørsel til admin-ajax.php med et fast intervall. Den håndterer innleggslåsing (meldingen om at noen andre redigerer), autolagringsdata i den klassiske editoren og kontrollen av utløpt innlogging som viser dialogen for ny innlogging. I WordPress 7.1.3 er standardverdien for mainInterval 60 sekunder, det tillatte området er 1 til 3 600 sekunder, løkken kan midlertidig øke farten til 5 sekunder, og den senker farten til 120 sekunder når fanen er skjult. Å sette intervallet til 60 endrer derfor ingenting; et langsommere intervall er den nyttige justeringen for travle adminteam eller svak hosting:

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 120;
    return $settings;
} );

På frontend laster ikke kjernen Heartbeat for besøkende; det dukker bare opp når en utvidelse legger det i køen. Å avregistrere det der er trygt hvis du sjekker den utvidelsens funksjon etterpå. Avregistrer det aldri i admin: innleggslåser og advarsler om utløpt økt er avhengige av det.

#Hvordan begrense innleggsrevisjoner med WP_POST_REVISIONS

Revisjoner gjør ikke frontend tregere, fordi de aldri hentes på offentlige sider. De får tabellen wp_posts til å vokse og gjør sikkerhetskopier og eksporter tregere. Styringen er en konstant i wp-config.php, som leses av wp_revisions_to_keep():

define( 'WP_POST_REVISIONS', 10 );   // behold de 10 nyeste revisjonene per innlegg
// define( 'WP_POST_REVISIONS', false ); // ingen revisjoner i det hele tatt

Standardverdien er true, som betyr ubegrenset. false eller 0 slår av revisjoner; et positivt tall beholder så mange. Filteret wp_revisions_to_keep overstyrer konstanten, og siden WordPress 5.8 setter filteret wp_{$post_type}_revisions_to_keep en grense per innleggstype. Grensen gjelder neste gang et innlegg lagres, så eksisterende ekstra revisjoner blir liggende til da. Å slå av revisjoner fjerner sikkerhetsnettet for redaktørene, så et lite tall er vanligvis den bedre avveiningen.

Autolagring har sin egen konstant. Det finnes ikke noe autosave_interval-filter i kjernen, så kode som legger til et slikt, gjør ingenting; sett heller intervallet i sekunder i wp-config.php:

define( 'AUTOSAVE_INTERVAL', 120 ); // standard er 60

#Hvordan slå av kommentarer på hele nettstedet

Et nettsted uten kommentarer rendrer fortsatt kommentarskjemaer der temaet ber om dem, beholder lenken til kommentarfeeden i head og beholder pingback-maskineriet. Å stenge kommentarer og pings med filtre dekker alle innleggstyper uten at du må redigere innlegg i databasen:

add_filter( 'comments_open', '__return_false', 20, 2 );
add_filter( 'pings_open', '__return_false', 20, 2 );
add_filter( 'feed_links_show_comments_feed', '__return_false' );

add_action( 'admin_menu', function () {
    remove_menu_page( 'edit-comments.php' );
} );
add_action( 'init', function () {
    remove_post_type_support( 'post', 'comments' );
    remove_post_type_support( 'page', 'comments' );
} );

Når du stenger pings, fjernes også headeren X-Pingback, siden kjernen bare sender den når pings_open() er true. Eksisterende kommentarer blir liggende i databasen og kan fortsatt vises hvis temaet skriver dem ut uansett comments_open(). Skriptet comment-reply er ikke verdt eget arbeid: kjernen registrerer det med async-strategien og lav hentingsprioritet, og det er på 1 371 byte gzippet.

#Hvordan utsette skript med API-et for lastestrategi

Siden WordPress 6.3 godtar wp_register_script() og wp_enqueue_script() et strategy-argument med verdiene defer eller async. Kjernen sjekker da avhengighetstreet før attributtet skrives ut: et skript med et inline-skript koblet til i after-posisjonen blir aldri forsinket, og et defer-skript faller tilbake til blokkerende lasting når et avhengig skript trenger at det kjører først. Den logikken ligger i WP_Scripts::get_eligible_loading_strategy(). Filteret script_loader_tag i seksjon 11 hopper over alt dette, og det er slik utsatte skript ender opp med å kjøre etter inline-kode som kaller dem.

// Ditt eget skript.
wp_enqueue_script( 'site-main', get_theme_file_uri( 'js/main.js' ), array(), '1.4.0', array(
    'in_footer' => true,
    'strategy'  => 'defer',
) );

// Et skript registrert av en utvidelse.
add_action( 'wp_enqueue_scripts', function () {
    wp_script_add_data( 'some-plugin-handle', 'strategy', 'defer' );
}, 20 );

Se på sidekilden etterpå: hvis kjernen har bestemt at en handle ikke kan utsettes, mangler attributtet rett og slett.

#Hvordan teste WordPress-ytelsen før og etter slanking

Én kjøring av PageSpeed Insights er ingen måling, fordi laboratorieresultatene varierer mellom kjøringer. En fremgangsmåte som gir sammenlignbare tall:

1. Forbered: tøm sidehurtigbufferen, bruk samme hosting og samme sett med URL-er i begge kjøringene, og noter versjonene av WordPress, tema og utvidelser.
2. Utgangspunkt: kjør PageSpeed Insights eller Lighthouse tre ganger per URL og behold medianen, og noter deretter overførte byte og antall forespørsler fra Network-fanen i DevTools med hurtigbufferen slått av.
3. Rull ut slankekoden på staging og tøm hurtigbufferen igjen.
4. Gjenta de samme kjøringene på de samme URL-ene.
5. Sammenlign overførte byte, antall forespørsler, LCP og CLS. Feltdata i Chrome UX Report-delen av PageSpeed Insights oppdateres over 28 dager, så sjekk dem igjen en måned senere.

Størrelsestabellen ovenfor viser deg den øvre grensen. På et klassisk tema som allerede laster blokkstiler ved behov, sparer fjerning av emoji, classic theme styles og head-taggene noen få kilobyte og noen linjer HTML; det er i jQuery og utvidelsenes ressurser de store tallene ligger.

#Hvordan sjekke kompatibilitet etter slanking

Sjekk tre områder etter hver endring:

1. Frontend: oppsettet, menyer, slidere og skjemaer, og nettleserkonsollen for JavaScript-feil.
2. Admin: innleggseditoren, mediebiblioteket, widgetskjermen og alle innstillingssider for utvidelser du bruker.
3. Utlogget: kontaktskjemaer, kommentarer hvis du beholder dem, søk og alt som laster data uten å laste siden på nytt.

Slå på logging mens du tester, og hold visningen av feil avslått slik at besøkende ikke ser varsler:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

#Hvordan pakke slankekoden som en mu-plugin

Kode i functions.php forsvinner når temaet byttes. En must-use-utvidelse i wp-content/mu-plugins/ lastes ved hver forespørsel, kan ikke deaktiveres fra admin og holder slankeinnstillingene uavhengige av temaet. WordPress laster PHP-filer som ligger direkte i den mappen, ikke filer i undermapper, så enten beholder du én fil, eller så legger du til en liten laster:

wp-content/
  mu-plugins/
    debloat-loader.php
    debloat/
      emoji.php
      head-cleanup.php
      xmlrpc.php
      heartbeat.php

<?php
/**
 * Plugin Name: Debloat
 * Description: Removes front-end features this site does not use.
 */

defined( 'ABSPATH' ) || exit;

foreach ( array( 'emoji', 'head-cleanup', 'xmlrpc', 'heartbeat' ) as $module ) {
    $file = __DIR__ . '/debloat/' . $module . '.php';
    if ( is_readable( $file ) ) {
        require_once $file;
    }
}

Hver modul inneholder kodesnuttene fra seksjonene ovenfor. Hold to ting utenfor en slankeutvidelse. Å slå av automatiske oppdateringer av utvidelser og temaer med auto_update_plugin og auto_update_theme er en vedlikeholdspolicy, ikke en ytelsesinnstilling, og det slår av sikkerhetsoppdateringer sammen med funksjonsoppdateringer. Og grenser for revisjoner og autolagring er konstanter, så de hører hjemme i wp-config.php, ikke i en utvidelse som lastes etter at konstantene er lest.

#Oppsummering

WordPress’ “batterier inkludert”-tilnærming er flott for nybegynnere, men utviklere som søker maksimal ytelse må trimme bort fettet. Teknikkene i denne guiden, inspirert av Terence Edens utmerkede debloating-skript, vil hjelpe deg å oppnå en slankere, raskere WordPress-installasjon.

Flere klassiske kodesnutter gjør ingenting på WordPress 7.1 (WLW-manifest, lenker til tilstøtende innlegg, SVG-filtre, autosave_interval-filteret), og noen gjør skade (fjerning av do_blocks, fjerning av oEmbed-renselsen, full blokkering av REST API). Hver kodelinje du fjerner er ett potensielt feilpunkt mindre, så sjekk hver kodesnutt mot versjonen du kjører før den går i produksjon.