WordPress flersprogede plugins øger antallet af databaseforespørgsler, HTTP-anmodninger og PHP-overhead, hvilket er grunden til, at WordPress flersproget falder ydeevnen ofte målbart. Jeg viser tydeligt, hvor tiden går tabt, hvilke arkitekturer der gør tingene langsommere, og hvordan jeg kan reducere indlæsningstiderne med målrettede foranstaltninger uden at ofre sproglig mangfoldighed.
Centrale punkter
Før jeg forklarer detaljerne, opsummerer jeg de vigtigste håndtag og sætter dem ind i en praktisk sammenhæng. Jeg bruger bevidst klare formuleringer, så du kan træffe beslutninger hurtigere. De følgende nøglepunkter dækker teknologi, arkitektur og tuning. Det betyder, at du straks kan se, hvor du skal starte først. Hvert udsagn fokuserer på målbare effekter og specifikke foranstaltninger, som jeg derefter går mere i dybden med.
- DatabaseDuplikater pr. sprog øger forespørgsler og hukommelseskrav.
- HTTP-anmodningerFlere scripts, stilarter og API-kald øger indlæsningstiden.
- ArkitekturMultisite adskiller sprog på en ren måde, men kræver mere administration.
- CloudEksterne oversættelsestjenester sparer DB-belastning, men skaber ventetid.
- IndstillingCaching, string-strategi og CDN reducerer ventetiden.
Hvorfor oversættelses-plugins koster performance
Oversættelses-plug-ins graver dybt ned i WordPress arkitektur, fordi de skal levere indhold, strenge, menuer og permalinks på en sprogspecifik måde. Hvert ekstra sprog øger antallet af databaseforespørgsler, fordi systemet tjekker og indlæser varianter af et objekt. Der er også sprogomskiftere, ekstra scripts og stilarter, der genererer flere HTTP-anmodninger pr. visning. Jeg ser regelmæssigt i revisioner, at PHP-køretiden og antallet af indlæste indstillinger stiger, så snart et plugin aktiverer oversættelser på niveau med indlæg, taksonomier og strenge. Uden tuning afspejles denne ekstra indsats i Time to First Byte, Start Render og Largest Contentful Paint.
Databasebelastning: dubletter, forespørgsler og caching
Mange wp Oversættelsesplugins gemmer oversættelser som separate indlæg, sider og taksonomier, hvilket gør databasen meget stor. Hvis tre eller fem sprog er aktive, vokser wp_posts-tabellen og dens relationer betydeligt, og jeg observerer derefter forespørgselsspring fra omkring 4 til op til 16 pr. sidevisning. Dette mønster påvirker især butikker, da produkter, varianter og metadata vokser uforholdsmæssigt meget. Jeg reducerer virkningen ved at aktivere selektiv strengoversættelse, begrænse de anvendte sprog og gøre målrettet brug af objektcaching. Det hjælper også at rydde op i revisioner, autodrafts og gamle strengposter, så indekserne forbliver mindre, og InnoDB-bufferen arbejder mere effektivt.
HTTP-anmodninger, aktiver og eksterne tjenester
Ud over databaseforespørgsler kan yderligere HTTP-forespørgsler reducerer indlæsningstiden, f.eks. for sprogskift, stilark eller editorintegrationer. Hvis en tjeneste opbevarer oversættelser i skyen, aflaster det databasen, men flytter arbejdet til API-opkald og svartider. Det kan betale sig for små sider, men bliver en flaskehals med lange tekster eller mange sprog. Lokalt lagrede plugins drager fordel af cache-hits, så snart der sker tilbagevendende sidevisninger, men kræver ren asset management. Jeg minimerer effekten ved at bundle scripts, deaktivere ubrugte komponenter og gengive CSS kritisk.
Multisite-tilgang med MultilingualPress
En multisite-opsætning distribuerer sprog til separate Steder, Det betyder, at hver instans bruger sin egen database og undgår kollisioner mellem forespørgsler. Det holder antallet af forespørgsler pr. side nede, selv om der findes mange sprog, hvilket holder svartiden stabil. Prisen for dette er en ekstra administrationsindsats for temaer, plugins og brugerrettigheder, men det betaler sig for større projekter. Jeg vælger multisite, når der er mange sprog, forskelligt indhold eller forskellige teams involveret. Hvis du vil sammenligne mulighederne først, kan du finde Sammenligning af værktøjer 2025 en god hjælp til at træffe beslutninger.
Sammenligning af målte værdier: plugins og nøgletal
Jeg vurderer Strøm altid baseret på konkrete nøgletal, fordi den subjektive opfattelse er vildledende. Medianbelastningstiden, antallet af anmodninger, overførselsstørrelsen og antallet af databaseforespørgsler er afgørende. Følgende tabel opsummerer typiske resultater fra testscenarier, som jeg bruger i audits. Værdierne viser, at slanke arkitekturer giver fordele for den samme funktion og skal cachelagres mindre aggressivt. Især i projekter med meget dynamisk indhold tæller et lavt antal forespørgsler mere end rå gennemstrømning.
| Plugin | Median indlæsningstid | HTTP-anmodninger | Filstørrelse | DB-forespørgsler |
|---|---|---|---|---|
| Intet plugin | 0,764 s | 14 | 81 KB | 4 |
| WPML | 0,707 s | 18 | 82 KB | 16 |
| Polylong | 0,712 s | 15 | 79 KB | 4 |
| TranslatePress | 1,026 s | 22 | 127 KB | 7 |
| Weglot | 0,987 s | 19 | 138 KB | 4 |
Praktisk tuning: caching, database og medier
Jeg starter hver tuning med en ren Caching, fordi det er her, de største tidsbesparelser pr. opkald kommer fra. Side- og fragmentcacher reducerer PHP-køretiden, mens objektcacher opfanger tilbagevendende forespørgsler. Samtidig holder jeg strengoversættelser slanke, deaktiverer automatiske scanninger og sletter gamle poster, så indekserne forbliver hurtige. Et CDN til billeder, webfonts og scripts reducerer mærkbart ventetiden afhængigt af regionen, hvilket direkte fremskynder flersproget trafik. Hvis du vil dykke dybere ned i faldgruberne, kan du med fordel læse mine noter om Anti-mønstre for performance, som jeg jævnligt ser i projekter.
WooCommerce-specifikke snublesten
Butikker tilføjer deres egne Belastning, fordi produkter, varianter og filtre vokser pr. sprog og multiplicerer forespørgsler. Jeg observerer ofte yderligere 0,3 sekunder pr. sprog med omfattende kataloger, hvilket fører til mærkbare afbrydelser for mobile besøgende. Produktsitemaps, breadcrumbs og facetter kan gøre det hele meget langsommere, hvis databasen allerede er oppustet. Jeg bremser det ved at fjerne unødvendige metafelter fra oversættelsen, genopbygge søgeindeks og adskille indkøbskurvens cache. Jeg opstiller også en regel: strengoversættelse kun for tekster, der rent faktisk er synlige, ikke for tekniske metadata.
Udvælgelsesguide: Hvilken løsning passer til hvilket projekt?
Jeg beslutter mig pragmatisk i henhold til Profil af hjemmesiden, fordi intet plugin tjener alle formål på samme tid. Mindre websteder har gavn af Polylang, fordi det forbliver let og genererer få forespørgsler. Til store projekter med mange indholdstyper bruger jeg WPML, men er meget opmærksom på tuning og klare string-strategier. Hvis du prioriterer teamwork og lav serverbelastning, fungerer en cloud-tilgang som Weglot godt, så længe API-latency er under kontrol. For indholdsteams, der ønsker at spille signaler på siden rent ud, har jeg skabt en kompakt SEO-guide som undgår typiske faldgruber.
Overvågning: måle, teste, optimere
Jeg måler ægtee performance med gentagne tests, fordi caches, netværkseffekter og outliers ellers kan være vildledende. Ensartede testbetingelser, identiske sider og klare budgetter for TTFB, LCP og requests er vigtige. Jeg sætter målværdier for hvert sprog, så udrulningen af yderligere oversættelser ikke i al hemmelighed driver indlæsningstiden op. Et staging-system forhindrer plugin-opdateringer i at forringe de målte værdier, før de går i luften. Jeg sporer også Core Web Vitals pr. sprog for at kunne genkende konverteringstab på et tidligt tidspunkt og træffe målrettede modforanstaltninger.
Sammenligning af arkitektur: WPML, Polylang, TranslatePress, Weglot
Oversættelsespluginets arkitektur bestemmer, hvor omkostningerne opstår. WPML duplikerer indhold som uafhængige indlæg og linker dem ved hjælp af mapping-tabeller; parallelt hermed ender strenge i separate tabeller. Det øger planlægningssikkerheden, men koster forespørgsler og optionsoverhead. Polylang knytter primært sprog til en taksonomi og arbejder med enkle relationer - magert i forespørgslen, så længe synkroniseringer (f.eks. for medier) er bevidst konfigureret. TranslatePress skriver oversættelser i sine egne tabeller og gengiver mange ting på runtime, hvilket gør frontend-ændringer hurtige, men kan øge PHP-tiden, hvis siderne varierer meget. Weglot opbevarer oversættelser i skyen på serversiden og injicerer dem i frontend; den lokale database forbliver lille, men omkostningerne flyttes til API-latenstider og yderligere anmodninger. Jeg vælger model efter indholdstyper: Mange brugerdefinerede indlægstyper og komplekse taksonomier er mere til fordel for Polylang eller Multisite, meget teksttunge sider uden særlig logik kan kontrolleres godt med WPML eller TranslatePress, cloud-tilgange er værd at bruge for teams uden servervedligeholdelse.
URL'er, Hreflang og SEO-signaler uden performance-fælder
URL-strategien har en direkte effekt på caching og crawling. Underkataloger (/en/) er de mest fordelagtige ud fra et administrativt synspunkt og kan nemt kortlægges i cachenøglen; underdomæner (de.example.com) adskilles rent, men kræver mere DNS/CDN-vedligeholdelse. Forespørgselsparametre (?lang=de) er de enkleste, men forstyrrer proxy- og edge-cacher. Jeg definerer klare regler for hvert projekt: Sprog som sti, konsekvente efterfølgende skråstreger, 301-omdirigeringer sat rent og ingen sprogskift via JavaScript uden at ændre URL'en. Hreflang skal vedligeholdes fuldt ud pr. side, herunder x-default. Sitemaps pr. sprog gør crawling lettere for søgemaskiner og reducerer unødvendige hits på irrelevante sprogversioner. Vigtigt: Cachenøglen skal indeholde sproget, ellers vil den forkerte bruger modtage den forkerte version. Cookies varierer med standardplugins (f.eks. wpll_language), som ofte ignoreres i cacher - her definerer jeg en „Vary by Cookie“-regel eller, bedre, arbejder rent stibaseret.
Caching pr. sprog: Edge, Vary og Prewarm
Effektiv caching afgør, om Multilingual forbliver hurtig. Jeg er afhængig af:
- Sidecache med „Vary on Language“ (stipræfiks i stedet for cookie) for maksimal hitrate.
- Caching af fragmenter for tilbagevendende widgets (f.eks. menuer), så oversættelseslogik ikke gengives ved hvert kald.
- Edge-cache i CDN med kort TTL plus „stale-while-revalidate“ for at undgå at straffe kolde sprog.
- Målrettet forvarmning af vigtige landingssider pr. sprog i henhold til implementeringer.
I frontend reducerer jeg blokering af rendering ved at holde kritiske elementer inline og indlæse resten asynkront. HTTP/2/3 tillader mange parallelle forespørgsler, så i stedet for at bundle, prioriterer jeg blindt alt i én fil. Jeg underinddeler skrifttyper pr. skriftsystem (latin, kyrillisk, CJK), så ikke alle sprog indlæser den samme store skrifttype. For dynamiske sider med en indkøbskurv eller personalisering adskiller jeg nøje cache-zoner, ellers kolliderer valutaer, sprog og brugertilstande.
Serveropsætning og PHP-tuning, der virkelig virker
Det bedste valg af plugin vil falde til jorden, hvis stakken gør dig langsommere. Jeg planlægger med PHP 8.2+, OPcache aktiveret, tilstrækkelig hukommelse og en FPM-pool, der matcher trafikken og CPU'en (pm dynamisk, begrænset max_children). Objektcaching via Redis reducerer round trips dramatisk - nøglen er at undgå flush-orgier og at definere cachegrupper med sprogkontekst på en ren måde. På databasesiden holder jeg InnoDB-bufferen stor nok til at rumme arbejdsdata og aktiverer langsomme forespørgselslogfiler for at gøre sprogrelaterede „N+1“-mønstre synlige. Jeg undgår transienter med lange køretider og „autoload = yes“ i optionstabellen; autoload hører kun til de poster, der virkelig er brug for. Baggrundsjobs kører via det rigtige systems cron, ikke kun WP cron, så oversættelseskøer kan planlægges og behandles uden for spidsbelastningsperioder.
Workflow, cron og prebuilds til problemfrit redaktionelt arbejde
Der opstår mange bremser i hverdagen: automatiske stringscanninger ved hver ændring, live-synkronisering af menuer eller medier og ukoordinerede batch-oversættelser. Jeg flytter dyre operationer til tidsvinduer uden for spidsbelastning, deaktiverer realtidsscanninger og arbejder med manuelle synkroniseringer før udgivelser. Store sites har gavn af prebuilds: Jeg pre-render de vigtigste skabeloner pr. sprog, opvarmer cacher og kontrollerer LCP/TTFB i forhold til budgetter. Jeg integrerer oversættelses-API'er som en kø, ikke inline i editoren - timeout- og retries-strategier forhindrer individuelle sprog i at blokere hele udgivelsesprocessen. Ændringsvinduer pr. team og klare ansvarsområder pr. sprog undgår dobbeltarbejde og reducerer metadata-kaos.
Medier, skrifttype og layout: sprogspecifikt, men strømlinet
Medier bliver hurtigt mange, hvis hvert aktiv duplikeres til hvert sprog. Jeg oversætter primært metadata (alt, titel, billedtekst) og deler binære filer, forudsat at motivet er identisk. Til sprog med andre skriftsystemer bruger jeg mine egne, lette undergrupper af skrifttyper og variable skrifttyper med målrettet brug af akser. RTL-sprog kræver separate stilarter; jeg adskiller den ekstra CSS-belastning i stedet for at levere den globalt. Jeg gør billeder identisk responsive for hvert sprog (srcset, størrelser), men kun med sprogspecifikke overlays, hvor det giver konvertering. For LCP-elementer sætter jeg fetchpriority=high og sørger for, at det gælder konsekvent i alle sprogvarianter - det er en hyppig afvigelse i audits.
Databaseteknik: indekser, autoload og hygiejne
Flere sprog uden indeksplanlægning er en præstationsmultiplikator i den forkerte retning. Jeg tjekker, om de felter, der bruges af plugins i postmeta, termmeta eller mine egne tabeller, har passende sammensatte indekser (f.eks. language_code + object_id). For meget store kataloger reducerer jeg revisioner aggressivt, opsætter regelmæssige oprydninger af forældreløse og forældreløse strengposter og er opmærksom på optionstabellens autoload-størrelse. Små justeringer har også en effekt: grænser for heartbeat i editoren, deaktiveret kommentartælling i arkiver og undgåelse af dyre „LIKE %%“-forespørgsler på store metatabeller. Resultatet er reproducerbart lavere forespørgselstider, især på produktlister og facetfiltre.
Typiske fejlmønstre og hurtige løsninger
- Forkert cache-nøgleSprog mangler i nøglen, brugerne ser blandet indhold. Løsning: Brug stipræfikser, eller indstil „Vary on Cookie“ korrekt.
- N+1 forespørgslerStrengoversættelser per menupunkt individuelt. Løsning: Aktivér preloading/batching, fragment-cache menu-output.
- Oppustede optionerAutoload-strenge vokser lydløst. Løsning: Gennemgå autoload=yes, arkivering af gamle domæner/sprog.
- API-flaskehalseCloud translation seriel og uden cache. Løsning: Definer TTL'er, backoff-strategier, aktiver edge-cache.
- Fragmenter af WooCommerce-vognOmgåelse af alle cacher på alle sprog. Løsning: Tjek indkøbskurvens fragmenteringsstrategi, cacher separate endepunkter pr. sprog.
Til diagnosticering bruger jeg query- og hook-analyser, sammenligner sporingsdata pr. sprog og isolerer outliers i editoren og frontend. Nogle få målrettede rettelser halverer ofte PHP-tiden uden at spare på indholdet.
Kompakt oversigt til hurtige beslutninger
Flere sprog betyder mere Arbejde til database, forespørgsler og PHP, men smart udvælgelse og indstilling holder siderne hurtige. Jeg planlægger først arkitekturen og målværdierne, så vælger jeg plugin'et efter, hvordan det håndterer forespørgsler, aktiver og strenge. Multisite fungerer godt til flersprogethed med heterogent indhold, et letvægts-plugin er tilstrækkeligt til slanke sites. Hvis du bruger butiksfunktioner, bør du tage synkroniseringen af produktdata og filtre meget alvorligt og installere caching lige fra starten. Det vil udvide rækkevidden af dit indhold uden at sætte brugernes tålmodighed og placeringer over styr.
