← Alle innlegg

Slik fekk vi Lavenity-knappen til å dukke opp på under 100 ms

Ein lastar på 2,9 kB gzip, umiddelbar vising av knappen og førehandslasting i ledig tid held chatten unna den kritiske lastesløyfa.

Ein kundeservicewidget bør vere raskt tilgjengeleg utan å konkurrere med sida han skal hjelpe. Vi bygde lastesekvensen i Lavenity om rundt akkurat den grensa: teikn den vesle knappen først, og førebu så heile samtaleopplevinga når nettlesaren har plass.

Difor blir knappen lasta for seg

Innbyggingslastaren er 8 058 byte ukomprimert og 2 947 byte med gzip i den noverande produksjonsbygginga. Han blir lasta med ein async script-tagg, injiserer eit lite isolert stilark og lagar knappen med reine nettlesar-API-ar. Vue, samtalehistorikk, WebSocket-oppsett og ekstern arbeidsromskonfigurasjon trengst ikkje før knappen kan visast.

Den tyngre chat-applikasjonen held seg isolert i ein iframe. Etter at knappen er montert, ber Lavenity requestIdleCallback om å førehandslaste ramma, med eit tidsavbrot som reserveløysing. Det held ramma unna den første teikninga til vertssida, samstundes som den første opninga kjennest klar. Klikkar ein besøkjande før den ledige oppgåva køyrer, startar det same idempotente rammeoppsettet med ein gong.

Dette målte vi

Vi endra òg hurtigbuffringa for den faste widget.js-adressa. Lastaren kan halde seg fersk i fem minutt og bli revalidert i bakgrunnen i eitt døgn. Gjenbesøk kan difor teiknast frå hurtigbufferen utan å vente på ein blokkerande valideringsførespurnad, medan oppdateringar av lastaren likevel spreier seg raskt.

21. juli 2026 køyrde vi fem lokale Chromium-målingar med tømd hurtigbuffer, frå skriptet vart sett inn til knappen var klar. Knappen kom inn i DOM-en på 2,9–3,6 ms og nådde neste teikning på 4,4–8,8 ms. Dei tala isolerer køyringa i nettlesaren på ein lokal tenar; dei inkluderer ikkje DNS, TLS, geografisk forseinking, einingslast eller CDN-veg for ein ekte besøkjande.

Hurtigbuffer, iframe-lasting og det reelle fartsbudsjettet

Det gir eit praktisk budsjett på rundt 100 ms for knappen på eit raskt samband eller eit buffra besøk — snarare enn å gjere 100 ms om til ein universell lovnad. Faktiske tider vil variere, så vi held fram med å måle persentilar i produksjon etter kvart som trafikken veks. Det nyttige tekniske resultatet er at det lokale arbeidet tek under 10 ms og at nettverksoverføringa berre er 2,9 kB gzip.

Den synlege knappen er no den billegaste delen av opplevinga, og heile appen ventar på tur. Det er den åtferda vi vil ha frå innebygd kundeservice: til stades når kunden treng han, stille medan resten av nettstaden blir lasta.

Slik testar du chat-widgeten på din eigen nettstad

Mål minst to tilstandar: eit førstegongsbesøk med tom hurtigbuffer og eit gjenbesøk. Sjekk når knappen dukkar opp, endringar i Largest Contentful Paint og Total Blocking Time, og tida det tek å opne heile chatten. Éi lokal køyring kan ikkje representere eit mobilnett, ei tregare eining eller geografisk forseinking.

Samanlikn den same sida under dei same forholda, i staden for å samanlikne overskriftstal frå urelaterte køyringar. Er widgeten installert gjennom ein tag manager, ta med forseinkinga frå behaldaren. Knappen kan køyre raskt, men bli vist seint på grunn av rekkjefølgja på taggar, samtykkereglar eller andre skript framfor han.

Ofte stilt spørsmål

Betyr «under 100 ms» den same tida for kvar besøkjande?

Nei. Det er eit praktisk budsjett for eit raskt eller buffra besøk, ikkje ein universell garanti. Faktisk tid avheng av nettverket, eininga, CDN-et, skriptrekkjefølgja og korleis sida blir lasta. I dei lokale målingane våre heldt sjølve køyringa av knappen seg under 10 ms.