La stessa pressione pu\u00f2 derivare da funzionalit\u00e0 che a prima vista sembrano molto diverse. La ricerca con l\u2019AI, 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\u2019API (e se le loro richieste possono essere memorizzate nella cache) ti aiuta a pianificare le risorse del server di cui avranno bisogno.<\/p>\n
Come si presenta effettivamente l\u2019AI di WordPress su un sito live<\/h2>\n
L\u2019AI su WordPress non \u00e8 un unico carico di lavoro. Dove viene eseguita la funzionalit\u00e0, quando viene eseguita e se \u00e8 un visitatore ad attivarla sono tutti fattori che influenzano il profilo dell\u2019infrastruttura.<\/p>\n
Chatbot con AI e assistenti di supporto<\/h3>\n
Questa \u00e8 la categoria pi\u00f9 visibile. Plugin come AI Engine<\/a> (con oltre 100.000 installazioni attive), MxChat<\/a> e Tidio<\/a> portano le interfacce conversazionali sul front-end.<\/p>\n Ogni messaggio pu\u00f2 avviare una richiesta dinamica, recuperare il contesto, richiamare un modello esterno e memorizzare i dati della conversazione. A differenza dell\u2019invio di un modulo di contatto, una singola conversazione pu\u00f2 generare diverse richieste di questo tipo in rapida successione.<\/p>\n La personalizzazione, i consigli e la ricerca basata sull\u2019intelligenza artificiale di solito funzionano sul front-end. In un negozio WooCommerce, questo potrebbe significare adattare i suggerimenti sui prodotti in base a ci\u00f2 che un acquirente ha gi\u00e0 visualizzato o interpretare una query di ricerca invece di trovare una corrispondenza esatta con la formulazione inserita. Il resto della pagina spesso pu\u00f2 provenire dalla cache, ma quei risultati devono comunque essere generati per la singola richiesta.<\/p>\n Pensa a strumenti come Jetpack AI<\/a>, Rank Math Content AI<\/a>, Divi AI<\/a> e GetGenie<\/a>. Funzionano principalmente all\u2019interno della dashboard di WordPress.<\/p>\n 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.<\/p>\n Le integrazioni MCP<\/a> non aspettano che qualcuno visiti il sito. Il supporto MCP di AI Engine e l\u2019adattatore MCP di WordPress<\/a> ufficiale permettono a uno strumento esterno di connettersi a WordPress ed eseguire attivit\u00e0 approvate, come leggere i dati del sito o aggiornare un post. Ogni attivit\u00e0 viene eseguita come una richiesta API autenticata, aggiungendo un\u2019altra fonte di attivit\u00e0 del server da tenere in considerazione.<\/p>\n Due siti possono entrambi utilizzare l\u2019AI e richiedere livelli molto diversi di risorse di hosting. Uno potrebbe usarla occasionalmente nell\u2019editor per suggerire titoli, mentre un altro genera consigli sui prodotti per ogni acquirente. Per stimare l\u2019impatto, controlla dove viene eseguita la funzionalit\u00e0 e con quale frequenza genera una richiesta a WordPress.<\/p>\n Il costo di una funzionalit\u00e0 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.<\/p>\n 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.<\/p>\n Questo \u00e8 strutturalmente simile ai modelli di traffico dei bot documentati nel report sul traffico AI e bot di Kinsta<\/a>. I bot che accedono a pagine di ricerca, carrello e altri endpoint dinamici riservano thread PHP e costringono l\u2019elaborazione all\u2019origine. Le funzionalit\u00e0 di AI fanno la stessa cosa intenzionalmente e, idealmente, in modo produttivo. Il costo infrastrutturale di ogni richiesta rimane comparabile.<\/p>\n Molte risposte dell\u2019AI 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\u2019AI deve essere generato separatamente. Pi\u00f9 spesso questo accade durante una visita, pi\u00f9 richieste il server di origine deve gestire.<\/p>\n Prima di inviare un prompt, un plugin potrebbe dover recuperare da WordPress i dettagli del prodotto, i messaggi precedenti o le informazioni sull\u2019utente. Poich\u00e9 i dati cambiano da una richiesta all\u2019altra, \u00e8 pi\u00f9 difficile memorizzarli nella cache rispetto a una normale query di pagina. Se molte di queste richieste arrivano tutte insieme, aumentano l\u2019attivit\u00e0 del database proprio mentre le pagine di checkout e dell\u2019account stanno cercando di svolgere il proprio lavoro.<\/p>\n 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 \u2014 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\u2019infinito. 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.<\/p>\n WordPress 7.0 stesso ne \u00e8 un esempio utile<\/a>. 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\u2019uso della memoria e alle condizioni di competizione. La funzionalit\u00e0 aveva comunque un valore, ma non era pronta per essere rilasciata entro i limiti di prestazioni che il core di WordPress doveva rispettare.<\/p>\n I carichi di lavoro dell\u2019AI sono dinamici, a picchi e spesso dipendono da servizi esterni al tuo ambiente di hosting. Tre caratteristiche dell\u2019hosting determinano se quelle richieste rimangono circoscritte e diagnosticabili o iniziano a influenzare il resto del sito.<\/p>\n Questo pu\u00f2 essere un problema nell\u2019hosting condiviso, dove il tuo sito non \u00e8 l\u2019unico a utilizzare il server. Se l\u2019attivit\u00e0 di AI aumenta improvvisamente, pu\u00f2 intaccare le risorse di CPU, memoria e database disponibili per gli altri siti sulla stessa macchina.<\/p>\n Kinsta esegue ogni sito WordPress nel proprio container Linux isolato con uno stack software dedicato che include Nginx<\/a>, PHP<\/a> e MySQL<\/a>. Ogni sito riceve inoltre il proprio thread PHP e la propria allocazione di memoria. Se un chatbot basato sull\u2019intelligenza artificiale gestisce improvvisamente decine di conversazioni simultanee, il suo carico di lavoro rimane all\u2019interno del container di quel sito invece di utilizzare le risorse assegnate a un altro sito.<\/p>\n Questo isolamento \u00e8 particolarmente prezioso per le agenzie<\/a>. Un plugin di AI mal configurato sul sito di un cliente pu\u00f2 comunque compromettere le prestazioni di quel sito, ma il problema non si ripercuote sul resto del portafoglio.<\/p>\n PHP 7.4 \u00e8 in grado di eseguire WordPress 7.0, ma non \u00e8 la versione che sceglieresti per le prestazioni. PHP 8.x<\/a> gestisce il codice di WordPress pi\u00f9 velocemente, quindi il lavoro legato a una richiesta AI richiede meno tempo e il thread PHP torna disponibile prima.<\/p>\n Una versione pi\u00f9 recente di PHP non pu\u00f2 far rispondere pi\u00f9 velocemente OpenAI o Anthropic, ma pu\u00f2 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<\/a> da MyKinsta. Testare prima la modifica sull\u2019ambiente di staging aiuta a individuare eventuali conflitti di compatibilit\u00e0 nel plugin di AI, nel tema o nel codice personalizzato.<\/p>\n I problemi di prestazioni dell\u2019AI<\/a> possono avere diverse origini: il codice PHP del plugin, una query al database, il provider del modello esterno o una capacit\u00e0 insufficiente dei thread. Senza dati a livello di richiesta, tutte e quattro le cause possono sembrare un generico rallentamento dell\u2019hosting.<\/p>\n Lo strumento APM di Kinsta<\/a> separa questi componenti.<\/p>\n Un’analisi pratica potrebbe essere la seguente:<\/p>\n Una volta capito dove \u00e8 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\u2019API model che impiega diversi secondi a rispondere.<\/p>\n L\u2019AI pu\u00f2 aumentare la domanda di infrastruttura in entrambi i sensi. Il tuo sito WordPress invia pi\u00f9 richieste ai fornitori di modelli, mentre i sistemi automatizzati inviano pi\u00f9 richieste al tuo sito.<\/p>\n La pubblicazione assistita dall\u2019AI pu\u00f2 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\u00f9 URL, link interni, archivi e impaginazione che i crawler devono esplorare. I crawler non sanno necessariamente, n\u00e9 se ne curano, che l\u2019AI abbia contribuito alla produzione dei contenuti. Vedono semplicemente una libreria pi\u00f9 ampia e aggiornata pi\u00f9 frequentemente e tornano a scansionarla.<\/p>\n 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\u2019analisi di Kinsta su oltre 10 miliardi di richieste<\/a>, i crawler hanno ripetutamente colpito risultati di ricerca, pagine di prodotti filtrate, link \u201caggiungi al carrello\u201d e endpoint simili. Ogni richiesta pu\u00f2 bypassare la cache e inviare lavoro a PHP e al database.<\/p>\n Questo mette il traffico automatizzato in competizione con le funzionalit\u00e0 di AI del tuo sito stesso. Una richiesta di un chatbot e un crawler che accede a un\u00a0filtro prodotti<\/a> dinamico possono avere scopi completamente diversi, ma entrambi possono occupare thread PHP. Se i crawler consumano una parte considerevole della capacit\u00e0 disponibile del sito, le richieste legittime dei chatbot, delle ricerche e dei consigli hanno meno spazio per funzionare.<\/p>\n Un sito basato sull\u2019AI 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\u2019accesso ad alcuni crawler di AI. Il traffico da limitare \u00e8 l\u2019attivit\u00e0 ripetitiva su endpoint dinamici che non offre alcun valore ma che comunque occupa i thread PHP.<\/p>\n Protezione bot di Kinsta<\/a> offre controlli a livello di ambiente per consentire, verificare o bloccare il traffico automatizzato, inclusa un\u2019opzione separata per i crawler AI. Le sue analisi mostrano come le richieste vengono classificate e gestite.<\/p>\n 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 \u00e8 pi\u00f9 facile capire se il carico proviene dalle tue funzionalit\u00e0 di AI o da crawler esterni, e se le richieste di quei crawler valgono le risorse che consumano.<\/p>\n Prima di mettere in produzione una funzionalit\u00e0 di AI, verifica come si comporta sulla tua infrastruttura esistente. Inizia con queste cinque domande.<\/p>\n Il percorso della richiesta \u00e8 fondamentale in questo caso. Gli strumenti di scrittura e modifica di solito operano all\u2019interno di wp-admin. Gli strumenti rivolti ai clienti condividono la capacit\u00e0 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\u2019API. Controlla il flusso delle richieste del plugin prima di stimare quanta capacit\u00e0 gli serve.<\/p>\n Scopri esattamente cosa il plugin esclude dalla cache. La risposta stessa potrebbe dover rimanere dinamica, dato che cambia a seconda del prompt o dell\u2019utente, 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 \u00e8 molto meno costoso di un plugin che rende dinamica l\u2019intera pagina del prodotto.<\/p>\n Testa anche una chiamata fallita, non solo una lenta. Interrompi temporaneamente la connessione nell\u2019ambiente di staging e osserva quando termina la richiesta. Alcuni plugin riprovano subito; altri rimangono aperti finch\u00e9 PHP non li interrompe. Se diverse richieste del chatbot lo fanno contemporaneamente, le richieste relative al checkout e all\u2019account potrebbero dover attendere un thread PHP.<\/p>\n Installa il plugin su un ambiente di staging<\/a> e attiva lo strumento APM di Kinsta<\/a> durante i test. Riproduci conversazioni tipiche, ricerche o flussi di lavoro di generazione di contenuti, incluse attivit\u00e0 simultanee dove opportuno. Controlla le schede \u201cTransazioni\u201d<\/strong>, \u201cEsterne\u201d<\/strong> e \u201cDatabase\u201d<\/strong> per stabilire quanto tempo impiegano le richieste e dove viene impiegato quel tempo.<\/p>\n Registra come si comporta il sito di staging prima di modificare il PHP. MyKinsta ti mostra se sta gi\u00e0 raggiungendo il limite di thread PHP, oltre ai dati sui tempi di risposta e sull\u2019utilizzo 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.<\/p>\n L\u2019ambiente di staging non riprodurr\u00e0 perfettamente l\u2019ambiente di produzione. Pu\u00f2 comunque mostrare se il plugin genera troppe richieste che bypassano la cache, attende troppo a lungo su un\u2019API esterna, esegue query onerose o lascia troppo poca capacit\u00e0 PHP per il resto del sito.<\/p>\n 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\u00e0 comunque elaborare quelle richieste una volta che la funzionalit\u00e0 sar\u00e0 attiva.<\/p>\n Prima di modificare la configurazione dell\u2019hosting, apri alcune tracce APM. L\u2019elenco dei plugin non ti dir\u00e0 quanto lavoro sta svolgendo il sito, e il numero di thread PHP non spiegher\u00e0 perch\u00e9 una richiesta \u00e8 lenta. Una traccia mostra se la richiesta ha bypassato la cache, quanto tempo ha impiegato PHP per l\u2019elaborazione e se il ritardo \u00e8 dovuto al database o all\u2019API del modello. Da l\u00ec, puoi decidere se il plugin va modificato o se il sito ha bisogno di pi\u00f9 capacit\u00e0.<\/p>\n Un plugin basato sull\u2019intelligenza artificiale pu\u00f2 funzionare alla perfezione e tuttavia non essere adatto alla capacit\u00e0 attuale del sito. Prima di implementarlo sul sito di un cliente, esegui l\u2019APM 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\u2019ambiente. Controlla nuovamente questi dati dopo il lancio, quando il traffico reale entrer\u00e0 in gioco.<\/p>\n 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 \u2014 o in una conversazione difficile con il cliente.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 …<\/p>\n","protected":false},"author":36,"featured_media":85136,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[25869,26290],"class_list":["post-85135","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-prestazioni-wordpress","topic-traffico-bot"],"yoast_head":"\n![\"AI](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/ai-engine.png\")
Personalizzazione, consigli e ricerca basati sull’AI<\/h3>\n
Generazione di contenuti con l\u2019AI e strumenti editoriali<\/h3>\n
![\"Jetpack](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/jetpackai.png\")
Agenti AI e integrazioni MCP<\/h3>\n
Cosa comportano effettivamente le funzionalit\u00e0 di AI per il tuo server<\/h2>\n
I thread PHP rimangono occupati pi\u00f9 a lungo<\/h3>\n
Pi\u00f9 richieste bypassano la cache<\/h3>\n
L\u2019attivit\u00e0 del database diventa pi\u00f9 complessa<\/h3>\n
La latenza delle API esterne influisce sulle prestazioni del sito<\/h3>\n
Le tre caratteristiche di hosting pi\u00f9 importanti per WordPress con funzionalit\u00e0 AI<\/h2>\n
1. Architettura a container isolati<\/h3>\n
2. Una versione PHP aggiornata e una configurazione adeguata<\/h3>\n
3. Visibilit\u00e0 sull\u2019intera richiesta<\/h3>\n
![\"Kinsta](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/enabling-apm.png\")
\n
![\"Uno](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/kinsta-apm-tool.png\")
Le funzionalit\u00e0 di AI modificano anche il tuo profilo di traffico<\/h2>\n
![\"Strumento](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/bot-protection.png\")
Cosa controllare prima di aggiungere una funzionalit\u00e0 di AI a un sito WordPress<\/h2>\n
1. In quale fase del ciclo di richiesta viene eseguito questo plugin?<\/h3>\n
2. Cosa pu\u00f2 memorizzare nella cache il plugin?<\/h3>\n
3. Cosa succede quando l\u2019API esterna \u00e8 lenta?<\/h3>\n
4. Testa prima sull\u2019ambiente di staging con lo strumento APM in esecuzione<\/h3>\n
![\"screenshot](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/apm-duration.png\")
5. PHP \u00e8 pronto per il carico di lavoro aggiuntivo?<\/h3>\n
Considera ogni lancio di un\u2019AI come un cambiamento infrastrutturale<\/h2>\n