Aggiungi come fonte preferita su Google
Consideriamo questo scenario. Il tuo nuovo chatbot WooCommerce supera tutti i test. Risponde alle domande sui prodotti, aiuta gli acquirenti a confrontare le opzioni e risponde così velocemente che nessuno si preoccupa delle prestazioni.
Il problema non salta all’occhio finché il negozio non ha un pomeriggio di grande affluenza. Il checkout inizia a richiedere un po’ più di tempo e i tempi di risposta aumentano man mano che i thread PHP raggiungono la capacità massima. All’inizio, il rallentamento sembra il risultato di un picco di traffico, ma il numero di visitatori è più o meno lo stesso della settimana precedente. Ciò che è cambiato è la quantità di lavoro che il server svolge durante ogni visita.
Ogni scambio con il chatbot può attivare una chiamata API in tempo reale che passa attraverso WordPress, aggira la cache della pagina e occupa un thread PHP mentre il fornitore del modello genera la sua risposta. Potrebbe anche interrogare il database per i dettagli del prodotto, la cronologia delle conversazioni o altri elementi di contesto. L’acquirente vede arrivare una risposta in due secondi. Il server vede un thread che non può usare per nient’altro in quel lasso di tempo.
Questa questione di infrastruttura sta diventando sempre più difficile da evitare. WordPress 7.0 ha integrato l’AI nel core tramite un client AI indipendente dal fornitore, insieme all’API Abilities e a un hub centrale di connettori.
La stessa pressione può derivare da funzionalità che a prima vista sembrano molto diverse. La ricerca con l’AI, i consigli sui prodotti, i contenuti personalizzati, gli strumenti editoriali e le integrazioni con gli agenti interagiscono ciascuno con WordPress a modo proprio. Sapere se funzionano nella dashboard, sul front-end o tramite un’API (e se le loro richieste possono essere memorizzate nella cache) ti aiuta a pianificare le risorse del server di cui avranno bisogno.
Come si presenta effettivamente l’AI di WordPress su un sito live
L’AI su WordPress non è un unico carico di lavoro. Dove viene eseguita la funzionalità, quando viene eseguita e se è un visitatore ad attivarla sono tutti fattori che influenzano il profilo dell’infrastruttura.
Chatbot con AI e assistenti di supporto
Questa è la categoria più visibile. Plugin come AI Engine (con oltre 100.000 installazioni attive), MxChat e Tidio portano le interfacce conversazionali sul front-end.
Ogni messaggio può avviare una richiesta dinamica, recuperare il contesto, richiamare un modello esterno e memorizzare i dati della conversazione. A differenza dell’invio di un modulo di contatto, una singola conversazione può generare diverse richieste di questo tipo in rapida successione.
Personalizzazione, consigli e ricerca basati sull’AI
La personalizzazione, i consigli e la ricerca basata sull’intelligenza artificiale di solito funzionano sul front-end. In un negozio WooCommerce, questo potrebbe significare adattare i suggerimenti sui prodotti in base a ciò che un acquirente ha già visualizzato o interpretare una query di ricerca invece di trovare una corrispondenza esatta con la formulazione inserita. Il resto della pagina spesso può provenire dalla cache, ma quei risultati devono comunque essere generati per la singola richiesta.
Generazione di contenuti con l’AI e strumenti editoriali
Pensa a strumenti come Jetpack AI, Rank Math Content AI, Divi AI e GetGenie. Funzionano principalmente all’interno della dashboard di WordPress.
Dato che questi strumenti funzionano principalmente nella dashboard di WordPress, in genere non rallentano il caricamento delle pagine sul front-end. Possono comunque mettere a dura prova il server quando diversi editor li usano contemporaneamente.
Agenti AI e integrazioni MCP
Le integrazioni MCP non aspettano che qualcuno visiti il sito. Il supporto MCP di AI Engine e l’adattatore MCP di WordPress ufficiale permettono a uno strumento esterno di connettersi a WordPress ed eseguire attività approvate, come leggere i dati del sito o aggiornare un post. Ogni attività viene eseguita come una richiesta API autenticata, aggiungendo un’altra fonte di attività del server da tenere in considerazione.
Due siti possono entrambi utilizzare l’AI e richiedere livelli molto diversi di risorse di hosting. Uno potrebbe usarla occasionalmente nell’editor per suggerire titoli, mentre un altro genera consigli sui prodotti per ogni acquirente. Per stimare l’impatto, controlla dove viene eseguita la funzionalità e con quale frequenza genera una richiesta a WordPress.
Cosa comportano effettivamente le funzionalità di AI per il tuo server
Il costo di una funzionalità di AI deriva dal lavoro necessario per elaborare la risposta del modello. WordPress deve comunque ricevere la richiesta, eseguire il codice del plugin, recuperare i dati necessari, contattare il provider esterno e restituire il risultato. Quattro parti di questo processo hanno il maggiore impatto sulle prestazioni.
I thread PHP rimangono occupati più a lungo
I contenuti memorizzati nella cache possono essere forniti senza utilizzare un thread PHP. Una richiesta dinamica di AI deve essere elaborata da un thread, e ogni thread gestisce una sola richiesta alla volta. Se un chatbot aspetta due secondi per un provider esterno, il thread PHP che gestisce quello scambio potrebbe rimanere occupato per quei due secondi. Quando le conversazioni simultanee utilizzano tutti i thread disponibili, le altre richieste non memorizzate nella cache finiscono in coda.
Questo è strutturalmente simile ai modelli di traffico dei bot documentati nel report sul traffico AI e bot di Kinsta. I bot che accedono a pagine di ricerca, carrello e altri endpoint dinamici riservano thread PHP e costringono l’elaborazione all’origine. Le funzionalità di AI fanno la stessa cosa intenzionalmente e, idealmente, in modo produttivo. Il costo infrastrutturale di ogni richiesta rimane comparabile.
Più richieste bypassano la cache
Molte risposte dell’AI sono specifiche per chi effettua la richiesta, quindi non possono essere semplicemente riutilizzate per il visitatore successivo. La pagina principale del prodotto potrebbe comunque caricarsi dalla cache, ma un pannello di consigli o un risultato di ricerca generato dall’AI deve essere generato separatamente. Più spesso questo accade durante una visita, più richieste il server di origine deve gestire.
L’attività del database diventa più complessa
Prima di inviare un prompt, un plugin potrebbe dover recuperare da WordPress i dettagli del prodotto, i messaggi precedenti o le informazioni sull’utente. Poiché i dati cambiano da una richiesta all’altra, è più difficile memorizzarli nella cache rispetto a una normale query di pagina. Se molte di queste richieste arrivano tutte insieme, aumentano l’attività del database proprio mentre le pagine di checkout e dell’account stanno cercando di svolgere il proprio lavoro.
La latenza delle API esterne influisce sulle prestazioni del sito
I plugin di AI spesso devono attendere un servizio di terze parti prima di poter completare una richiesta. Se OpenAI impiega tre secondi a rispondere, anche WordPress rimane in attesa — e con una chiamata sincrona, lo stesso vale per il thread PHP che la gestisce. Il plugin dovrebbe avere un timeout in modo che una chiamata bloccata non rimanga aperta all’infinito. Alcuni carichi di lavoro possono anche essere messi in coda o memorizzati nella cache, anche se un chatbot in tempo reale di solito deve aspettare il provider.
WordPress 7.0 stesso ne è un esempio utile. Il team del core ha rimosso la collaborazione in tempo reale dalla versione dopo che i test avevano sollevato preoccupazioni riguardo al carico del server, all’uso della memoria e alle condizioni di competizione. La funzionalità aveva comunque un valore, ma non era pronta per essere rilasciata entro i limiti di prestazioni che il core di WordPress doveva rispettare.
Le tre caratteristiche di hosting più importanti per WordPress con funzionalità AI
I carichi di lavoro dell’AI sono dinamici, a picchi e spesso dipendono da servizi esterni al tuo ambiente di hosting. Tre caratteristiche dell’hosting determinano se quelle richieste rimangono circoscritte e diagnosticabili o iniziano a influenzare il resto del sito.
1. Architettura a container isolati
Questo può essere un problema nell’hosting condiviso, dove il tuo sito non è l’unico a utilizzare il server. Se l’attività di AI aumenta improvvisamente, può intaccare le risorse di CPU, memoria e database disponibili per gli altri siti sulla stessa macchina.
Kinsta esegue ogni sito WordPress nel proprio container Linux isolato con uno stack software dedicato che include Nginx, PHP e MySQL. Ogni sito riceve inoltre il proprio thread PHP e la propria allocazione di memoria. Se un chatbot basato sull’intelligenza artificiale gestisce improvvisamente decine di conversazioni simultanee, il suo carico di lavoro rimane all’interno del container di quel sito invece di utilizzare le risorse assegnate a un altro sito.
Questo isolamento è particolarmente prezioso per le agenzie. Un plugin di AI mal configurato sul sito di un cliente può comunque compromettere le prestazioni di quel sito, ma il problema non si ripercuote sul resto del portafoglio.
2. Una versione PHP aggiornata e una configurazione adeguata
PHP 7.4 è in grado di eseguire WordPress 7.0, ma non è la versione che sceglieresti per le prestazioni. PHP 8.x gestisce il codice di WordPress più velocemente, quindi il lavoro legato a una richiesta AI richiede meno tempo e il thread PHP torna disponibile prima.
Una versione più recente di PHP non può far rispondere più velocemente OpenAI o Anthropic, ma può ridurre il lavoro che WordPress svolge prima e dopo quella chiamata esterna. Kinsta supporta le versioni di PHP fino alla 8.5 e ti permette di cambiare versione per i singoli ambienti live o di staging da MyKinsta. Testare prima la modifica sull’ambiente di staging aiuta a individuare eventuali conflitti di compatibilità nel plugin di AI, nel tema o nel codice personalizzato.
3. Visibilità sull’intera richiesta
I problemi di prestazioni dell’AI possono avere diverse origini: il codice PHP del plugin, una query al database, il provider del modello esterno o una capacità insufficiente dei thread. Senza dati a livello di richiesta, tutte e quattro le cause possono sembrare un generico rallentamento dell’hosting.
Lo strumento APM di Kinsta separa questi componenti.
Un’analisi pratica potrebbe essere la seguente:
- Controlla Statistiche > Prestazioni per verificare quando i tempi di risposta sono aumentati.
- Apri APM > Transazioni per identificare gli endpoint e le richieste più lenti.
- Controlla APM > Esterne per misurare le chiamate a OpenAI, Anthropic o un altro provider.
- Controlla APM > Database per individuare query di personalizzazione lente o ripetute.
- Controlla i principali bypass della cache del server per vedere quali percorsi guidati dall’AI stanno raggiungendo l’origine.
Una volta capito dove è andato a finire il tempo, hai un punto di partenza utile. Una transazione WordPress lenta richiede una soluzione diversa rispetto a un database intasato o a un’API model che impiega diversi secondi a rispondere.
Le funzionalità di AI modificano anche il tuo profilo di traffico
L’AI può aumentare la domanda di infrastruttura in entrambi i sensi. Il tuo sito WordPress invia più richieste ai fornitori di modelli, mentre i sistemi automatizzati inviano più richieste al tuo sito.
La pubblicazione assistita dall’AI può espandere rapidamente la superficie di scansione di un sito. Se un team editoriale aumenta la propria produzione da cinque articoli a settimana a venti, il sito aggiunge più URL, link interni, archivi e impaginazione che i crawler devono esplorare. I crawler non sanno necessariamente, né se ne curano, che l’AI abbia contribuito alla produzione dei contenuti. Vedono semplicemente una libreria più ampia e aggiornata più frequentemente e tornano a scansionarla.
Un milione di richieste per pagine memorizzate nella cache comporta un carico molto diverso sul server rispetto a un milione di richieste verso URL dinamici. Nell’analisi di Kinsta su oltre 10 miliardi di richieste, i crawler hanno ripetutamente colpito risultati di ricerca, pagine di prodotti filtrate, link “aggiungi al carrello” e endpoint simili. Ogni richiesta può bypassare la cache e inviare lavoro a PHP e al database.
Questo mette il traffico automatizzato in competizione con le funzionalità di AI del tuo sito stesso. Una richiesta di un chatbot e un crawler che accede a un filtro prodotti dinamico possono avere scopi completamente diversi, ma entrambi possono occupare thread PHP. Se i crawler consumano una parte considerevole della capacità disponibile del sito, le richieste legittime dei chatbot, delle ricerche e dei consigli hanno meno spazio per funzionare.
Un sito basato sull’AI ha bisogno di spazio sufficiente per le richieste che i tuoi visitatori effettuano effettivamente. I controlli sui bot aiutano a preservarlo. Googlebot ha ancora bisogno di accedere alle pagine che vuoi indicizzare, e potresti decidere che vale la pena consentire l’accesso ad alcuni crawler di AI. Il traffico da limitare è l’attività ripetitiva su endpoint dinamici che non offre alcun valore ma che comunque occupa i thread PHP.
Protezione bot di Kinsta offre controlli a livello di ambiente per consentire, verificare o bloccare il traffico automatizzato, inclusa un’opzione separata per i crawler AI. Le sue analisi mostrano come le richieste vengono classificate e gestite.
Le analisi sui bot sono solo una parte del quadro. Confrontale con le tracce APM, i rapporti sul bypass della cache e gli IP dei clienti principali in MyKinsta. In questo modo è più facile capire se il carico proviene dalle tue funzionalità di AI o da crawler esterni, e se le richieste di quei crawler valgono le risorse che consumano.
Cosa controllare prima di aggiungere una funzionalità di AI a un sito WordPress
Prima di mettere in produzione una funzionalità di AI, verifica come si comporta sulla tua infrastruttura esistente. Inizia con queste cinque domande.
1. In quale fase del ciclo di richiesta viene eseguito questo plugin?
Il percorso della richiesta è fondamentale in questo caso. Gli strumenti di scrittura e modifica di solito operano all’interno di wp-admin. Gli strumenti rivolti ai clienti condividono la capacità PHP con il resto del front-end, comprese le pagine di checkout e di account. Un agente potrebbe bypassare entrambi i percorsi e accedere tramite l’API. Controlla il flusso delle richieste del plugin prima di stimare quanta capacità gli serve.
2. Cosa può memorizzare nella cache il plugin?
Scopri esattamente cosa il plugin esclude dalla cache. La risposta stessa potrebbe dover rimanere dinamica, dato che cambia a seconda del prompt o dell’utente, ma i dati correlati, come lo stato della conversazione, i risultati di ricerca o i consigli, potrebbero essere riutilizzabili per un breve periodo. Un endpoint API dedicato non memorizzato nella cache è molto meno costoso di un plugin che rende dinamica l’intera pagina del prodotto.
3. Cosa succede quando l’API esterna è lenta?
Testa anche una chiamata fallita, non solo una lenta. Interrompi temporaneamente la connessione nell’ambiente di staging e osserva quando termina la richiesta. Alcuni plugin riprovano subito; altri rimangono aperti finché PHP non li interrompe. Se diverse richieste del chatbot lo fanno contemporaneamente, le richieste relative al checkout e all’account potrebbero dover attendere un thread PHP.
4. Testa prima sull’ambiente di staging con lo strumento APM in esecuzione
Installa il plugin su un ambiente di staging e attiva lo strumento APM di Kinsta durante i test. Riproduci conversazioni tipiche, ricerche o flussi di lavoro di generazione di contenuti, incluse attività simultanee dove opportuno. Controlla le schede “Transazioni”, “Esterne” e “Database” per stabilire quanto tempo impiegano le richieste e dove viene impiegato quel tempo.
5. PHP è pronto per il carico di lavoro aggiuntivo?
Registra come si comporta il sito di staging prima di modificare il PHP. MyKinsta ti mostra se sta già raggiungendo il limite di thread PHP, oltre ai dati sui tempi di risposta e sull’utilizzo della memoria. Passa lo staging a una versione attuale di PHP 8.x, ripeti gli stessi flussi di lavoro e verifica che il plugin funzioni ancora prima di apportare la modifica in produzione.
L’ambiente di staging non riprodurrà perfettamente l’ambiente di produzione. Può comunque mostrare se il plugin genera troppe richieste che bypassano la cache, attende troppo a lungo su un’API esterna, esegue query onerose o lascia troppo poca capacità PHP per il resto del sito.
Considera ogni lancio di un’AI come un cambiamento infrastrutturale
WordPress 7.0 offre agli sviluppatori un modo standard per integrarsi con i fornitori di AI e richiamare i modelli direttamente da WordPress. Il server dovrà comunque elaborare quelle richieste una volta che la funzionalità sarà attiva.
Prima di modificare la configurazione dell’hosting, apri alcune tracce APM. L’elenco dei plugin non ti dirà quanto lavoro sta svolgendo il sito, e il numero di thread PHP non spiegherà perché una richiesta è lenta. Una traccia mostra se la richiesta ha bypassato la cache, quanto tempo ha impiegato PHP per l’elaborazione e se il ritardo è dovuto al database o all’API del modello. Da lì, puoi decidere se il plugin va modificato o se il sito ha bisogno di più capacità.
Un plugin basato sull’intelligenza artificiale può funzionare alla perfezione e tuttavia non essere adatto alla capacità attuale del sito. Prima di implementarlo sul sito di un cliente, esegui l’APM in ambiente di staging e verifica quanto tempo impiegano le chiamate alle API esterne, quali richieste non vengono memorizzate nella cache e quale versione di PHP utilizza l’ambiente. Controlla nuovamente questi dati dopo il lancio, quando il traffico reale entrerà in gioco.
Questi pochi controlli permettono di individuare la pressione sui thread, le dipendenze lente e i comportamenti di query onerosi prima che si trasformino in un sito lento — o in una conversazione difficile con il cliente.
Carlo è cultore appassionato di webdesign e front-end development. Gioca con WordPress da oltre 20 anni, anche in collaborazione con università ed enti educativi italiani ed europei. Su WordPress ha scritto centinaia di articoli e guide, pubblicati sia in siti web italiani e internazionali, che su riviste a stampa. Lo trovate su LinkedIn.
