Moderne WordPress medieoptimalisering med WebP og AVIF

#Moderne WordPress medieoptimalisering: hastighet og skalerbarhet

Les mer om vår WordPress-hastighetsoptimalisering hvis du vil forbedre ytelsestallene til nettstedet ditt.

Strategiene under krever en systematisk tilnærming der teknisk optimalisering og innholdskvalitet veies mot hverandre. Slik gjennomfører du hver av dem.

#1. WebP og AVIF i WordPress med Imagick eller GD

JPEG og PNG er lite effektive sammenlignet med moderne alternativer.

• WebP: Støttet i WordPress siden versjon 5.8, med både tapsfri og tapsbasert komprimering. Googles WebP-dokumentasjon oppgir at tapsbasert WebP er 25 til 34 % mindre enn sammenlignbare JPEG-filer, og at tapsfri WebP er 26 % mindre enn PNG.
• AVIF (AV1 Image File Format): Støttet siden WordPress 6.5. AVIF bruker intra-frame-koding hentet fra videokodeken AV1. Formatet slår som regel WebP ved samme visuelle kvalitet, men forskjellen avhenger av bildet, så mål på ditt eget bibliotek. Guiden om AVIF og JPEG XL går gjennom kodingskostnad og nettleserstøtte.

#Sjekk om PHP støtter WebP og AVIF

For å lage disse formatene må PHP bruke Imagick eller GD, kompilert med støtte for AVIF og WebP. Du kan sjekke hvilke bildebiblioteker som finnes på serveren fra kommandolinjen:

# Verify WebP and AVIF support inside PHP modules
php -r "print_r(gd_info());"
php -r "if (class_exists('Imagick')) { print_r(Imagick::getConfigureOptions()); }"

I GD-tabellen ser du etter WebP Support => 1 og AVIF Support => 1. Mangler disse, må PHP-pakkene på serveren kompileres med libwebp og libavif.

[!TIP] Sjekk nettstedshelsen din: Gå til Verktøy > Nettstedshelse (Site Health) for å se om PHP-installasjonen din støtter AVIF.

#Imagick eller GD til bildebehandling i WordPress

I WordPress er det to biblioteker som står for bildetransformasjonene på serversiden: GD og Imagick. Valget påvirker både ressursbruk og kvaliteten på resultatet:

• Imagick (ImageMagick): Den foretrukne motoren i større miljøer. Den gir bedre fargegjengivelse, beholder metadataprofiler (som EXIF-rotasjon) og støtter avanserte operasjoner som forhåndsvisning av PDF-er med flere sider. Imagick bruker likevel mye minne, fordi den dekodede pikselbufferen vokser med antall piksler og ikke med filstørrelsen: en JPEG på 12 megapiksler som tar 3 MB på disk, blir til flere titalls megabyte i RAM.
• GD (Graphics Library): En lett motor med lite fotavtrykk. GD er den letteste av de to ved vanlig skalering. Publiserte målinger er uenige om hvor stor forskjellen er, og noen er uenige om hvilken vei den går, så mål på din egen stack i stedet for å stole på en prosentsats fra en overskrift. GD mangler derimot avanserte konverteringer av fargerom (fargene ser ofte litt blasse ut etter konvertering), og EXIF-profiler forsvinner.
• Når WebP og AVIF genereres, håndterer Imagicks koder flertråding, mens GD kjører synkront på én CPU-kjerne. På plattformer med mye trafikk bør du prioritere Imagick og samtidig sette strenge ressursgrenser for å holde minnebruken under kontroll.

#Sett minnegrenser for Imagick i policy.xml

Å generere AVIF-filer krever mye CPU og minne. Lastes flere høyoppløselige bilder opp samtidig, kan PHP-prosessen gå tom for minne (OOM) eller nå tidsgrensen for skriptet. For å unngå dette endrer du ressursreglene for Imagick på serveren. Rediger /etc/ImageMagick-6/policy.xml eller /etc/ImageMagick-7/policy.xml og sett passende minnegrenser:

<policymap>
  <!-- Limit memory usage per process to 512MiB -->
  <policy domain="resource" name="memory" value="512MiB"/>
  <policy domain="resource" name="map" value="1GiB"/>
  <!-- Limit processing threads to prevent CPU starvation -->
  <policy domain="resource" name="thread" value="2"/>
  <!-- Block external delegate programs -->
  <policy domain="delegate" rights="none" pattern="*"/>
</policymap>

Med disse grensene kjører bildebehandlingen stabilt i vertsmiljøet, også når hele mediebiblioteket regenereres.

#2. Slik endrer du komprimeringskvaliteten for bilder i WordPress

Som standard komprimerer WordPress JPEG-opplastinger til kvalitet 82. For miniatyrbilder og bakgrunnselementer er det unødvendig høyt, og filene blir større enn de trenger å være.

#Sett komprimeringskvalitet per bildeformat

Legg disse filtrene i functions.php i temaet ditt for å justere kvaliteten etter MIME-type:

declare(strict_types=1);

namespace WPPoland\Performance\Media;

/**
 * Customizes compression quality by image format.
 */
function set_media_compression_quality( int $quality, string $mime_type ): int {
    switch ( $mime_type ) {
        case 'image/jpeg':
            return 75; // Save ~20% file space over default 82%
        case 'image/webp':
            return 80;
        case 'image/avif':
            return 65; // AVIF retains high quality even at lower compression levels
        default:
            return $quality;
    }
}
add_filter( 'wp_editor_set_quality', __NAMESPACE__ . '\\set_media_compression_quality', 10, 2 );
add_filter( 'jpeg_quality', function() { return 75; } );

#3. Slik deaktiverer du ubrukte bildestørrelser i WordPress

Når noen laster opp et bilde, lager WordPress én fil for hver registrerte understørrelse. Kjernen alene registrerer seks (thumbnail, medium, medium_large, large, 1536x1536 og 2048x2048), og hvert tema eller hver plugin som kaller add_image_size(), legger til flere. Én opplasting kan dermed etterlate et dusin filer på disken. Dette kaster bort inode-grenser og diskplass, og det koster CPU-tid ved migrering av medier.

#Fjern ubrukte bildestørrelser i functions.php

Fjern miniatyrstørrelser du ikke bruker, så sparer du diskplass og prosessering ved opplasting:

declare(strict_types=1);

namespace WPPoland\Performance\Thumbnails;

/**
 * Removes unused thumbnail dimensions.
 */
function unregister_bloated_thumbnail_sizes( array $sizes ): array {
    // Unset sizes not used by the theme layout
    unset( $sizes['medium_large'] ); // 768px wide
    unset( $sizes['1536x1536'] );     // Extra large
    unset( $sizes['2048x2048'] );     // 2K large
    return $sizes;
}
add_filter( 'intermediate_image_sizes_advanced', __NAMESPACE__ . '\\unregister_bloated_thumbnail_sizes' );

/**
 * Registers explicit custom sizes used by active layouts.
 */
function register_theme_image_sizes(): void {
    add_image_size( 'hero-lg', 1920, 800, true );
    add_image_size( 'blog-card', 600, 400, true );
}
add_action( 'after_setup_theme', __NAMESPACE__ . '\\register_theme_image_sizes' );

Proff-tips: Gå til Innstillinger > Media og sett dimensjonene til 0 for alle standardstørrelser (som Medium) du ikke bruker.

#4. Deaktiver lazy loading på LCP-bildet i WordPress

Siden versjon 5.5 legger WordPress automatisk til loading="lazy" på bilder i innlegg. Det er bra for hastigheten totalt sett, men lazy loading på ressurser over bretten hindrer nettleserens forhåndslaster og svekker LCP (Largest Contentful Paint). Siden WordPress 6.3 hopper kjernen allerede over lazy loading på det første store bildet og gir det fetchpriority="high", slik guiden om bildehåndtering forklarer. Filtrene under virker fortsatt (kjernen beholder wp_img_tag_add_loading_attr for bakoverkompatibilitet) og er nyttige i egne maler og lister der kjernen gjetter feil.

#Last bilder over bretten eager med fetchpriority

Sett opp malene slik at det første bildet i innleggslister lastes eager, og gi hero-bilder høy hente-prioritet:

declare(strict_types=1);

namespace WPPoland\Performance\LCP;

/**
 * Disables lazy loading for the first post image.
 */
function disable_lazy_load_on_first_image( string|bool $value, string $image_tag, string $context ): string|bool {
    static $first_image = true;

    if ( 'the_content' === $context && $first_image ) {
        $first_image = false;
        return false; // Prevents loading="lazy" injection
    }

    return $value;
}
add_filter( 'wp_img_tag_add_loading_attr', __NAMESPACE__ . '\\disable_lazy_load_on_first_image', 10, 3 );

/**
 * Appends fetchpriority="high" to eager-loaded images.
 */
function apply_fetchpriority_to_eager_images( array $attr, \WP_Post $attachment ): array {
    if ( isset( $attr['loading'] ) && 'eager' === $attr['loading'] ) {
        $attr['fetchpriority'] = 'high';
    }
    return $attr;
}
add_filter( 'wp_get_attachment_image_attributes', __NAMESPACE__ . '\\apply_fetchpriority_to_eager_images', 10, 2 );

#5. Konfigurasjon av responsive bildestørrelser

For at nettleseren skal hente riktig bildestørrelse fra srcset-attributtet, må du tilpasse sizes-definisjonene. Standardverdien faller ofte tilbake til 100vw, og da henter nettleseren for store bilder på skrivebordsskjermer.

#Eget sizes-attributt for srcset-brytepunkter

declare(strict_types=1);

namespace WPPoland\Performance\Responsive;

/**
 * Overrides default sizes attributes to match theme layout breakpoints.
 */
function filter_responsive_image_sizes_attribute( string $sizes, array $size_array ): string {
    $width = $size_array[0];

    // Check if the image matches our blog post layout bounds
    if ( $width >= 800 ) {
        return '(max-width: 840px) 100vw, 800px';
    }

    return $sizes;
}
add_filter( 'wp_calculate_image_sizes', __NAMESPACE__ . '\\filter_responsive_image_sizes_attribute', 10, 2 );

Når du rendrer bilder i egne løkker, kan du også sende sizes-attributtet direkte:

echo wp_get_attachment_image(
    $image_id,
    'large',
    false,
    ['sizes' => '(max-width: 600px) 100vw, 800px']
);

Dette forteller nettleseren at bildet tar opp hele bredden når skjermen er smalere enn 600px, og ellers er 800px bredt.

#6. Lever AVIF i stedet for JPEG med .htaccess

Har nettstedet gamle JPEG-filer, men du vil levere WebP- eller AVIF-versjoner til moderne nettlesere uten å endre HTML-koden, kan du bruke regler for innholdsforhandling på serveren.

#Lever AVIF med rewrite-regler i Apache

Legg disse reglene i .htaccess for å levere AVIF-filen automatisk når nettleseren godtar formatet og filen finnes på serveren:

<IfModule mod_rewrite.c>
  RewriteEngine On
  
  # Check if browser supports AVIF
  RewriteCond %{HTTP_ACCEPT} image/avif
  
  # Check if the AVIF version exists on disk
  RewriteCond %{DOCUMENT_ROOT}/$1.avif -f
  
  # Redirect requests for JPEGs/PNGs to the AVIF version
  RewriteRule ^(wp-content/uploads/.*)\.(jpe?g|png)$ $1.avif [T=image/avif,E=accept:1]
</IfModule>

Med slike rewrite-regler på servernivå leverer du moderne, godt optimaliserte filer til nettlesere som støtter dem, og beholder reserveløsningen for eldre systemer.

#7. Flytt WordPress-medier til S3 med CDN

For nettsteder med store mediebiblioteker begrenser lokale serverdisker skalerbarheten og gjør sikkerhetskopiering mer komplisert. Å flytte mediene til en Object Storage-tjeneste (for eksempel AWS S3, DigitalOcean Spaces eller Google Cloud Storage) og levere dem via et CDN (Content Delivery Network) er standardløsningen for nettsteder med mye trafikk. Plugins som WP Offload Media eller Media Cloud er vanlige verktøy for dette.

#Hva endrer seg når WordPress-mediene flyttes ut

Når mediene er flyttet ut:

1. Tilstandsløse webnoder: De enkelte webserverne trenger ikke lenger synkroniserte, vedvarende disker. Du kan skalere webcontainere opp og ned dynamisk med autoskaleringsgrupper.
2. Mindre lokal lagring: Når integrasjonen sletter lokale filer rett etter vellykket opplasting, går de lokale diskene ikke fulle, og kostnadene på applikasjonsserverne holdes nede.
3. CDN-mellomlagring og geografisk distribusjon: Forespørslene går til kantcacher (som Cloudflare, Amazon CloudFront eller KeyCDN) i stedet for hovedserveren, noe som reduserer båndbreddebruk og ventetid for brukere i hele verden.

#Innstillinger for WP Offload Media og S3 i wp-config.php

Dokumentasjonen av innstillingskonstantene i WP Offload Media beskriver AS3CF_SETTINGS som en serialisert tabell. Lagringsleverandørene heter aws, do og gcp, og et eget CDN-domene settes med leveringsnøklene, ikke lagringsnøklene:

// Define S3 credentials and bucket details securely in wp-config.php
define( 'AS3CF_SETTINGS', serialize( [
    'provider' => 'aws',
    'access-key-id' => getenv( 'AWS_ACCESS_KEY_ID' ),
    'secret-access-key' => getenv( 'AWS_SECRET_ACCESS_KEY' ),
    'bucket' => 'wppoland-media-bucket',
    'region' => 'eu-central-1',
    'copy-to-s3' => true,
    'serve-from-s3' => true,
    'remove-local-file' => true, // Saves disk space on the primary application server
    'object-versioning' => true, // Timestamped paths, so changed files get new URLs
    'delivery-provider' => 'cloudflare',
    'enable-delivery-domain' => true,
    'delivery-domain' => 'media.wppoland.com' // Custom CDN subdomain
] ) );

#CORS- og cache-control-headere for en S3- eller R2-bøtte

Skal vektorgrafikk (SVG) og egne webfonter fra mediebøtta vises riktig på frakoblede headless-domener (for eksempel en Astro-frontend på et annet domene), må du sette en CORS-konfigurasjon (Cross-Origin Resource Sharing) på bøtta.

Legg denne CORS-policyen i JSON inn i innstillingene for S3- eller R2-bøtta:

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["GET", "HEAD"],
    "AllowedOrigins": ["https://wppoland.com", "https://www.wppoland.com"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]

Sørg i tillegg for at filene fra bøtta har statiske cache-headere. Sett opp integrasjonen eller CDN-et slik at det sender: Cache-Control: public, max-age=31536000, immutable

Det får nettlesere og kantservere til å mellomlagre mediefilene permanent, med færre forespørsler og raskere lasting som resultat. Direktivet immutable er bare trygt fordi object-versioning legger en endret fil under en ny sti. Uten det beholder et redigert bilde den gamle URL-en og blir liggende i cachen i et år.

#8. Slik begrenser du størrelsen på bildeopplastinger i WordPress

For å hindre at redaktører laster ukomprimerte kamerabilder på 10 MB rett inn i blokkene i innleggsredigereren (noe som sløser med båndbredde og lagring), bør du validere filene automatisk på serversiden.

#Hvorfor opplastingsstørrelsen bør valideres på serveren

Når filstørrelsen sjekkes på serveren, unngår du tidsavbrudd i PHP. Laster en redaktør opp et bilde på 10 MB, skjer dette:

1. Serveren må skrive den midlertidige filen til /tmp/.
2. PHP-prosessen prøver å laste bildet inn i minnet for å skalere det. Nås grensene for GD eller Imagick, feiler skriptet og etterlater halvferdige filer på disken.
3. Et filter på wp_handle_upload_prefilter fanger filen opp med en gang den mottas og sjekker størrelsen før noen bildetransformasjon kjører. Avsnittet om upload_max_filesize lenger ned viser hvordan nettleseropplasteren håndhever samme grense før filen sendes.

Slik ser PHP-filteret ut:

declare(strict_types=1);

namespace WPPoland\Performance\Limits;

/**
 * Enforces file size limits by image type during upload.
 */
function restrict_large_uploads( array $file ): array {
    $size_kb = $file['size'] / 1024;
    $type    = $file['type'];

    // Limit standard raster images to 1.5MB
    if ( strpos( $type, 'image/' ) !== false && 'image/gif' !== $type ) {
        if ( $size_kb > 1536 ) {
            $file['error'] = 'Image upload failed: File size exceeds the 1.5MB limit. Please compress your asset before uploading.';
        }
    }

    return $file;
}
add_filter( 'wp_handle_upload_prefilter', __NAMESPACE__ . '\\restrict_large_uploads' );

#9. Hva WordPress lagrer for hvert opplastet bilde

Hver fil i mediebiblioteket er et innlegg av typen attachment. Selve filen refereres av to post meta-rader, og de fleste medieproblemer (ødelagte miniatyrbilder etter en migrering, en offload-plugin som leverer feil størrelse, regenerering som aldri blir ferdig) skyldes at disse to radene ikke stemmer med det som ligger på disken.

• _wp_attached_file inneholder stien relativt til opplastingsmappen, for eksempel 2026/10/workshop-floor.jpg. Var originalen større enn terskelen for store bilder, peker feltet til -scaled-kopien og ikke til originalen.
• _wp_attachment_metadata inneholder en serialisert tabell som bygges av wp_generate_attachment_metadata(): width, height, file, filesize (lagret siden WordPress 6.0), sizes med én oppføring per generert understørrelse (filnavn, bredde, høyde, MIME-type), image_meta med EXIF- og IPTC-dataene som kjernen leser, og original_image når opplastingen ble skalert ned.

Les tabellen før du stoler på en plugin-rapport om den:

# Dump the metadata of attachment 1874 as JSON
wp post meta get 1874 _wp_attachment_metadata --format=json

# Show the stored relative path
wp post meta get 1874 _wp_attached_file

Siden WordPress 5.3 skriver kjernen disse metadataene etter hver understørrelse den lager, ikke én gang til slutt. Dør PHP midt i en stor opplasting, er de ferdige størrelsene allerede registrert, og wp_update_image_subsizes() lager bare de manglende ved neste forsøk. Det er også grunnen til at REST API-et har en post-process-rute (/wp/v2/media/<id>/post-process med handlingen create-image-subsizes): etter en serverfeil kan opplasteren be om de manglende størrelsene i stedet for å sende filen på nytt.

Filteret big_image_size_threshold (2560 piksler som standard) avgjør når -scaled-kopien lages. Guiden om bildehåndtering viser hvordan du endrer eller slår av terskelen, og går også gjennom wp media regenerate.

#Slik lister du registrerte bildestørrelser med WP-CLI

Før du fjerner noe som beskrevet i del 3, bør du se hva som faktisk er registrert. wp media image-size skriver ut hver størrelse med bredde, høyde, beskjæringsflagg og forhold, også størrelser fra plugins du kanskje har glemt:

wp media image-size --format=table
wp media image-size --fields=name,width,height,crop --format=csv

Sammenlign listen med filene i en nylig månedsmappe. En størrelse som finnes på disken, men ikke i listen, tilhører et tema eller en plugin som ikke lenger er aktiv, og wp media regenerate lager den ikke på nytt. Standardverdiene i Innstillinger > Media kommer fra installasjonsskjemaet: thumbnail 150 x 150 beskåret, medium 300 x 300, medium_large 768 bred uten høydegrense og large 1024 x 1024. Setter du bredde og høyde til 0 på den skjermen, slutter kjernen å lage den størrelsen for nye opplastinger.

#10. Slik endrer du mappestrukturen for opplastinger i WordPress

Som standard lagrer WordPress opplastinger i mapper for år og måned (wp-content/uploads/2026/10/). Avkrysningsboksen for å organisere opplastinger i mapper etter år og måned under Innstillinger > Media styrer alternativet uploads_use_yearmonth_folders, som er 1 på en ny installasjon. Slår du den av, gjelder det bare nye opplastinger: eksisterende filer beholder stiene sine, fordi stien lagres per vedlegg i _wp_attached_file.

Filteret upload_dir endrer hvor nye filer havner. Det mottar en tabell med path, url, subdir, basedir, baseurl og error, og du endrer subdir sammen med path og url:

declare(strict_types=1);

namespace WPPoland\Performance\Uploads;

/**
 * Stores PDF uploads in /uploads/documents/ instead of the date folders.
 */
function route_pdf_uploads( array $uploads ): array {
    $name = $_FILES['async-upload']['name'] ?? '';

    if ( ! str_ends_with( strtolower( $name ), '.pdf' ) ) {
        return $uploads;
    }

    $uploads['subdir'] = '/documents';
    $uploads['path']   = $uploads['basedir'] . $uploads['subdir'];
    $uploads['url']    = $uploads['baseurl'] . $uploads['subdir'];

    return $uploads;
}
add_filter( 'upload_dir', __NAMESPACE__ . '\\route_pdf_uploads' );

Kjernen har ingen mapper i mediebiblioteket. Mappevisningen som enkelte plugins legger til, er en taksonomi registrert på posttypen attachment, så den ligger i databasen og flytter ingen filer på disken. Bygger du en selv med register_taxonomy( 'media_folder', 'attachment', ... ), bør du bruke _update_generic_term_count som tellefunksjon: standardtelleren teller et vedlegg bare via et publisert overordnet innlegg, så filer uten tilknytning dukker aldri opp i antallet.

#11. Slik håndterer du alt-tekst i WordPress-mediebiblioteket

Feltet for alt-tekst i mediebiblioteket lagres i post meta-feltet _wp_attachment_image_alt. wp_get_attachment_image() leser det hver gang bildet rendres, etter trim() og strip_tags(), så fremhevede bilder og temamaler som bruker den funksjonen, får en endret verdi med en gang.

Bildeblokken oppfører seg annerledes. alt-attributtet hentes fra alt-attributtet på <img> i det lagrede innleggsinnholdet, så blokken kopierer verdien fra biblioteket når bildet settes inn, og beholder sin egen kopi etterpå. Retter du alt-teksten i mediebiblioteket, oppdateres ikke innlegg som allerede inneholder bildet. Der må du redigere selve blokken.

En revisjonsspørring finner bilder uten alt-tekst (tilpass prefikset wp_ til installasjonen din):

wp db query "SELECT p.ID, p.post_title FROM wp_posts p
  LEFT JOIN wp_postmeta m ON m.post_id = p.ID AND m.meta_key = '_wp_attachment_image_alt'
  WHERE p.post_type = 'attachment' AND p.post_mime_type LIKE 'image/%'
  AND (m.meta_value IS NULL OR m.meta_value = '')"

# Set the alt text of one attachment
wp post meta update 1874 _wp_attachment_image_alt "Two developers reviewing a staging site on a laptop"

Et tomt resultat er ikke automatisk målet. W3Cs beslutningstre for alt-tekst sier at et rent dekorativt bilde, eller et bilde der teksten allerede står som ekte tekst i nærheten, skal ha et tomt alt-attributt. Skriv alt-tekst for bilder som bærer informasjon, og beskriv funksjonen for bilder som fungerer som lenker eller knapper.

#12. Slik øker du upload_max_filesize for WordPress

Grensen som opplasteren viser som maksimal filstørrelse ved opplasting, kommer fra wp_max_upload_size(). Funksjonen leser to PHP-innstillinger, upload_max_filesize og post_max_size, tar den minste og sender den gjennom filteret upload_size_limit. Samme verdi går til nettleseropplasteren som max_file_size, så en fil over grensen avvises før den sendes.

PHP-manualen oppgir standardverdiene 2M for upload_max_filesize og 8M for post_max_size, og merker begge som INI_PERDIR. Det har en praktisk konsekvens: ini_set() i wp-config.php kan ikke øke dem. Sett dem i php.ini, i en .user.ini-fil, i PHP-FPM-poolkonfigurasjonen eller (på Apache med mod_php) i .htaccess, og hold post_max_size større enn upload_max_filesize, fordi manualen krever det.

; .user.ini in the WordPress root (PHP-FPM / CGI)
upload_max_filesize = 16M
post_max_size = 20M

Å øke PHP-grensene er halve jobben. Den andre halvparten er å hindre at redaktørene bruker det nye handlingsrommet på kameraoriginaler på 12 megapiksler. Filteret upload_size_limit kan i praksis bare senke den effektive grensen (PHP forkaster alt over sin egen innstilling før WordPress kjører), og det er et bedre sted for regelen om 1,5 MB fra del 8, fordi opplasteren da viser den reelle grensen:

add_filter( 'upload_size_limit', static fn ( int $size ): int => min( $size, 1536 * KB_IN_BYTES ) );

På multisite finnes det en tredje grense. Nettverksinnstillingen for maksimal filstørrelse ved opplasting lagres i nettstedsalternativet fileupload_maxk, 1500 KB hvis ingen har endret den, og kjernen bruker den gjennom samme filter sammen med nettstedets gjenværende opplastingskvote.

#13. 90-dagers plan for bildeoptimalisering i WordPress

Følg denne tidslinjen for å optimalisere og overvåke mediefilene på nettstedet:

• Dag 1-30 (umiddelbar konfigurasjon): Sjekk at PHP-modulene på serveren støtter AVIF og WebP. Sett opp kvalitetsfiltre i functions.php med egen komprimeringskvalitet per format. Unnta hero-elementer over bretten fra lazy loading, og bruk filtre for høy hente-prioritet for å forbedre Largest Contentful Paint (LCP).
• Dag 31-60 (rydding i størrelser og regenerering): Finn og fjern ubrukte bildestørrelser fra temaet med filteret intermediate_image_sizes_advanced for å spare plass på serveren. Skriv et PHP-filter som begrenser store opplastinger på serveren, og juster upload_size_limit etter det. Kjør revisjonsspørringen for alt-tekst og rett bilder som bærer informasjon. Kjør regenereringskommandoene i WP-CLI for å bygge miniatyrbildene på nytt med de oppdaterte kvalitetsprofilene.
• Dag 61-90 (skalering og flytting til skyen): Flytt mediebiblioteket til objektlagring i S3 eller R2, med en konfigurasjon som fjerner de lokale kildefilene. Sett opp et eget, cookiefritt CDN-underdomene med riktige CORS- og cache-control-headere, og kontroller hastighetsforbedringene i Search Console.

Trenger du hjelp med en skreddersydd pipeline for medieoptimalisering eller med å flytte medier til S3? Teamet bak vår WordPress-hastighetsoptimalisering kan gå gjennom mediebibliotekene dine, kompilere serverpakker og konfigurere CDN på kanten. Kontakt oss for å snakke om prosjektet ditt.