Un WordPress AI workload ha utilizzato 27 secondi di tempo PHP
Un WordPress AI workload per creare una singola immagine in evidenza ha consumato circa 27,36 secondi cumulativi di elaborazione PHP in un test di Kinsta pubblicato il 22 ottobre 2026. PHP è il software utilizzato da WordPress per eseguire richieste dinamiche, mentre un PHP worker è un processo server disponibile per gestire questo tipo di lavoro. La misurazione è importante perché ogni worker coinvolto in una richiesta AI sincrona rimane occupato mentre un modello esterno elabora e restituisce la propria risposta.
WordPress può interagire con l'intelligenza artificiale tramite il traffico dei crawler, i plugin che utilizzano AI Client e le applicazioni esterne che interrogano Abilities API. Un'API, o interfaccia di programmazione delle applicazioni, è un metodo definito con cui i sistemi software si scambiano richieste e risultati. WordPress mette a disposizione Abilities API per esporre azioni che il software può invocare, mentre AI Client indirizza il lavoro verso un provider AI selezionato. Operazioni come la generazione di immagini e la trascrizione audio possono richiedere diversi secondi, riducendo in quel periodo la capacità dei worker disponibile per i visitatori e per le altre richieste automatizzate.
Kinsta ha testato il plugin AI ufficiale di WordPress.org con un connettore Google configurato. Il processo richiedeva un'API key del provider, l'attivazione del provider in Settings > Connectors e l'installazione del plugin AI. Il plugin ha registrato diverse funzionalità, tra cui Image Generation and Editing, visibili in Tools > Abilities Explorer. È stato quindi creato un nuovo articolo e il relativo comando Generate featured image ha avviato il workflow. Kinsta ha precisato che gli esempi sono stati registrati in momenti diversi, perciò i tempi variano tra le diverse viste di monitoraggio. I risultati dipendono inoltre in larga misura dal tempo di risposta del provider e dall'elaborazione effettuata dal plugin stesso.
L'analisi del server ha utilizzato Kinsta APM e gli access log. APM significa monitoraggio delle prestazioni delle applicazioni e registra dove un'applicazione impiega il proprio tempo di esecuzione. Kinsta afferma che i clienti possono abilitare lo strumento in Sites > sitename > APM, selezionare un periodo di monitoraggio e successivamente esaminare transazioni, plugin, temi, hook di WordPress, query lente al database e richieste esterne. Un access log è il registro del web server relativo alle richieste in arrivo, comprendente l'indirizzo IP e lo User Agent del richiedente, l'indirizzo richiesto, il codice di stato e il tempo totale di esecuzione. Kinsta rende disponibili tramite la propria dashboard i log di accesso, cache ed errori e consente anche di scaricarli tramite i propri strumenti di gestione dei file e accesso remoto.
Durante una finestra APM di due minuti, l'esecuzione PHP ha totalizzato circa 27 secondi, il server database ha impiegato 271 millisecondi e le transazioni esterne hanno rappresentato più di 19 secondi. Le richieste all'indirizzo /wp-json, utilizzato dalla REST API di WordPress, sono state le transazioni più lente. Una REST API è un'interfaccia web attraverso la quale un software richiede dati o azioni. I plugin ai-provider-for-google e ai hanno rappresentato insieme quasi il 90% della durata registrata.
I dati relativi alle richieste esterne hanno mostrato che le richieste POST a generativelanguage.googleapis.com rappresentavano il 95,51% del tempo complessivo di tutte le transazioni esterne, mentre le richieste GET allo stesso servizio rappresentavano il 3,94%. Le richieste POST inviano dati da elaborare, mentre le richieste GET recuperano una risorsa. Le chiamate POST hanno accumulato più di 18 secondi. Kinsta APM distingue la durata totale, ossia la somma di tutte le chiamate a un endpoint, dalla durata massima e media del campione. Riporta inoltre il tasso medio di esecuzione al minuto, quindi la durata totale non deve essere confusa con la durata di una singola richiesta.
Il trace della transazione ha mostrato il percorso di esecuzione alla base della generazione dell'immagine. WordPress è stato avviato tramite wp-blog-header.php e WP_REST_Server ha inoltrato la richiesta. Generate_Image.php ha invocato generate_image nel namespace delle immagini AI di WordPress, class-wp-ability.php ha trasferito l'esecuzione a WP_AI_Client e PromptBuilder.php ha composto le istruzioni. GoogleTextGenerationModel.php le ha convertite in una richiesta compatibile con Gemini. HttpTransporter.php ha quindi trasmesso la chiamata attraverso la WordPress HTTP API a WP_Http->request. In questo modo è stata aperta una synchronous, blocking connection, cioè lo stesso PHP worker ha atteso la risposta di Google invece di rendersi disponibile per un'altra attività. Una delle richieste analizzate ha occupato il proprio worker per più di otto secondi. APM ha fornito anche uno stack trace, ossia un registro, file per file e riga per riga, del codice PHP eseguito.
Gli access log hanno mostrato quattro operazioni sequenziali di Abilities API. La generazione del prompt ha inviato il contenuto dell'articolo a Gemini e ha richiesto 5,432 secondi. La generazione dell'immagine ha inviato la descrizione risultante al modello Imagen di Google e ha atteso per 9,795 secondi il payload binario o base64 dell'immagine, cioè una rappresentazione testuale dei dati dell'immagine. La generazione dell'alt text ha quindi chiesto a Gemini di analizzare l'immagine e ha richiesto 11,305 secondi. Infine, l'importazione dell'immagine ha scaricato il payload e lo ha registrato nella Media Library di WordPress in 0,839 secondi. Una successiva richiesta GET ha recuperato il JPEG completato dalla directory uploads con 0,000 secondi di tempo PHP, perché il web server ha fornito il file statico senza eseguire WordPress. Arrotondate ai valori presentati nell'analisi, le quattro operazioni PHP hanno totalizzato 27,36 secondi.
Gli strumenti per sviluppatori del browser hanno offerto una prospettiva separata dal lato client. Dopo aver aperto il Network panel e applicato un filtro per le richieste web in background, Kinsta ha registrato 5,52 secondi per la generazione del prompt, 9,92 secondi per la generazione dell'immagine, 7,32 secondi per l'alt text e 1,79 secondi per il download e il ritaglio dell'immagine e la sua registrazione nella Media Library. Il tempo totale di attesa nel browser è stato quindi di 24,55 secondi. Questi numeri differiscono dalle misurazioni dei log del server perché le operazioni sono state eseguite in momenti diversi, non perché le due viste misurino la stessa esecuzione.
Il test non stabilisce un costo fisso per ogni funzionalità AI, ma dimostra il metodo e il rischio per la capacità disponibile. Più attività bloccanti sovrapposte possono occupare i PHP worker disponibili, aumentare le code e la latenza e rendere più probabili timeout, errori HTTP 5xx del server o periodi di inattività. Kinsta ha concluso che due o tre attività simultanee potrebbero saturare una configurazione tradizionale con risorse limitate, anche se la soglia effettiva dipende dalla quantità di worker assegnata al sito, dal traffico, dal codice e dai tempi di risposta del provider. Anche l'utilizzo della larghezza di banda può aumentare durante il trasferimento dei payload delle immagini.
I proprietari dei siti dovrebbero ripetere questa misurazione in un ambiente di staging, cioè una copia privata utilizzata per i test, ed esaminare sia i trace del server sia i tempi del browser prima di distribuire una funzionalità AI su un sito di produzione molto trafficato. Un'infrastruttura dotata di caching, ottimizzazione del database e capacità scalabile dei worker non può eliminare il ritardo di elaborazione di un modello esterno, ma può offrire maggiore capacità per le richieste simultanee. Per le organizzazioni che desiderano un hosting gestito come servizio, AEU Hosting offre hosting WordPress gestito e protetto end to end.