"Ik zet de website niet in meerdere talen omdat de plugin hem gaat vertragen." Het is een van de meest herhaalde bezwaren en een van de slechtst gegronde: in de meeste audits is de taalplug-in dat wel de vierde factor, ver achter de beelden en de accommodatie.
Dat betekent niet dat het niet weegt. Het betekent dat het raadzaam is om het op uw website te meten voordat u de verkeerde verdachte de schuld geeft.
Tot het punt: Een meertalige plug-in voegt op elke pagina zoekopdrachten toe aan de database, en op sites met veel talen wordt deze ook weergegeven. Maar als het laden van uw website drie seconden duurt, is de taalplug-in niet de oorzaak: het zijn vrijwel altijd de niet-geoptimaliseerde afbeeldingen. Meten voordat u beslist.
Wat doet elke architectuur precies?
Ze wegen niet allemaal hetzelfde, en het verschil zit in de manier waarop ze de vertalingen opslaan.
Inheemse taxonomie (Polylang)
Declareer de taal als een andere WordPress-taxonomie. Elke vertaalde inzending is een normale inzending met een toegewezen term. WordPress doet wat het al weet, met zijn eigen geoptimaliseerde queries en caching. Het is de lichtste architectuur, en het is geen mening: het voegt minder machines toe dan enig ander.
Eigen tabellen (WPML)
Maak uw tabellen om vertalingen met elkaar in verband te brengen en tekenreeksen op te slaan. Krachtiger: biedt de beheerder toegang tot statussen en batchtaken, maar elke pagina heeft extra vragen nodig om te bepalen welke versie moet worden weergegeven en welke links moeten worden getekend. Bij grote sites met zes of zeven talen is dit het meest merkbaar.
Tabla de cadenas (TranslatePress, WP-Translate)
Ze houden een tabel bij met vertaalde tekenreeksen en verwijzen ernaar bij het schilderen van de pagina. De kosten hangen bijna volledig af van het feit of die er zijn cache in het geheugen: met de vertaalkaart in de cache, wordt deze gelezen; zonder dit is het één zoekopdracht voor elk bezoek.
Externe dienst (Weglot, GTranslate)
Ze raken uw server praktisch niet: het werk wordt gedaan door de infrastructuur ervan. In ruil daarvoor ben je afhankelijk van hun responstijd en zijn jouw vertalingen niet van jou, zoals we zien in Weglot vs WPML.
Hoe je het echt kunt meten op je website
De enige eerlijke manier is om dezelfde pagina te vergelijken met de plug-in actief en gedeactiveerd. Tien minuten:
- Kiezen een representatieve pagina: niet de omslag (meestal atypisch), maar een normale instap- of productfiche.
- Meet, terwijl de plug-in actief is, drie keer achter elkaar met PageSpeed Insights of WebPageTest en noteer de TTFB (tijd tot eerste byte) en de LCP.
- Schakel de taalplug-in uit en wis de volledige cache.
- Meet dezelfde URL nog drie keer.
- Vergelijk de medium, niet het beste, noch het slechtste merk.
- Activeer de plug-in opnieuw.
Ojo: doe het in een proefexemplaar, niet in productie. Als u de meertalige plug-in op een live website deactiveert, zijn de vertaalde URL's tijdelijk onbruikbaar, en als Google op dat moment passeert, vindt u 404's op geïndexeerde pagina's. Het is nooit de tijd waard die u bespaart.
Interpreteer het resultaat:
- Minder dan 50 ms verschil in TTFB: de plug-in is niet jouw probleem. Kijk ergens anders.
- Tussen 50 en 200 ms: Het is zwaar, maar er is ruimte voor optimalisatie voordat er van gereedschap wordt gewisseld.
- Meer dan 300 ms: verdient onderzoek. Dit is meestal een verkeerd geconfigureerde cache, niet de plug-in zelf.
Wat een website echt traag maakt
| Oorzaak | Frequentie | Te doen |
|---|---|---|
| Niet-geoptimaliseerde afbeeldingen | Zeer hoog | WebP, juiste maten, loading="lazy" |
| Verzadigde gedeelde hosting | Alt | Bekijk de TTFB; plannen of aanbieders wijzigen |
| Lay-out met CSS en JS als reserve | Alt | Verwijder ongebruikte bronnen |
| Te veel actieve plug-ins | Media | Controleer en verwijder wat niet wordt gebruikt |
| Geen paginacache | Media | Activeer de cache en controleer of deze werkt |
| Taal plug-in | Baja | Objectcache; controleer het aantal talen |
De volgorde is belangrijk. Het optimaliseren van de taalplug-in als je 3 MB ongecomprimeerde afbeeldingen hebt, werkt op de verkeerde plaats.
Hoe u de kosten van meertalig kunt verlagen
Als u al heeft gemeten en de plug-in weegt in uw geval mee:
1. Paginacache, goed geconfigureerd per taal. Het is degene die veruit de meeste impact heeft. Een slecht geconfigureerde caching-plug-in op een meertalige site kan de in de cache opgeslagen versie van de verkeerde taal weergeven; Controleer of uw caching-plug-in de talen begrijpt en bewaar voor elke taal een kopie.
2. Objectcache (Redis of Memcached). Dit is waar het het meest opvallend is in tekenreekstabelarchitecturen: de vertaalkaart wordt één keer geladen en opnieuw gebruikt. Veel fatsoenlijke hosts bieden het aan met activering met één klik.
3. Minder talen. De kosten stijgen met het aantal actieve talen, niet met het aantal bezoeken. Vijf half onderhouden talen wegen evenveel als vijf goed onderhouden talen en presteren veel minder. Hoe u dit kunt beslissen met gegevens, in hoeveel talen moet uw website hebben.
4. Optimaliseer eerst bovenstaande. De afbeeldingen, de hosting en de lay-outontwerper staan voorop. En afbeeldingen op een meertalige website hebben hun eigen truc: dezelfde afbeelding werkt voor alle talen, dus als je deze eenmaal optimaliseert, kom je al een heel eind. Wij dekken het in meertalige beeld- en metadata-optimalisatie.
Advies: controleer dat jij cache-plug-in begrijpt talen vóór iets anders. Het is de fout die het vaakst wordt verward met "de taalplug-in is traag": de cache slaat één versie op en biedt deze aan iedereen weer, waardoor sommige bezoekers de verkeerde taal zien en de plug-in uiteindelijk twee keer zo hard werkt. Bijna alle caching plugins hebben hiervoor een specifieke instelling.
De kosten van het niet vertalen
Het is de moeite waard om het cijfer in context te plaatsen. Uitgaande van een redelijk worst case (200 ms meer TTFB) duurt het zo lang om twee slecht geoptimaliseerde afbeeldingen te laden. In ruil daarvoor bestaat uw website op een markt waar deze voorheen niet bestond.
Als prestatie uw voornaamste zorg is, is de juiste volgorde: eerst de bovenkant van de tabel optimaliseren, later meten en beslissen met cijfers. Er is vrijwel altijd voldoende ruimte.
WP-Translate slaat de kaart met vertalingen op in het geheugen en in de transiënten, zodat de meeste bezoeken de database niet raadplegen voor vertalingen. Je kunt het zelf meten met de gratis versie door de bovenstaande methode te volgen, wat het enige is dat deze vraag echt beantwoordt voor uw website.
Veelgestelde vragen
Wat is de snelste meertalige plug-in?
Polylang, voor architectuur. Als je enige prioriteit prestatie is en je iemand hebt om elke taal te schrijven, is het moeilijk te verslaan. De alternatieven zijn binnen Polylang-alternatieven.
Heeft dit invloed op Core Web Vitals?
Het kan de TTFB beïnvloeden, die het LCP beïnvloedt. Het heeft geen invloed op CLS of INP, die afhankelijk zijn van het thema en JavaScript.
Zijn meer talen langzamer?
Ja, maar niet lineair. Wat met elke taal groeit, is het werk van het oplossen van koppelingen en het schilderen van de selector. Content in talen die niemand bezoekt kost niets.
Wat moet ik doen als ik een CDN gebruik?
Het helpt veel, zolang het maar is geconfigureerd om op taal te cachen. Als u niet taalgevoelig bent, kan de verkeerde versie optreden: hetzelfde probleem als met paginacache, maar moeilijker te detecteren.
Lees verder
Dit stuk maakt deel uit van de gids WordPress meertalig, waar de volledige rondleiding is: URL-structuur, plug-inkeuze, automatische vertaling, SEO en budget.
- hreflang met Yoast SEO – wat het werkelijk omvat en wat u moet voltooien
- dubbele inhoud op meertalige websites – wanneer Google u niet bestraft en wanneer dat wel het geval is
- meertalige SEO-fouten – 9 meertalige SEO-fouten die een website doen zinken (en hoe je ze vandaag nog kunt detecteren)