Wordpress

Varför WordPress flerspråkiga plugins kostar prestanda

WordPress Flerspråkiga plugins driver upp ytterligare databasfrågor, HTTP-förfrågningar och PHP-overhead, vilket är anledningen till att WordPress Flerspråkig prestandan sjunker ofta mätbart. Jag visar tydligt var tiden går förlorad, vilka arkitekturer som gör saker långsammare och hur jag kan minska laddningstiderna med riktade åtgärder utan att offra den språkliga mångfalden.

Centrala punkter

Innan jag går in på detaljerna sammanfattar jag de viktigaste hävstängerna och sätter in dem i ett praktiskt sammanhang. Jag använder medvetet tydliga formuleringar så att du snabbare ska kunna fatta beslut. Följande nyckelpunkter omfattar teknik, arkitektur och tuning. Det innebär att du omedelbart kan se var du bör börja först. Varje påstående fokuserar på mätbara effekter och specifika åtgärder, som jag sedan går in på mer i detalj.

DatabasDuplikat per språk ökar antalet frågor och minnesbehovet.
HTTP-förfrågningarFler skript, stilar och API-anrop ökar laddningstiden.
ArkitekturMultisite separerar språk på ett snyggt sätt, men kräver mer administration.
MolnExterna översättningstjänster sparar DB-belastning, men genererar fördröjning.
TuningCaching, strängstrategi och CDN minskar väntetiderna.

Varför översättningsplugins kostar prestanda

Plug-ins för översättning går på djupet i WordPress arkitektur, eftersom de måste tillhandahålla innehåll, strängar, menyer och permalänkar på ett språkspecifikt sätt. Varje ytterligare språk ökar antalet databasförfrågningar eftersom systemet kontrollerar och laddar varianter av ett objekt. Det finns också språkväxlare, ytterligare skript och stilar som genererar fler HTTP-förfrågningar per vy. Jag ser regelbundet i revisioner att PHP-körtiden och antalet laddade alternativ ökar så snart ett plugin aktiverar översättningar på nivån av inlägg, taxonomier och strängar. Utan inställning återspeglas denna extra ansträngning i tid till första byte, Start Render och Largest Contentful Paint.

Databasbelastning: dubbletter, frågor och cachelagring

Många wp översättningsplugins lagrar översättningar som separata inlägg, sidor och taxonomier, vilket kraftigt blåser upp databasen. Om tre eller fem språk är aktiva växer wp_posts-tabellen och dess relationer avsevärt, och jag observerar då frågehopp från cirka 4 till upp till 16 per sidvisning. Detta mönster påverkar särskilt butiker, eftersom produkter, varianter och metadata växer oproportionerligt. Jag minskar påverkan genom att aktivera selektiv strängöversättning, begränsa de språk som används och använda objektcachelagring på ett målinriktat sätt. Det hjälper också att rensa upp i revisioner, autodrafts och gamla strängposter så att indexen förblir mindre och InnoDB-bufferten fungerar mer effektivt.

HTTP-förfrågningar, tillgångar och externa tjänster

Förutom databasförfrågningar kan ytterligare HTTP-förfrågningar minskar laddningstiden, till exempel för språkbyten, stilmallar eller redaktörsintegrationer. Om en tjänst lagrar översättningar i molnet avlastas databasen, men arbetet flyttas till API-anrop och svarstider. Detta lönar sig för små sidor, men blir en flaskhals med långa texter eller många språk. Lokalt lagrade plugins drar nytta av cacheträffar så snart återkommande sidvisningar inträffar, men kräver ren tillgångshantering. Jag minimerar effekten genom att paketera skript, inaktivera oanvända komponenter och rendera CSS kritiskt.

Multisite-strategi med MultilingualPress

En installation med flera webbplatser distribuerar språk till separata Platser, Detta innebär att varje instans använder sin egen databas och undviker kollisioner mellan frågor. Detta gör att antalet frågor per sida blir lågt, även om det finns många språk, vilket håller svarstiden stabil. Priset för detta är ytterligare administrativa insatser för teman, plugins och användarrättigheter, men det lönar sig för större projekt. Jag väljer multisite när det finns många språk, olika innehåll eller olika team inblandade. Om du vill jämföra alternativen först kan du hitta Verktygsjämförelse 2025 ett bra hjälpmedel för beslutsfattande.

Jämförelse av uppmätta värden: plugins och nyckeltal

Jag betygsätter Effekt alltid baseras på konkreta nyckeltal, eftersom subjektiv uppfattning är bedräglig. Medianbelastningstiden, antalet förfrågningar, överföringsstorleken och antalet databasfrågor är avgörande. I följande tabell sammanfattas typiska resultat från testscenarier som jag använder vid revisioner. Värdena visar att smala arkitekturer erbjuder fördelar för samma funktion och behöver cachelagras mindre aggressivt. Speciellt i projekt med mycket dynamiskt innehåll är ett lågt antal frågor viktigare än den råa genomströmningen.

Plugin	Median laddningstid	HTTP-förfrågningar	Filstorlek	DB-frågor
Inget insticksprogram	0,764 s	14	81 KB	4
WPML	0,707 s	18	82 KB	16
Polylong	0,712 s	15	79 KB	4
ÖversättPress	1,026 s	22	127 KB	7
Weglot	0,987 s	19	138 KB	4

Praktisk tuning: cachelagring, databas och media

Jag börjar varje avstämning med en ren Caching, eftersom det är här de största tidsbesparingarna per samtal kommer ifrån. Sid- och fragmentcachar minskar PHP-körtiden, medan objektcachning fångar upp återkommande frågor. Samtidigt håller jag strängöversättningar smala, avaktiverar automatiska skanningar och tar bort gamla poster så att indexen förblir snabba. Ett CDN för bilder, webbteckensnitt och skript minskar märkbart latensen beroende på region, vilket direkt påskyndar flerspråkig trafik. Om du vill gå djupare in i fallgroparna kan du dra nytta av mina anteckningar om Anti-mönster för prestanda, som jag regelbundet ser i projekt.

WooCommerce-specifika stötestenar

Butikerna lägger till sina egna Last, eftersom produkter, varianter och filter växer per språk och mångdubblar antalet förfrågningar. Jag ser ofta att det tar ytterligare 0,3 sekunder per språk med omfattande kataloger, vilket leder till märkbara avbrott för mobila besökare. Produktwebbplatskartor, brödsmulor och facetter kan sakta ner saker och ting avsevärt om databasen redan är uppblåst. Jag bromsar detta genom att ta bort onödiga metafält från översättningen, bygga om sökindex och separera varukorgens cache. Jag har också satt upp en regel: strängöversättning endast för texter som faktiskt är synliga, inte för tekniska metadata.

Urvalsguide: Vilken lösning passar för vilket projekt?

Jag beslutar pragmatiskt enligt Profil av webbplatsen, eftersom inget plugin tjänar alla syften samtidigt. Mindre webbplatser drar nytta av Polylang eftersom det förblir lättviktigt och genererar få frågor. För stora projekt med många innehållstyper använder jag WPML, men jag är noga med tuning och tydliga strängstrategier. Om du prioriterar teamarbete och låg serverbelastning fungerar en molnstrategi som Weglot bra så länge API-latenserna förblir under kontroll. För innehållsteam som vill spela ut onpage-signaler på ett rent sätt har jag en kompakt SEO-guide som undviker typiska fallgropar.

Övervakning: mäta, testa, optimera

Jag mäter verklige prestanda med upprepade tester, eftersom cacher, nätverkseffekter och outliers annars är vilseledande. Det är viktigt med konsekventa testförhållanden, identiska sidor och tydliga budgetar för TTFB, LCP och requests. Jag sätter målvärden för varje språk så att utrullningen av ytterligare översättningar inte i hemlighet driver upp laddningstiden. Ett staging-system förhindrar att plugin-uppdateringar försämrar mätvärdena innan de går live. Jag följer också upp Core Web Vitals per språk för att kunna upptäcka konverteringsförluster i ett tidigt skede och vidta riktade motåtgärder.

Jämförelse av arkitektur: WPML, Polylang, TranslatePress, Weglot

Arkitekturen för översättningsprogrammet avgör var kostnaderna uppstår. WPML duplicerar innehåll som oberoende inlägg och länkar dem med hjälp av mappningstabeller; parallellt hamnar strängar i separata tabeller. Detta ökar planeringens tillförlitlighet, men kostar frågor och alternativkostnader. Polylang knyter i första hand språk till en taxonomi och arbetar med enkla relationer, vilket gör det lättare att ställa frågor, så länge synkroniseringar (t.ex. för media) konfigureras på ett medvetet sätt. TranslatePress skriver översättningar i sina egna tabeller och renderar många saker vid körning, vilket gör ändringar i frontend snabba och enkla, men PHP-tiden kan öka om sidorna varierar mycket. Weglot håller översättningar i molnet på serversidan och injicerar dem i frontend; den lokala databasen förblir liten, men kostnaderna flyttas till API-latenstider och ytterligare förfrågningar. Jag väljer modell enligt innehållstyper: Många anpassade inläggstyper och komplexa taxonomier är mer till förmån för Polylang eller Multisite, mycket texttunga sidor utan speciell logik kan kontrolleras väl med WPML eller TranslatePress, molnmetoder är värda för team utan serverunderhåll.

URL:er, Hreflang och SEO-signaler utan prestandafällor

URL-strategin har en direkt effekt på cachelagring och crawling. Underkataloger (/de/) är de mest gynnsamma ur administrativ synvinkel och kan enkelt mappas i cache-nyckeln; underdomäner (de.example.com) separeras rent, men kräver mer DNS/CDN-underhåll. Frågeparametrar (?lang=de) är enklast, men stör proxy- och edge-cacher. Jag definierar tydliga regler per projekt: Språk som sökväg, konsekventa efterföljande snedstreck, 301-omdirigeringar som är rena och inga språkbyten via JavaScript utan att ändra URL:en. Hreflang bör underhållas fullt ut per sida, inklusive x-standard. Sitemaps per språk underlättar sökmotorernas crawling och minskar antalet onödiga träffar på irrelevanta språkversioner. Viktigt: Cache-nyckeln måste innehålla språket, annars får fel användare fel version. Cookies varierar med standardplugins (t.ex. wpll_language), som ofta ignoreras i cacher - här definierar jag en „Vary by Cookie“-regel eller, bättre, arbetar rent sökvägsbaserat.

Cachelagring per språk: Edge, Vary och Prewarm

Effektiv cachelagring avgör om Multilingual förblir snabb. Jag förlitar mig på:

Sidcache med „Vary on Language“ (sökvägsprefix i stället för cookie) för maximal träfffrekvens.
Cachelagring av fragment för återkommande widgetar (t.ex. menyer) så att översättningslogiken inte renderas vid varje anrop.
Edge-cache i CDN med kort TTL plus „stale-while-revalidate“ för att undvika att straffa kalla språk.
Riktad förvärmning av viktiga landningssidor per språk i enlighet med utplaceringar.

I frontend minskar jag renderingsblockeringen genom att hålla kritiska element inline och ladda resten asynkront. HTTP/2/3 tillåter många parallella förfrågningar, så i stället för att bunta ihop prioriterar jag blint allt i en fil. Jag delar upp teckensnitt per skriftsystem (latin, kyrilliska, CJK) så att inte alla språk laddar samma stora teckensnitt. För dynamiska sidor med en varukorg eller personalisering separerar jag strikt cachezonerna, annars kolliderar valutor, språk och användartillstånd.

Serverkonfiguration och PHP-tuning som verkligen fungerar

Det bästa valet av plugin kommer att falla platt om stacken saktar ner dig. Jag planerar med PHP 8.2+, OPcache aktiverat, tillräckligt med minne och en FPM-pool som matchar trafiken och CPU (pm dynamisk, begränsad max_children). Objektcachelagring via Redis minskar rundresor dramatiskt - nyckeln är att undvika spolningsorgier och att definiera cachegrupper med språkkontext på ett rent sätt. På databassidan håller jag InnoDB-bufferten tillräckligt stor för att passa arbetsdata och aktiverar långsamma frågeloggar för att göra språkrelaterade „N+1“-mönster synliga. Jag undviker transienter med långa körtider och „autoload = yes“ i alternativtabellen; autoload hör bara hemma i poster som verkligen behövs. Bakgrundsjobb körs via cron i det verkliga systemet, inte bara WP-cron, så att översättningsköer kan planeras och bearbetas utanför topptider.

Arbetsflöde, cron och prebuilds för smidigt redaktionellt arbete

Många bromsar uppstår i vardagen: automatiska strängskanningar vid varje ändring, livesynkronisering av menyer eller media och okoordinerade batchöversättningar. Jag flyttar dyra operationer till tidsfönster med lågtrafik, avaktiverar realtidsscanningar och arbetar med manuella synkroniseringar före releaser. Stora webbplatser drar nytta av prebuilds: Jag förrenderar de viktigaste mallarna per språk, värmer upp cacheminnet och kontrollerar LCP/TTFB mot budget. Jag integrerar översättnings-API:er som en kö, inte inline i redigeraren - strategier för timeout och omförsök förhindrar att enskilda språk blockerar hela publiceringsprocessen. Förändringsfönster per team och tydliga ansvarsområden per språk undviker dubbelarbete och minskar kaoset i metadata.

Media, typsnitt och layout: språkspecifik, men slimmad

Medierna blir snabbt många om varje tillgång dupliceras för varje språk. Jag översätter främst metadata (alt, titel, bildtexter) och delar binära filer, förutsatt att motivet är identiskt. För språk med andra skriftsystem använder jag mina egna, lätta teckensnittsundergrupper och variabla teckensnitt med riktat axelutnyttjande. RTL-språk kräver separata stilar; jag separerar den extra CSS-belastningen istället för att leverera den globalt. Jag gör bilder identiskt responsiva för varje språk (srcset, storlekar), men med språkspecifika överlägg endast där det ger konvertering. För LCP-element ställer jag in fetchpriority=high och ser till att detta gäller konsekvent i alla språkvarianter - detta är en vanlig avvikelse i revisioner.

Databasteknik: index, autoload och hygien

Fler språk utan indexplanering är en prestandamultiplikator i fel riktning. Jag kontrollerar om de fält som används av plugins i postmeta, termmeta eller mina egna tabeller har lämpliga sammansatta index (t.ex. language_code + object_id). För mycket stora kataloger minskar jag aggressivt revisionerna, sätter upp regelbundna rensningar av föräldralösa och föräldralösa strängposter och är uppmärksam på autoload-storleken i alternativtabellen. Små justeringar har också effekt: gränser för heartbeat i redigeraren, avaktiverade kommentarsräkningar i arkiv och undvikande av dyra „LIKE %%“-frågor på stora metatabeller. Resultatet är reproducerbart lägre frågetider, särskilt på produktlistor och facettfilter.

Typiska felmönster och snabba lösningar

Felaktig cache-nyckelSpråk saknas i nyckeln, användare ser blandat innehåll. Lösning: Använd sökvägsprefix eller ställ in „Vary on Cookie“ på rätt sätt.
N+1 förfrågningarSträngöversättningar per menyalternativ individuellt. Lösning: Aktivera förladdning/batchning, fragment-cache menyutmatning.
Inflaterade optionerAutoload-strängar växer i tysthet. Lösning: Granska autoload=yes, arkivering av gamla domäner/språk.
API-flaskhalsarMolnöversättning seriellt och utan cache. Lösning: Definiera TTL, backoff-strategier, aktivera edge-cache.
WooCommerce vagnsfragmentKringgå varje cache på alla språk. Lösning: Kontrollera strategin för fragmentering av kundvagnar, cacha separata slutpunkter per språk.

För diagnos använder jag query- och hook-analyser, jämför spårningsdata per språk och isolerar avvikelser i editorn och frontend. Bara några få riktade korrigeringar halverar ofta PHP-tiden utan att spara på innehållet.

Kompakt sammanfattning för snabba beslut

Fler språk betyder mer Arbetskraft för databas, förfrågningar och PHP, men smarta val och inställningar håller sidorna snabba. Jag planerar först arkitekturen och målvärdena, sedan väljer jag plugin efter hur det hanterar frågor, tillgångar och strängar. Multisite fungerar bra för flerspråkighet med heterogent innehåll, ett lätt plugin är tillräckligt för magra webbplatser. Om du använder butiksfunktioner bör du ta synkroniseringen av produktdata och filter på största allvar och installera cachelagring redan från början. På så sätt kan du utöka räckvidden för ditt innehåll utan att äventyra användarnas tålamod eller rankningen.