"Non inserisco il sito in più lingue perché il plugin lo rallenterebbe." È una delle obiezioni più ripetute e una delle peggio fondate: nella maggior parte degli audit lo è il plugin linguistico il quarto fattore, molto indietro rispetto alle immagini e alla sistemazione.
Ciò non significa che non pesi. Ciò significa che è consigliabile misurarlo sul proprio sito web prima di incolpare il sospettato sbagliato.
Al punto: Un plug-in multilingue aggiunge query al database su ogni pagina e mostra i siti con molte lingue. Ma se il tuo sito web impiega tre secondi a caricarsi, la causa non è il plugin della lingua: quasi sempre sono le immagini non ottimizzate. Misurare prima di decidere.
Cosa fa esattamente ciascuna architettura?
Non tutti hanno lo stesso peso e la differenza sta nel modo in cui salvano le traduzioni.
Tassonomia nativa (Polylang)
Dichiara la lingua come un'altra tassonomia di WordPress. Ogni voce tradotta è una voce normale con un termine assegnato. WordPress fa quello che già sa fare, con le proprie query ottimizzate e il caching. È l'architettura più leggera, e non è un'opinione: aggiunge meno macchinari di qualunque altro.
Proprie tabelle (WPML)
Crea le tue tabelle per mettere in relazione le traduzioni e memorizzare le stringhe. Più potente: consente al gestore, agli stati, ai lavori batch, ma ogni pagina necessita di query aggiuntive per decidere quale versione servire e quali collegamenti dipingere. Nei siti di grandi dimensioni con sei o sette lingue è dove è più evidente.
Tabella delle cadenze (TranslatePress, WP-Translate)
Mantengono una tabella delle stringhe tradotte e fanno riferimento ad essa quando dipingono la pagina. Il costo dipende quasi interamente dalla presenza o meno cache in memoria: con la mappa di traduzione memorizzata nella cache, è una lettura; senza di essa, è una query per ogni visita.
Servizio esterno (Weglot, GTranslate)
Praticamente non toccano il tuo server: il lavoro è svolto dalla sua infrastruttura. In cambio, dipendi dai loro tempi di risposta e le tue traduzioni non sono tue, come vediamo in Weglot vs WPML.
Come misurarlo realmente sul tuo sito web
L'unico modo onesto è confrontare la stessa pagina con il plugin attivo e disattivato. Dieci minuti:
- Scegliere una pagina rappresentativa: non la copertina (solitamente atipica), ma una normale voce o scheda prodotto.
- Con il plugin attivo, misura tre volte di seguito con PageSpeed Insights o WebPageTest e annota il TTFB (tempo al primo byte) e il LCP.
- Disabilita il plug-in della lingua e svuota l'intera cache.
- Misura lo stesso URL altre tre volte.
- Confronta il medio, né la marca migliore né quella peggiore.
- Riattiva il plugin.
Ojo: fallo in una copia di prova, non in produzione. La disattivazione del plug-in multilingue su un sito Web live lascia temporaneamente inutilizzabili gli URL tradotti e, se Google passa in quel momento, troverai 404 sulle pagine indicizzate. Il tempo che risparmi non vale mai la pena.
Interpretare il risultato:
- Meno di 50 ms di differenza nel TTFB: il plugin non è un tuo problema. Guarda altrove.
- Tra 50 e 200 ms: È pesante, ma c'è spazio per l'ottimizzazione prima di cambiare strumento.
- Più di 300 ms: merita un'indagine. Di solito si tratta di una cache configurata in modo errato, non del plugin stesso.
Ciò che rende davvero lento un sito web
| Causa | Frequenza | Fare |
|---|---|---|
| Immagini non ottimizzate | Molto alto | WebP, dimensioni corrette, loading="lazy" |
| Hosting condiviso saturo | Alta | Guarda il TTFB; cambiare piani o fornitori |
| Layout con CSS e JS di riserva | Alta | Elimina le risorse inutilizzate |
| Troppi plugin attivi | Media | Controlla e rimuovi ciò che non viene utilizzato |
| Nessuna cache della pagina | Media | Attiva la cache e verifica che funzioni |
| Plug-in per la lingua | Baja | Cache degli oggetti; controllare il numero di lingue |
L'ordine conta. L'ottimizzazione del plugin della lingua quando hai immagini non compresse da 3 MB funziona nel posto sbagliato.
Come ridurre il costo del multilingue
Se hai già misurato e il plugin fa al caso tuo:
1. Cache della pagina, ben configurata per lingua. È quello che ha di gran lunga il maggiore impatto. Un plug-in di memorizzazione nella cache mal configurato su un sito multilingue potrebbe fornire la versione memorizzata nella cache della lingua sbagliata; Verifica che il tuo plug-in di memorizzazione nella cache comprenda le lingue e salva una copia per ciascuna di esse.
2. Cache degli oggetti (Redis o Memcached). È qui che è più evidente nelle architetture di tabelle di stringhe: la mappa di traduzione viene caricata una volta e riutilizzata. Molti host decenti lo offrono con l'attivazione con un clic.
3. Meno lingue. Il costo cresce con il numero di lingue attive, non con il numero di visite. Cinque lingue mantenute a metà pesano quanto cinque lingue ben mantenute e hanno prestazioni molto inferiori. Come deciderlo con i dati, in quante lingue dovrebbe avere il tuo sito web.
4. Ottimizza prima quanto sopra. Le immagini, l'hosting e il progettista del layout vengono prima di tutto. E le immagini su un sito web multilingue hanno il loro trucco: la stessa immagine funziona per tutte le lingue, quindi ottimizzarla una volta è molto utile. Lo copriamo ottimizzazione di immagini e metadati multilingue.
Consiglio: controlla che tu il plug-in della cache comprende le lingue prima di ogni altra cosa. È l'errore che più spesso viene confuso con "il plugin della lingua è lento": la cache salva una sola versione e la rende disponibile a tutti, quindi alcuni visitatori vedono la lingua sbagliata e il plugin finisce per lavorare il doppio. Quasi tutti i plugin di caching hanno un'impostazione specifica per questo.
Il costo della mancata traduzione
Vale la pena contestualizzare la figura. Supponendo un ragionevole caso peggiore, ovvero 200 ms in più di TTFB, questo è il tempo necessario per caricare due immagini scarsamente ottimizzate. In cambio, il tuo sito web esiste in un mercato in cui prima non esisteva.
Se la performance è la tua preoccupazione principale, l'ordine corretto è: ottimizzare prima la parte superiore della tabella, misurare poi e decidere con i numeri. C'è quasi sempre molto spazio.
WP-Translate memorizza nella cache la mappa delle traduzioni in memoria e transitorie, in modo che la maggior parte delle visite non consulti il database per le traduzioni. Puoi misurarlo tu stesso con il versione gratuita seguendo il metodo sopra, che è l'unica cosa che risponde veramente a questa domanda per il tuo sito web.
Domande frequenti
Qual è il plugin multilingue più veloce?
Polylang, per l'architettura. Se la tua unica priorità sono le prestazioni e hai qualcuno con cui scrivere in ogni lingua, è difficile da battere. Le alternative ci sono Alternative a Polylang.
Influisce sui Core Web Vitals?
Può influenzare il TTFB, che influenza l’LCP. Non influisce su CLS o INP, che dipendono dal tema e da JavaScript.
Più lingue sono più lente?
Sì, ma non in modo lineare. Ciò che cresce con ogni lingua è il lavoro di risoluzione dei collegamenti e di pittura del selettore. I contenuti nelle lingue che nessuno visita non costano nulla.
Cosa succede se utilizzo un CDN?
Aiuta molto, purché sia configurato per memorizzare nella cache in base alla lingua. Se non sei sensibile alla lingua, potrebbe essere pubblicata la versione sbagliata: lo stesso problema della cache delle pagine, ma più difficile da rilevare.
Continua a leggere
Questo pezzo fa parte della guida WordPress multilingue, dove si trova il tour completo: struttura URL, scelta plugin, traduzione automatica, SEO e budget.
- hreflang con Yoast SEO - cosa copre realmente e cosa devi completare
- duplicare contenuti su siti web multilingue - quando Google non ti penalizza e quando lo fa
- Errori SEO multilingue — 9 errori SEO multilingue che affondano un sito web (e come rilevarli oggi)