I plugin multilingua di WordPress aumentano le query al database, le richieste HTTP e l'overhead di PHP. WordPress multilingue le prestazioni spesso diminuiscono in modo misurabile. Mostro chiaramente dove si perde tempo, quali architetture rallentano le cose e come posso ridurre i tempi di caricamento con misure mirate senza sacrificare la diversità linguistica.
Punti centrali
Prima di illustrare i dettagli, riassumo le leve più importanti e le inserisco in un contesto pratico. Uso volutamente una formulazione chiara, in modo che possiate prendere decisioni più rapidamente. I punti chiave che seguono riguardano la tecnologia, l'architettura e la messa a punto. In questo modo potrete riconoscere immediatamente da dove iniziare. Ciascuna affermazione si concentra su effetti misurabili e misure specifiche, che vengono poi approfondite.
- Banca datiI duplicati per lingua aumentano le query e i requisiti di memoria.
- Richieste HTTPPiù script, stili e chiamate API aumentano il tempo di caricamento.
- ArchitetturaIl multisito separa le lingue in modo pulito, ma richiede una maggiore amministrazione.
- CloudI servizi di traduzione esterni risparmiano il carico del DB, ma generano latenza.
- SintonizzazioneCaching, strategia delle stringhe e CDN riducono i tempi di attesa.
Perché i plugin di traduzione costano in termini di prestazioni
I plug-in di traduzione scavano in profondità nella WordPress perché devono fornire contenuti, stringhe, menu e permalink in modo specifico per ogni lingua. Ogni lingua aggiuntiva aumenta il numero di interrogazioni al database, perché il sistema controlla e carica le varianti di un oggetto. Ci sono anche i commutatori di lingua, gli script e gli stili aggiuntivi che generano un maggior numero di richieste HTTP per ogni visualizzazione. Nelle verifiche vedo regolarmente che il runtime PHP e il numero di opzioni caricate aumentano non appena un plugin attiva traduzioni a livello di post, tassonomie e stringhe. In assenza di ottimizzazione, questo sforzo aggiuntivo si riflette nel tempo per il primo byte, nell'avvio del rendering e nel più grande Contentful Paint.
Carico del database: duplicati, query e cache
Molti wp I plugin di traduzione memorizzano le traduzioni come post, pagine e tassonomie separate, il che gonfia notevolmente il database. Se sono attive tre o cinque lingue, la tabella wp_posts e le sue relazioni crescono in modo considerevole e si osservano salti di query da circa 4 a 16 per pagina visualizzata. Questo schema riguarda in particolare i negozi, poiché i prodotti, le varianti e i metadati crescono in modo sproporzionato. Riduco l'impatto attivando la traduzione selettiva delle stringhe, limitando le lingue utilizzate e facendo un uso mirato della cache degli oggetti. È utile anche ripulire le revisioni, gli autodraft e le vecchie voci di stringa, in modo che gli indici rimangano più piccoli e il buffer InnoDB funzioni in modo più efficiente.
Richieste HTTP, risorse e servizi esterni
Oltre alle interrogazioni del database, ulteriori HTTP-Le richieste riducono il tempo di caricamento, ad esempio per i cambi di lingua, i fogli di stile o le integrazioni di editor. Se un servizio mantiene le traduzioni nel cloud, questo alleggerisce il database, ma sposta il lavoro sulle chiamate API e sui tempi di risposta. Ciò è vantaggioso per le pagine di piccole dimensioni, ma diventa un collo di bottiglia con testi lunghi o in molte lingue. I plugin memorizzati localmente traggono vantaggio dalle visite alla cache non appena si verificano visualizzazioni ricorrenti della pagina, ma richiedono una gestione pulita delle risorse. Riduco al minimo l'effetto raggruppando gli script, disattivando i componenti inutilizzati e renderizzando i CSS in modo critico.
Approccio multisito con MultilingualPress
Un'impostazione multisito distribuisce le lingue in siti separati. Siti, Ciò significa che ogni istanza utilizza il proprio database ed evita collisioni di query. In questo modo si mantiene basso il numero di query per pagina, anche se esistono molte lingue, mantenendo stabile il tempo di risposta. Il prezzo da pagare è un ulteriore sforzo di amministrazione per i temi, i plugin e i diritti degli utenti, ma questo ripaga per i progetti più grandi. Io opto per il multisito quando ci sono molte lingue, diversi contenuti o diversi team coinvolti. Se volete prima confrontare le opzioni, potete trovare Confronto strumenti 2025 un buon aiuto per le decisioni.
Confronto dei valori misurati: plugin e cifre chiave
Tasso Prestazioni sempre basati su cifre chiave concrete, perché la percezione soggettiva è ingannevole. Il tempo di caricamento mediano, il numero di richieste, la dimensione del trasferimento e il numero di query al database sono determinanti. La tabella seguente riassume i risultati tipici degli scenari di test che utilizzo negli audit. I valori mostrano che le architetture snelle offrono vantaggi a parità di funzione e necessitano di una cache meno aggressiva. Soprattutto nei progetti con molti contenuti dinamici, un basso numero di query conta più del throughput grezzo.
| Plugin | Tempo di caricamento mediano | Richieste HTTP | Dimensione del file | Query DB |
|---|---|---|---|---|
| Nessun plugin | 0,764 s | 14 | 81 KB | 4 |
| WPML | 0,707 s | 18 | 82 KB | 16 |
| Polilungo | 0,712 s | 15 | 79 KB | 4 |
| TradurrePress | 1,026 s | 22 | 127 KB | 7 |
| Weglot | 0,987 s | 19 | 138 KB | 4 |
Messa a punto pratica: cache, database e media
Inizio ogni messa a punto con una pulizia Caching, perché è da qui che proviene il maggior risparmio di tempo per ogni chiamata. Le cache di pagine e frammenti riducono il tempo di esecuzione di PHP, mentre la cache degli oggetti intercetta le query ricorrenti. Allo stesso tempo, mantengo le traduzioni delle stringhe snelle, disattivo le scansioni automatiche e cancello le vecchie voci in modo che gli indici rimangano veloci. Un CDN per le immagini, i web font e gli script riduce sensibilmente la latenza a seconda della regione, accelerando direttamente il traffico multilingue. Se volete approfondire le insidie, vi saranno utili i miei appunti su Antipattern delle prestazioni, che vedo regolarmente nei progetti.
Ostacoli specifici di WooCommerce
I negozi aggiungono i propri Carico, perché i prodotti, le varianti e i filtri crescono per lingua e moltiplicano le query. Spesso osservo 0,3 secondi in più per lingua con cataloghi estesi, il che comporta interruzioni notevoli per i visitatori mobili. Le sitemap dei prodotti, le briciole di pane e le sfaccettature possono rallentare considerevolmente le operazioni se il database è già molto ricco. Io rallento questo processo eliminando i meta-campi non necessari dalla traduzione, ricostruendo gli indici di ricerca e separando la cache del carrello. Ho anche stabilito una regola: la traduzione delle stringhe riguarda solo i testi effettivamente visibili, non i metadati tecnici.
Guida alla selezione: quale soluzione è adatta al progetto?
Decido pragmaticamente in base a Profilo del sito web, perché nessun plugin serve a tutti gli scopi contemporaneamente. I siti più piccoli traggono vantaggio da Polylang perché rimane leggero e genera poche query. Per progetti di grandi dimensioni con molti tipi di contenuto, utilizzo WPML, ma prestando molta attenzione alla messa a punto e a chiare strategie di stringa. Se si dà priorità al lavoro di squadra e al basso carico del server, un approccio cloud come Weglot funziona bene, purché le latenze dell'API rimangano sotto controllo. Per i team di contenuti che desiderano riprodurre i segnali onpage in modo pulito, ho una soluzione compatta Guida SEO che evita le tipiche insidie.
Monitoraggio: misurare, testare, ottimizzare
Misuro realee prestazioni con test ripetuti, perché le cache, gli effetti di rete e gli outlier sono altrimenti ingannevoli. Sono importanti condizioni di test coerenti, pagine identiche e budget chiari per TTFB, LCP e richieste. Stabilisco dei valori target per ogni lingua, in modo che l'introduzione di ulteriori traduzioni non faccia aumentare segretamente il tempo di caricamento. Un sistema di staging impedisce agli aggiornamenti dei plugin di degradare i valori misurati prima della loro messa in funzione. Traccio anche i Core Web Vitals per ogni lingua, per riconoscere tempestivamente le perdite di conversione e adottare contromisure mirate.
Architettura a confronto: WPML, Polylang, TranslatePress, Weglot
L'architettura del plugin di traduzione determina dove vengono sostenuti i costi. WPML duplica i contenuti come post indipendenti e li collega utilizzando tabelle di mappatura; in parallelo, le stringhe finiscono in tabelle separate. Questo aumenta l'affidabilità della pianificazione, ma costa query e overhead di opzioni. Polylang collega principalmente le lingue a una tassonomia e lavora con relazioni semplici - snelle nella query, a patto che le sincronizzazioni (ad esempio per i media) siano deliberatamente configurate. TranslatePress scrive le traduzioni nelle proprie tabelle e rende molte cose in runtime, rendendo le modifiche al frontend facili e veloci, ma il tempo PHP può aumentare se le pagine variano molto. Weglot mantiene le traduzioni nel cloud sul lato server e le inietta nel frontend; il database locale rimane piccolo, ma i costi si spostano sulle latenze dell'API e sulle richieste aggiuntive. Scelgo il modello in base ai tipi di contenuto: Molti tipi di post personalizzati e tassonomie complesse sono più favorevoli a Polylang o Multisite, le pagine molto pesanti senza logica speciale possono essere controllate bene con WPML o TranslatePress, gli approcci cloud sono utili per i team che non hanno bisogno di manutenzione del server.
URL, Hreflang e segnali SEO senza trappole per le prestazioni
La strategia degli URL ha un effetto diretto sulla cache e sul crawling. Le sottodirectory (/de/) sono le più favorevoli in termini amministrativi e possono essere facilmente mappate nella chiave della cache; i sottodomini (de.example.com) si separano in modo pulito, ma richiedono una maggiore manutenzione DNS/CDN. I parametri di interrogazione (?lang=de) sono i più semplici, ma interferiscono con le cache proxy e edge. Definisco regole chiare per ogni progetto: Lingua come percorso, barre di separazione coerenti, reindirizzamenti 301 impostati in modo pulito e nessun cambio di lingua tramite JavaScript senza modificare l'URL. L'hreflang deve essere mantenuto completamente per ogni pagina, compreso l'x-default. Le sitemap per lingua facilitano il crawling per i motori di ricerca e riducono le visite inutili alle versioni linguistiche non pertinenti. Importante: la chiave della cache deve contenere la lingua, altrimenti l'utente sbagliato riceverà la versione sbagliata. I cookie variano con i plugin standard (ad es. wpll_language), che spesso vengono ignorati nelle cache - qui definisco una regola „Vary by Cookie“ o, meglio, lavoro puramente basato sul percorso.
Caching per lingua: Edge, Vary e Prewarm
Una cache efficace determina la velocità di Multilingual. Mi affido a:
- Cache della pagina con „Vary on Language“ (prefisso del percorso anziché cookie) per ottenere il massimo tasso di risposta.
- Caching dei frammenti per i widget ricorrenti (ad esempio, i menu), in modo che la logica di traduzione non venga resa a ogni chiamata.
- Edge cache nella CDN con TTL breve e „stale-while-revalidate“ per non penalizzare le lingue fredde.
- Preriscaldamento mirato di importanti landing page per lingua in base alle implementazioni.
Nel frontend, riduco il blocco del rendering mantenendo gli elementi critici in linea e caricando il resto in modo asincrono. HTTP/2/3 consente molte richieste parallele, quindi invece di raggruppare, metto tutto in ordine di priorità in un unico file. Sottoinsieme di font per sistema di scrittura (latino, cirillico, CJK), in modo che non tutte le lingue carichino lo stesso font grande. Per le pagine dinamiche con un carrello o una personalizzazione, separo rigorosamente le zone di cache, altrimenti valute, lingue e stati dell'utente si scontrano.
Configurazione del server e messa a punto del PHP che funziona davvero
La migliore scelta di un plugin non sarà all'altezza se lo stack vi rallenterà. Io progetto con PHP 8.2+, OPcache attivato, memoria sufficiente e un pool FPM che corrisponda al traffico e alla CPU (pm dinamico, max_children limitato). La cache degli oggetti tramite Redis riduce drasticamente i viaggi di andata e ritorno - la chiave è evitare le orge di flush e definire in modo pulito i gruppi di cache con il contesto linguistico. Per quanto riguarda il database, mantengo il buffer InnoDB abbastanza grande da contenere i dati di lavoro e attivo i log delle query lente per rendere visibili i modelli „N+1“ relativi alla lingua. Evito i transitori con tempi di esecuzione lunghi e „autoload = yes“ nella tabella delle opzioni; l'autoload appartiene solo alle voci che sono veramente necessarie. I lavori in background vengono eseguiti tramite cron del sistema reale, non solo di WP, in modo che le code di traduzione possano essere pianificate ed elaborate al di fuori degli orari di punta.
Flusso di lavoro, cron e precompilazioni per un lavoro editoriale senza intoppi
Nella vita di tutti i giorni si presentano molti freni: scansioni automatiche delle stringhe a ogni modifica, sincronizzazione live di menu o media e traduzioni batch non coordinate. Sposto le operazioni costose in finestre temporali non di punta, disattivo le scansioni in tempo reale e lavoro con sincronizzazioni manuali prima dei rilasci. I siti di grandi dimensioni traggono vantaggio dalle pre-costruzioni: Eseguo il pre-rendering dei modelli più importanti per lingua, riscaldo le cache e controllo LCP/TTFB rispetto ai budget. Integro le API di traduzione come coda, non in linea nell'editor - le strategie di timeout e retries impediscono alle singole lingue di bloccare l'intero processo di pubblicazione. Finestre di modifica per team e responsabilità chiare per lingua evitano la duplicazione del lavoro e riducono il caos dei metadati.
Supporti, caratteri e layout: specifici per la lingua, ma snelli
I media si moltiplicano rapidamente se ogni risorsa viene duplicata per ogni lingua. Traduco principalmente i metadati (alt, titolo, didascalie) e mantengo i file binari condivisi, purché il motivo sia identico. Per le lingue con altri sistemi di scrittura, mi affido ai miei sottoinsiemi di font leggeri e a font variabili con utilizzo mirato degli assi. Le lingue RTL richiedono stili separati; separo il carico aggiuntivo di CSS invece di fornirlo globalmente. Renderizzo le immagini in modo identico per ogni lingua (srcset, dimensioni), ma con sovrapposizioni specifiche per la lingua solo dove ciò comporta una conversione. Per gli elementi LCP, imposto fetchpriority=high e mi assicuro che si applichi in modo coerente in tutte le varianti linguistiche - si tratta di un'anomalia frequente nelle verifiche.
Ingegneria dei database: indici, autoload e igiene
Più lingue senza pianificazione degli indici sono un moltiplicatore di prestazioni nella direzione sbagliata. Verifico se i campi utilizzati dai plugin in postmeta, termmeta o nelle mie tabelle hanno indici compositi adeguati (ad esempio language_code + object_id). Per i cataloghi molto grandi, riduco in modo aggressivo le revisioni, imposto pulizie regolari degli orfani e delle voci di stringa orfane e faccio attenzione alla dimensione del caricamento automatico della tabella delle opzioni. Anche piccoli aggiustamenti hanno effetto: limiti per il battito cardiaco nell'editor, conteggio dei commenti disattivato negli archivi ed evitare costose query „LIKE %%“ su grandi meta tabelle. Il risultato è una riduzione riproducibile dei tempi di interrogazione, soprattutto per gli elenchi di prodotti e i filtri a faccette.
Modelli di errore tipici e rimedi rapidi
- Chiave cache errataLa lingua manca nella chiave, gli utenti vedono contenuti misti. Soluzione: utilizzare i prefissi di percorso o impostare correttamente „Vary on Cookie“.
- N+1 interrogazioniTraduzioni di stringhe per ogni singola voce di menu. Soluzione: Attivare il precaricamento/batching e la memorizzazione nella cache dei frammenti del menu.
- Opzioni gonfiateLe stringhe di autoload crescono silenziosamente. Soluzione: rivedere autoload=yes, archiviazione dei vecchi domini/lingue.
- Colli di bottiglia dell'APITraduzione cloud seriale e senza cache. Soluzione: definire TTL, strategie di backoff, attivare la cache del bordo.
- Frammenti di carrello WooCommerceBypassare ogni cache in tutte le lingue. Soluzione: controllare la strategia di frammentazione del carrello, memorizzare nella cache endpoint separati per ogni lingua.
Per la diagnosi, mi affido alle analisi delle query e degli hook, confronto i dati di tracciamento per lingua e isolo i valori anomali nell'editor e nel frontend. Poche correzioni mirate spesso dimezzano il tempo di PHP senza risparmiare sul contenuto.
Sintesi compatta per decisioni rapide
Più lingue significano più Lavoro per il database, le richieste e il PHP, ma una selezione intelligente e la messa a punto mantengono le pagine veloci. Prima pianifico l'architettura e i valori target, poi scelgo il plugin in base a come gestisce le query, le risorse e le stringhe. Multisite funziona bene per il multilinguismo con contenuti eterogenei, un plugin leggero è sufficiente per i siti più semplici. Se utilizzate le funzioni del negozio, dovreste prendere molto sul serio la sincronizzazione dei dati dei prodotti e dei filtri e installare la cache fin dall'inizio. In questo modo estenderete la portata dei vostri contenuti senza mettere a rischio la pazienza degli utenti e le classifiche.
