Data di pubblicazione: 10 novembre 2026
WeTV è la piattaforma di streaming video internazionale di Tencent. Offre serie drammatiche, anime e programmi di varietà agli spettatori del Sud-Est asiatico e di altri mercati globali. Per un sito incentrato sui video, le prestazioni determinano se gli spettatori rimangono, se i motori di ricerca mostrano i contenuti e se la riproduzione è fluida.
Il team di ingegneria web di WeTV non rilascia codice che non raggiunge i target di rendimento. Per molto tempo, mantenere questa linea significava che uno sviluppatore doveva interrompere ciò che stava facendo, aprire Chrome e profilare la pagina manualmente ogni volta che una build non superava il controllo. Individuare e correggere una regressione richiedeva circa quattro ore.
Oggi, un agente di programmazione AI svolge questo lavoro nell'ambito della pipeline CI/CD. Con Chrome DevTools per agenti, l'agente ispeziona la pagina in un browser attivo. Con Modern Web Guidance, scrive correzioni che seguono gli standard attuali della piattaforma web. Il workflow ora diagnostica e risolve automaticamente il 90% dei test delle prestazioni non riusciti e il tempo che intercorre tra un controllo non riuscito e una correzione verificata è sceso da quattro ore a 30 minuti, inclusi la build completa e la valutazione manuale.
La sfida: uno sviluppatore bloccato tra l'editor e il browser
Gli ingegneri di WeTV utilizzavano già strumenti di programmazione AI nel loro IDE. Questi strumenti potevano scrivere codice, ma non potevano vedere cosa faceva il codice una volta eseguito in un browser. Quindi il lavoro è stato diviso in due. Gli ingegneri scrivono il codice nell'editor, quindi passano a Chrome per eseguirne il deployment, ispezionarlo e verificarlo. Ogni correzione significava ripetere manualmente il ciclo.
La divisione ha avuto un impatto maggiore sul gate di rilascio. La pipeline CI/CD di WeTV esegue tracce delle prestazioni su ogni release e mantiene il Cumulative Layout Shift (CLS) a 0,1 o meno. Quando una build superava questa soglia, la pipeline la segnalava, ma l'individuazione della causa era ancora manuale. Un ingegnere doveva aprire Chrome DevTools, registrare una traccia, trovare l'elemento che si era spostato, riportare il risultato nell'editor, scrivere una correzione ed eseguire nuovamente il controllo. Una singola regressione CLS costava circa quattro ore di lavoro di progettazione.
Il team aveva bisogno di un agente in grado di gestire entrambe le parti del lavoro: esaminare la pagina in esecuzione e poi correggere il codice in base a uno standard noto.
La soluzione: connettere l'agente al browser e agli standard web
WeTV ha spostato la verifica delle prestazioni nel flusso delle richieste di unione (MR). Quando uno sviluppatore apre una MR, la pipeline CI/CD avvia un ambiente in cui l'agente di programmazione AI viene eseguito localmente con due funzionalità che mancavano agli strumenti IDE del team:
- Chrome DevTools per agenti: esegue un server Model Context Protocol (MCP) e connette l'agente a un'istanza Chrome attiva. L'agente può registrare le tracce delle prestazioni (tra le altre funzionalità di Chrome DevTools) e controllare come viene effettivamente eseguito il rendering del codice frontend, nello stesso modo in cui lo farebbe uno sviluppatore in DevTools.
- Modern Web Guidance: una skill dell'agente che contiene le best practice per le piattaforme web e i dati sulla compatibilità dei browser. Allontana l'agente dai pattern legacy e lo indirizza verso correzioni basate sulle funzionalità della piattaforma web moderna.
DevTools per gli agenti indica all'agente cosa non ha funzionato. Modern Web Guidance determina il modo in cui lo corregge.
Esempio reale: una variazione del layout nella pagina di riproduzione della puntata
Durante una richiesta di unione, l'agente ha eseguito lo strumento performance_start_trace nella pagina di riproduzione delle puntate per computer. La traccia ha registrato un CLS di 0,39, quasi quattro volte il limite di 0,1.
Chiedi all'agente di eseguire una diagnosi prima di apportare modifiche
WeTV non consente all'agente di improvvisare. Il prompt che guida il workflow gli indica di diagnosticare il problema prima di toccare il codice e di confrontare i risultati con Modern Web Guidance, anziché fare affidamento su ciò che il modello genererebbe per impostazione predefinita.
Ecco un esempio di prompt utilizzato dal team di WeTV:
Context:
"The CLS (Cumulative Layout Shift) of this page needs inspection. Diagnose
first, then modify the code, do not guess."
Mandatory Execution Steps:
1. Performance Trace: Use Chrome DevTools for agents to run performance traces
on both Desktop and Mobile views.
2. Identify Culprits: Use CLSCulprits insight to pinpoint the exact DOM elements
causing shifts (capture class/id, timing, and score).
3. Use web best practices for performance and CSS to optimize CLS.
4. Multi-Agent Parallelism: Enable parallel agents for efficiency:
- Agent A: Investigate Player/Main Layout SSR placeholders.
- Agent B: Investigate Sidebar Ads, VIP buttons, Tabs, and late-injected
lists.
- Agent C: Investigate Fonts and other minor factors.
Constraint: Each agent modifies only files within its scope to prevent
conflicts.
5. Root Cause Confirmation: Confirm the root cause before applying fixes.
Prioritize reserving space over changing interaction semantics just to fix
CLS.
6. Verification: After modification, re-test CLS via equivalent CSS injection
or local build. Target: CLS < 0.1.
Due parti di questo prompt hanno un peso maggiore. "Diagnostica prima, poi modifica il codice" impedisce all'agente di applicare patch ai sintomi. Il passaggio 2 indica all'agente di utilizzare performance_analyze_insight con insightName: 'CLSCulprits', in modo che segnali l'elemento, la tempistica e il punteggio esatti anziché un sospetto generale.
Nel video seguente, quando viene eseguito il prompt, l'agente cerca la guida pertinente in Modern Web Guidance per implementare le correzioni con le funzionalità web moderne relative a CLS e utilizza Chrome DevTools per agenti per aprire un'istanza del browser Chrome e registrare una traccia delle prestazioni.
Questa combinazione di diagnostica di runtime e indicazioni strutturate consente di correggere automaticamente i cambiamenti di layout complessi. Ecco un esempio di problema risolto dal workflow automatico.
Trova la causa principale
La traccia indicava il video player. WeTV esegue il rendering del player sul server, ma il contenitore del player non ha riservato spazio per l'altezza. Quando il client ha idratato la pagina, l'altezza del container è aumentata e i contenuti circostanti si sono spostati.
Applica una correzione basata su standard
La soluzione è riservare lo spazio durante il rendering lato server, in modo che il container abbia già l'altezza corretta prima dell'idratazione. Di seguito è riportato un esempio di correzione scritta dall'agente con riferimento alla guida al layout CSS di Modern Web Guidance:
.play__block--player .play__aside--left {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16/9;
}
Dopo che l'agente ha applicato il CSS, la pipeline ha ricostruito la pagina e l'agente ha eseguito di nuovo la stessa traccia. Solo quando il CLS è sceso sotto lo 0,1, la patch è passata alla revisione umana.
Impatto: rilasci più rapidi e layout stabili
WeTV ha ottenuto miglioramenti misurabili nell'efficienza di progettazione e nella stabilità del layout quando ha aggiunto Chrome DevTools per agenti e Modern Web Guidance al suo workflow CI/CD:
- Riduzione dell'87% del tempo di debug e risoluzione end-to-end (da 4 ore a 30 minuti).
- Il 90% di tutte le regressioni delle prestazioni ricorrenti viene diagnosticato e risolto automaticamente.
Gli ingegneri non perdono più mezza giornata di lavoro per la profilazione. Quando una build supera la soglia, l'agente legge la traccia, scrive una correzione, la testa e consegna una patch verificata a un revisore umano. Le persone prendono comunque la decisione finale, ma partono da una correzione che ha già superato il controllo non riuscito.
Poiché le regressioni CLS vengono corrette all'interno della richiesta di unione, non raggiungono la produzione. In questo modo, le pagine rimangono al di sotto del target di 0,1, la visibilità della ricerca di WeTV è protetta e viene rimosso un motivo comune per bloccare una release in ritardo nel ciclo.
Lezioni per il tuo team
La configurazione di WeTV è specifica per il suo stack, ma il pattern alla base si applica alla maggior parte dei team che bloccano le release in base alle prestazioni:
- Esegui l'agente nel punto in cui si verifica l'errore. WeTV attiva l'agente dalla richiesta di unione, quindi nessuno deve notare un controllo non riuscito e avviare una sessione manualmente.
- Chiedi all'agente di eseguire una diagnosi prima di apportare modifiche. Chiedere prima una traccia e un colpevole con nome produce correzioni che prendono di mira l'elemento effettivo anziché un'ipotesi.
- Associa i dati di runtime a uno standard. Una traccia indica all'agente quale elemento è stato spostato. Modern Web Guidance gli indica quale correzione segue la prassi attuale della piattaforma.
- Richiedi una prova. La riesecuzione della stessa traccia che ha restituito un errore è la prova per l'agente che la correzione funziona. P2ER segue lo stesso principio nella sua regola di verifica empirica obbligatoria.
- Mantieni l'approccio human-in-the-loop. L'agente esegue l'indagine e un engineer esamina una patch che ha già superato il controllo.
Feedback e piani futuri
WeTV ha scoperto che l'abbinamento della telemetria di runtime in tempo reale di Chrome DevTools per agenti con le regole standardizzate di Modern Web Guidance ha eliminato l'analisi manuale delle prestazioni dal processo di rilascio, mantenendo al contempo le modifiche al codice dell'agente in linea con gli attuali standard della piattaforma web.
"I risultati sono stati molto efficaci sia in termini di velocità che di qualità. Gli insight diagnostici forniti da Chrome DevTools per agenti e Modern Web Guidance ci hanno fornito riferimenti affidabili per risolvere problemi di layout complessi. Eseguiamo una verifica rigorosa dopo ogni correzione e l'attuale tasso di successo e stabilità ha migliorato notevolmente la nostra fiducia nelle release."
—Yangjie Zheng, Head of Engineering, WeTV (Tencent)
In futuro, il team di ingegneri di WeTV prevede di introdurre Chrome DevTools per agenti e Modern Web Guidance nei test end-to-end per le prossime release del codice.
Risorse
Per configurare un flusso di lavoro simile, consulta queste risorse: