Hoe Policybazaar de overhead voor controles met 92% verminderde en de schermweergave met meer dan 90% versnelde met Chrome DevTools voor agents en Modern Web Guidance

Swetha Gopalakrishnan
Swetha Gopalakrishnan

Gepubliceerd: 10 november 2026

Policybazaar is een van de grootste verzekeringsplatforms in India, met meer dan 97 miljoen geregistreerde klanten. Ongeveer 80% van de klanten bezoekt de website elke maand. Het moederbedrijf, PB Fintech, heeft onlangs Pensionbazaar gelanceerd, een end-to-end platform voor pensioenplanning. Dit is een merk van Paisabazaar Marketing & Consulting Private Limited.

Beide teams gebruiken al programmeeragents die snel code schrijven, maar niet kunnen zien wat die code doet in een browser. Medewerkers gebruikten vaak verouderde webpatronen en konden niet controleren of een scherm correct werd weergegeven. Daarom moesten technici alles nog steeds handmatig verifiëren.

Om dit op te lossen, hebben beide bedrijven 2 tools gecombineerd in hun agentic workflow: Modern Web Guidance om modellen moderne webstandaarden te leren en Chrome DevTools voor agents om die agents een live, headless browser te geven om hun werk te inspecteren en te verifiëren.

Dit is de impact:

92%

Minder handmatige controle op ongeveer 30 Policybazaar-landingspagina's

>90%

Snellere ontwikkeling en testdoorlooptijd voor nieuwe Pensionbazaar-pagina's, van ongeveer 4 dagen tot een paar uur

>90%

Minder UI-bugs in nieuwe Pensionbazaar-schermen

De uitdaging: snelle code, langzame verificatie

Policybazaar en Pensionbazaar liepen tegen 2 verschillende knelpunten aan die de standaard AI-coderingsworkflows niet konden optimaliseren op productieniveau.

Pensionbazaar: Nieuwe schermen met lange QA-cycli

Pensionbazaar had tientallen nieuwe, complexe schermen nodig, zoals de Retirement Freedom Score-calculator met meerdere stappen, aanpasbare prognoses voor investeringskosten en geautomatiseerde aanbevelingsrapporten. Het team heeft ze gebouwd met programmeeragents en de Figma MCP-server, maar door 2 problemen duurden de QA-cycli lang.

Ten eerste moesten de medewerkers coderen zonder te weten wat de andere medewerkers deden. Een basismodel kan code genereren, maar kan de gerenderde interface niet zien, berekende stijlen niet vergelijken met de ontwerpspecificaties, verschuivingen in de vormgeving niet waarnemen en een netwerkwaterfall niet lezen. Gerelateerde problemen zoals afgekapte UI en verschuivingen in de vormgeving kwamen helemaal tot de handmatige QA.

Ten tweede was de gegenereerde code verouderd. Omdat de agents niet op de hoogte waren van het moderne webplatform, vielen ze terug op verouderde tijdelijke oplossingen. Ze schreven zware JavaScript-modals in plaats van het ingebouwde element <dialog> te gebruiken, voegden onnodige polyfills toe en lieten prestatiehints zoals fetchpriority weg.

Policybazaar: 30 landingspagina's en een handmatige controle

Het levensverzekeringsteam van Policybazaar beheert ongeveer 30 landingspagina's voor verschillende verzekeringsproducten. Elke pagina kan variaties hebben voor verschillende marketingcampagnes. Samen ontvangen ze 200.000 tot 300.000 bezoekers per dag en elke pagina krijgt maandelijkse updates voor ontwerp en bedrijfslogica. Het team moet de Core Web Vitals-scores hoog houden en zorgen dat elke variant toegankelijk blijft en correct wordt weergegeven op elk schermformaat.

Voordat we dit automatiseerden, controleerde een engineer elke pagina handmatig:

  1. Voer PageSpeed Insights uit om gebruikersgegevens uit de echte wereld te verzamelen.
  2. Evalueer de scores en aanbevelingen voor Core Web Vitals.
  3. Inspecteer de ontwikkelings- of testversie, stel een diagnose van de problemen achter de scores en pas codecorrecties toe.

Het proces was traag, repetitief en niet schaalbaar. Er was ruimte voor gemiste optimalisaties, inconsistente controledekking, niet-gedetecteerde prestatieproblemen en vertraagde releases.

Voordat de teams hun workflow wijzigden, stelden ze 3 doelen: de tijd die ontwikkelaars besteden aan prestatiecontroles met meer dan 80% verminderen en tegelijkertijd de controledekking continu maken, de doorlooptijd van QA verkorten met geverifieerde rapporten en het aantal UI-bugs verminderen dat werd veroorzaakt doordat een scherm niet overeenkwam met de wireframes.

De oplossing: een code-to-verify-lus

Pensionbazaar overbrugde de kloof tussen code schrijven en code controleren. De agent schrijft de code, start een schone browserinstantie, controleert de pagina programmatisch op visuele pariteit, lay-outfouten, consolefouten en prestaties, en lost de gevonden problemen op met minimale menselijke tussenkomst. De agent haalt het ontwerp op uit Figma MCP, zodat deze de gerenderde pagina kan vergelijken met wat de ontwerpers hebben bedoeld.

Een stroomdiagram met 5 fasen van boven naar beneden. Eerst een Figma-wireframe, gelezen met de Figma MCP-server. Ten tweede: codegeneratie,
            waarbij een programmeeragent wordt begeleid door Modern Web Guidance. Ten derde:
            geautomatiseerde controles in een geïsoleerde browser die is gestart met Chrome
            DevTools voor agents: een controle van de viewport en visuele lay-out, een controle van
            consolefouten en -uitzonderingen en een geautomatiseerde prestatiecontrole.
            Ten vierde, verificatie, waarbij een autonome feedback- en zelfcorrectielus wijzigingen toepast op basis van de auditbevindingen, het resultaat vergelijkt met het oorspronkelijke Figma-wireframe en indien nodig terugkeert naar de audits. Ten vijfde: de resulterende definitieve geverifieerde code, inclusief een geautomatiseerd QA-rapport met screenshots.
De code-to-verify-lus van Pensionbazaar. De agent herhaalt de controles en correcties totdat de pagina overeenkomt met het ontwerp en verifieert de code daarna automatisch met een QA-rapport.

In de volgende video zie je deze lus in actie. De agent leest de Figma-ontwerpen voor een nieuw scherm, implementeert het en gebruikt Chrome DevTools voor agents om de gerenderde pagina te inspecteren en de gevonden verschillen op te lossen.

De programmeeragent van Pensionbazaar implementeert een scherm op basis van Figma-ontwerpen en gebruikt daarna Chrome DevTools voor agents om het te verifiëren en te corrigeren.

Stap 1: De agent baseren op moderne webstandaarden

Het team van Pensionbazaar wilde dat de gegenereerde code de best practices voor het moderne web volgde, de huidige platformfuncties gebruikte en nog steeds werkte in oudere browsers. Het is vervelend om dat handmatig te controleren en medewerkers zijn niet altijd up-to-date met het platform. Modern Web Guidance lost dit probleem op. Het is een agentvaardigheid, geschreven en onderhouden door webexperts van Chrome en de webcommunity, die meer dan 200 use cases dekt. De tool stuurt agents naar moderne webplatform-API's en naar best practices voor prestaties en toegankelijkheid die passen bij je Baseline-doel. Als je geen doel instelt, wordt standaard Baseline Widely Available gebruikt.

Nadat de agent context uit de Figma-bestanden heeft opgehaald, gebruikt deze Modern Web Guidance bij het schrijven van code. Voor Pensionbazaar veranderde dit de code op 3 manieren:

  • Native elementen hebben JavaScript-workarounds vervangen. De agent gebruikte het ingebouwde element <dialog> en de Popover API voor modale vensters met abonnementsgegevens, en CSS Grid en Flexbox voor kaarten met financiële overzichten.
  • De agent heeft prestatietips toegevoegd die basismodellen meestal weglaten. Deze omvatten fetchpriority="high" op hero LCP-afbeeldingen, loading="lazy" op plan-kaarten onder de vouw en een op tijd gebaseerd uitvoeringsbudget met scheduler.yield() om Interaction to Next Paint (INP) te beschermen.
  • Moderne functies zorgden niet voor problemen in oudere browsers. Pensionbazaar ondersteunt oudere browserversies, die worden gedefinieerd in Browserslist. De agent gebruikte functies zoals de CSS-pseudoklasse :user-invalid en autoComplete="one-time-code" in het veld voor eenmalige wachtwoorden (OTP). Oudere browsers negeren ze en de kernfunctionaliteit blijft werken.

De basismodellen zaten er niet ver naast. Het team ontdekte dat ze voor ongeveer 70% overeenkwamen met de best practices. In het eigen rapport van de agent stonden 12 Modern Web Guidance-regels die de resterende kloof overbrugden. 4 voorbeelden:

Gebied De kloof tussen basismodellen De regel Modern Web Guidance
Afbeelding wordt geladen Hallucinaties van conflicterende combinaties, zoals fetchpriority="high" met loading="lazy". Verbiedt expliciet om ze te combineren en beperkt afbeeldingen met hoge prioriteit tot 1 of 2 per pagina.
Stabiliteit van de indeling content-visibility: auto voorgesteld voor prestaties, maar contain-intrinsic-size weggelaten. Hiervoor moeten de 2 property's worden gekoppeld om ernstige verschuivingen in de indeling te voorkomen wanneer content wordt gerenderd.
Primaire thread opbrengst scheduler.yield() wordt algemeen gebruikt zonder deadlinepatroon. Handhaaft een strikte tijdgebaseerde deadline (performance.now() + 50) om Interaction to Next Paint (INP) te beschermen.
Caching van service worker Er is geen rekening gehouden met offline formulierinzendingen. Waarschuwt de agent dat servicemedewerkers niet-GET-verzoeken niet native kunnen cachen.

Voor Pensionbazaar was het onze prioriteit om vanaf dag één code van hoge kwaliteit te schrijven om later technische problemen te voorkomen. Modern Web Guidance stuurde onze programmeeragent aan om moderne webstandaarden en best practices voor prestaties te gebruiken, terwijl onze specifieke doelen voor browsercompatibiliteit werden gerespecteerd. Hierdoor werden onze code-reviews voor de frontend aanzienlijk makkelijker en sneller, waardoor we uiteindelijk sneller konden ontwikkelen.

Aman Soni, Engineering Manager, Policybazaar

Stap 2: Geef de agent een browser

Chrome DevTools voor agents is een set tools, waaronder een MCP-server, een CLI en agentvaardigheden, die programmeeragents realtime toegang geven tot runtime-foutopsporingsgegevens, zoals consolelogboeken, netwerkverkeer, de toegankelijkheidsstructuur en andere DevTools-mogelijkheden.

Het team installeerde Chrome DevTools voor agents als plug-in in hun programmeeragent, Claude Code:

# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp

# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

Het team wilde dat elke test werd uitgevoerd in een schone browserinstantie, zodat geïnstalleerde Chrome-extensies de resultaten niet konden beïnvloeden en persoonlijke of gevoelige gegevens niet konden lekken. Voeg hiervoor --isolated toe aan de args- matrix in de MCP-serverconfiguratie:

{
  "args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}

Als je tests een bestaande ingelogde browsersessie nodig hebben, gebruik je --autoConnect.

Stap 3: Laat de agent het eigen werk controleren en corrigeren

Het technische team vermeldt de controles in de instructies van de agent, als prompt of als vaardigheid van de agent. In grote lijnen doet de agent het volgende:

  • Inspecteert de DOM-boomstructuur en berekende CSS en vergelijkt deze met het Figma-ontwerp.
  • Past het formaat van de pagina aan mobiele viewports aan om de responsiviteit te testen.
  • Registreert prestatietraces om lange animatieframes (LoAF) te vinden die worden veroorzaakt door scripts, bronnen die de weergave blokkeren en andere prestatieproblemen.
  • Herschrijft code om ontwerpfouten, prestatieproblemen en console-uitzonderingen op te lossen voordat een engineer deze beoordeelt.

In de volgende tabel staat welke Chrome DevTools voor agents-tools elke controle ondersteunen:

Aanvinken Tools
Responsiviteit testen in verschillende weergavegebieden resize_page past het formaat van het venster van de pagina aan naar expliciete afmetingen. emulate emuleert specifieke apparaatomgevingen. take_screenshot legt het resultaat vast.
Vergelijk de DOM en berekende CSS met het Figma-ontwerp take_snapshot retourneert een tekstmomentopname van de pagina op basis van de toegankelijkheidsstructuur. get_css_styles leest toegepaste CSS-regels. evaluate_script voert een JavaScript-functie uit op de pagina.
LoAF, weergaveblokkerende bronnen en problemen met Core Web Vitals vinden click en drag bootsen interacties na. performance_start_trace en performance_stop_trace nemen een prestatietracering op. performance_analyze_insight retourneert gedetailleerde diagnostische gegevens voor de inzichten in de trace. list_network_requests en get_network_request tonen netwerkactiviteit. lighthouse_audit controleert niet-prestatiegebieden zoals SEO en toegankelijkheid.

Als de agent een probleem vindt, zoals tekst die wordt afgekapt op kleine schermen, een verbroken flex wrap of een niet-geoptimaliseerde afbeelding die een verschuiving van de indeling veroorzaakt, voert deze een korte correctielus uit:

  1. Chrome DevTools voor agents legt de exacte fout vast.
  2. De agent analyseert de gegevens en herschrijft de problematische CSS of JavaScript.
  3. De medewerker laadt de pagina opnieuw om de oplossing te bevestigen.

Op één scherm gaf de agent de pagina weer en ontdekte dat de lay-out, de afstand en het kleurverloop van de kop niet overeenkwamen met het ontwerp. De relevante .scss-bestanden zijn hersteld. De tool voerde ook interacties uit met de pagina, zoals het uitvouwen van accordeons om te controleren of de geopende statussen overeenkwamen met de ontwerpen.

Stap 4: Geef QA een geverifieerd rapport

Als de verificatie is afgerond, levert de agent productieklare code en een auditrapport voor het QA-team. Het rapport bevat de volgende elementen:

  • Een visuele vergelijking met het Figma-ontwerp die pixelverschillen benadrukt, opgebouwd uit screenshots, DOM-snapshots en berekende stijlen.
  • Screenshots van de weergegeven pagina bij verschillende schermformaten.
  • Core Web Vitals en prestatiediagnose van performance_start_trace en performance_analyze_insight, zoals Speed Index en Total Blocking Time (TBT).
  • Lighthouse-scores voor SEO, best practices en toegankelijkheid van lighthouse_audit.
  • Controles op geslaagd of mislukt voor interacties, zoals rijen samenvouwen en schakelaars, plus consolefouten en wijzigingen in de app-status, zoals rijen bewerken, rijen verwijderen en lege statussen.
Een QA-rapport voor de detailpagina met financiële gegevens van de klant met het Figma-ontwerp, de implementatie en een pixel-diff naast elkaar, waarbij 98,7% en 97,1% van de pixels overeenkomen.
Door de agent gegenereerde visuele vergelijking tussen de gerenderde pagina (vastgelegd met Chrome DevTools voor agents) en Figma-ontwerpspecificaties, waarbij verschillen per pixel worden gemarkeerd.
Een Lighthouse-rapporttabel voor de productiebuild. De mobiele en desktopscores zijn 90 en 93 voor prestaties, 91 voor toegankelijkheid, 100 voor best practices en 92 voor SEO. Statistieken
            omvatten een Largest Contentful Paint van 2,1 seconden op mobiel en
            0,5 seconden op desktop, 0 milliseconden Total Blocking Time en
            een Cumulative Layout Shift van 0,006 op mobiel en 0,001 op
            desktop.
Lighthouse- en Core Web Vitals-scores op mobiel en desktop.

Dezelfde aanpak toepassen op 30 campagnepagina's

Op het hoofdplatform verving Policybazaar handmatige PageSpeed Insights-uitvoeringen door audits die werden uitgevoerd via Chrome DevTools voor agents in Kiro. Voordat een campagnepagina live gaat, voert een engineer een controle uit op de staging-URL voor mobiel en desktop. De agent voert prestatie- en Lighthouse-controles uit en Chrome DevTools voor agents haalt automatisch praktijkgegevens uit het Chrome User Experience Report (CrUX) op naast de labgegevens. Dat verving de PageSpeed Insights-stap volledig.

De agent rapporteert daarna de prestatiescores, de gevonden knelpunten en een lijst met prioriteiten voor verbeteringen die een engineer kan oplossen. Tijdens een pre-releasecontrole werden niet-kritieke API-aanroepen gemarkeerd die elkaar snel opvolgden tijdens het laden van de pagina en concurreerden met kritieke weergaveprocessen. Het team heeft het probleem opgelost voordat de pagina live ging.

De agent voert nu 12 prestatiecontroles uit in de tijd die een engineer nodig heeft om er één af te ronden. Dat is een vermindering van 92% in handmatige inspanningen.

Kiro gebruikt Chrome DevTools voor agents om Lighthouse-controles en prestatietraceringen uit te voeren op een Policybazaar-landingspagina en vermeldt daarna de prestatieproblemen die worden gevonden.

Webprestaties zijn belangrijk voor ons om een goede gebruikerservaring te behouden, maar handmatig controleren en watervallen en traceringen evalueren op tientallen landingspagina's was vervelend en een groot knelpunt. Chrome DevTools voor agents heeft dit proces getransformeerd en de tijd die onze technici besteden aan prestatiecontroles met 92% verminderd, zodat ze zich kunnen richten op complexere taken.

Aman Soni, Engineering Manager, Policybazaar

Impact

Met Modern Web Guidance en Chrome DevTools voor agents is de frontend-test bij Policybazaar en Pensionbazaar veranderd van een handmatig, reactief proces in een geautomatiseerd, proactief proces. In de volgende tabel worden de workflows vóór en na de wijziging vergeleken:

Gebied Eerder: handmatige beoordeling en basismodellen Na: Modern Web Guidance en Chrome DevTools voor agents
Prestatiecontrole (Policybazaar) Een engineer voerde PageSpeed Insights uit, beoordeelde de Core Web Vitals en paste handmatig oplossingen toe voor elk van de ongeveer 30 landingspagina's. 92% minder handmatige inspanning. De agent voert 12 controles uit in de tijd die een technicus nodig heeft voor één controle.
Controledekking (Policybazaar) De controledekking voor campagnevarianten was inconsistent. 100% dekking van prestatietests voor campagnepagina's.
Nieuwe schermomlooptijd (Pensionbazaar) Een paar dagen van code tot geverifieerd scherm. Een paar uur, meer dan 90% sneller.
Design parity bugs (Pensionbazaar) Afgekapte UI en indelingsverschuivingen hebben handmatige QA bereikt. Er werden meer dan 90% minder UI-bugs gemeld.

De vermindering van 92% overtrof het doel van het team van meer dan 80%. Regressies op de landingspagina worden opgemerkt voordat ze de staging- of QA-fase bereiken. Op Pensionbazaar wordt code geleverd die al is gecontroleerd met screenshots voor verschillende viewports. Dit vermindert de communicatie tussen ontwerp, engineering en QA.

Belangrijke punten voor je team

  • Onderbouw je agent met gezaghebbende richtlijnen. Met beheerde richtlijnen zoals Modern Web Guidance blijven agents weg van verouderde patronen en blijft je code binnen je basisdoelen.
  • Laat een agent een frontend-taak pas als klaar markeren nadat deze de gerenderde pagina heeft gecontroleerd. Met Chrome DevTools voor agents kan de agent de vormgeving, viewports en prestatiesporen inspecteren in een echte browser.
  • Geef de loop duidelijke afsluitcriteria. Stel staplimieten en expliciete voorwaarden voor slagen en mislukken in, zodat de agent niet in een lus terechtkomt en tokens verspilt.
  • Begin met pagina's die vaak worden bezocht en die op templates zijn gebaseerd. Closed-loop workflows zijn het meest waardevol als de doorlooptijd belangrijk is.
  • Voer controles uit in een schone browser. Gebruik --isolated zodat extensies en gegevens in het cachegeheugen geen invloed hebben op de resultaten en er geen persoonsgegevens worden blootgesteld.

Bronnen