Ladda en chattwidget med perfekta Core Web Vitals

Ladda en chattwidget som inte påverkar PageSpeed och Core Web Vitals

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-07

Så laddar du en chattwidget på rätt sätt!

Jag har sagt det om och om igen. Vissa skript är viktigare än andra. Ingen i internets historia har någonsin blivit irriterad över att en chattwidget inte har laddats under de första 500 ms av sidladdningen. Den tiden då sidan fortfarande är blank.

Det vore ju meningslöst att ladda en chattwidget innan sidans huvudinnehåll ens har börjat laddas? Nej, det vore mycket vettigare att först ladda de viktigaste delarna (din logotyp, din huvudbild, dina stilmallar, dina typsnitt, kanske några superviktiga skript som hanterar navigering och konvertering)

Tyvärr är det inte så de flesta webbplatser gör. Dagligen ser jag oviktiga skript (som chattskript) laddas med högsta prioritet direkt vid sidladdningens start.

I den här artikeln förklarar jag hur man korrekt laddar ett chattskript och hur detta påverkar viktiga mätvärden som Largest Contentful Paint och Interaction to Next Paint.

Bakgrund: hur fungerar chattwidgets?

En chattwidget fungerar vanligtvis genom att ladda ett litet skript på din sida. Det skriptet laddar sedan några stilmallar och injicerar en iframe på din sida. En iframe är en liten isolerad webbsida inom en webbsida. Och den iframen hanterar allt som behövs för att chatta med dina kunder.

Hur påverkar chattwidgets Core Web Vitals?

Chattwidgets påverkar Core Web Vitals på flera sätt:

1. De påverkar First Contentful Paint och Largest Contentful Paint genom att konkurrera om tidiga nätverksresurser.

2. De påverkar Interaction to Next Paint genom att blockera huvudtråden och ibland genom att långsamt uppdatera efter interaktion.

3. De kan orsaka layoutförskjutningar när de inte renderas korrekt på sidan

Largest Contentful Paint-problem orsakade av chattwidgets

En chattwidget kan påverka Core Web Vitals när den konkurrerar om nätverksresurser. JavaScript köas vanligtvis för nedladdning tidigare än bilder. Det innebär att i värsta fall (när chattskriptet är renderingsblockerande) måste webbläsaren vänta på att chattskriptet laddas ner och körs innan den kan fortsätta med något annat.

Även när chattskriptet har defer-attribut kan det fortfarande påverka målvärdena på några sätt. Låt mig först förklara vad deferred-skript gör. Webbläsaren kan ladda ner deferred-skript parallellt och webbläsaren kan fortsätta rendera tills DomContentLoaded-eventet. Därefter körs skripten. Problemet är att för återkommande besökare har LCP-elementet förmodligen inte laddats vid DomContentLoaded-eventet, men det (cachade) chattskriptet kommer att köras och orsaka en fördröjning i LCP-mätvärdena.

Interaction to Next Paint (INP)-problem orsakade av chattwidgets.

En chattwidget kan och kommer att påverka Interaction to Next Paint på 2 sätt. Det första sättet är genom att blockera huvudtråden under en kort tid medan chattwidgeten kör sina skript eller söker efter uppdateringar. Det är bara så det fungerar. Allt du lägger till på en sida gör sidan lite långsammare. 

Det andra sättet det kan orsaka INP-problem är genom dålig kodning (och tro mig, det finns en del dåligt kodade chattwidgets där ute). När det gäller chattwidgets betyder "mer populär" inte "bättre kodad". När dålig kod tar lång tid att uppdatera presentationen får du automatiskt INP-problem. Jag antar att vissa chattleverantörer behöver höja sin nivå. Den här delen ligger tyvärr utanför min kontroll. Om du har valt en "dåligt kodad" chattwidget finns det inget sätt för mig att göra den koden bättre. 

Layout Shift (CLS)-problem orsakade av chattwidgets

Ibland orsakar chattwidgets en layoutförskjutning. Det finns 3 vanliga orsaker som jag letar efter när jag kontrollerar chattwidget-relaterade layoutförskjutningar.

  • Layoutförskjutningar som inträffar varje gång chatten laddas
  • Layoutförskjutningar som sker vid en fördröjd chattöppning
  • Layoutförskjutningar som inträffar när en chatthistorik laddas (återkommande chattbesökare)

Så fixar du Core Web Vitals-problem orsakade av chattskript

Lyckligtvis är det ganska enkelt att minimera den påverkan en chattwidget kan ha på målvärdena (LCP och FCP) och på vissa delar av Interaction to Next Paint (INP). I min inledning sa jag att skript har en tid och en plats. Och för chattskript är det inte "direkt och till varje pris". Jag laddar helst chattskript efter load-eventet, när sidan inte svarar på användarinteraktion och jag föredrar också att kringgå preload-skannern för att undvika nätverkskonkurrens. 

Så hur gör vi det? Vi använder load-eventet eftersom LCP-elementet redan har målats på sidan när load-eventet har utlösts (om du inte har lazy-laddat det med JavaScript). Vi använder requestIdleCallback för att vänta på ett ledigt ögonblick när webbläsaren inte svarar på användarinteraktion. Och vi använder JavaScript för att injicera chattskriptet så att preload-skannern inte omedelbart känner igen skriptets src och utlöser en tidig nedladdning (och det är precis det vi vill undvika!)

<script>
<script>

Fixa Cumulative Layout Shift-problem orsakade av chattwidgets

Chattwidgets orsakar vanligtvis en liten layoutförskjutning. Det behöver inte vara ett stort problem. Men ibland renderas chattwidgets helt enkelt dåligt. Lyckligtvis kan vi (i viss mån) fixa det också genom att dölja den dåliga renderingen tills widgeten har renderats klart.

För att göra detta behöver vi läsa dokumentationen för chattwidgeten (det finns många olika chattleverantörer och de fungerar alla lite olika). I dokumentationen, leta efter callback-funktioner som anropas i olika stadier av chattens rendering. Eftersom jag inte vet vilken chattwidget du använder kommer vi för att illustrera mekanismen att använda chat.ready()-funktionen.

Nu med lite smart styling kan vi dölja och visa chatten med CSS opacity-egenskapen. Först lägger vi till några klasser för att dölja chattwidgeten som standard (ändra selektorerna så att de matchar din chattwidget). Sedan i chat.ready()-callbacken lägger vi till 'showchat' i body-klasslistan för att aktivera den andra CSS-raden som visar chatten igen.
<style>
/*hide chat widget by default*/
.chatwidget{opacity:0}
/*show chat widget after .showchat body class*/
body.showchat .chatwidget {opacity:1}
<style>
<script>
chat.ready(function(){
  document.documentElement.classList.add('showchat');})
<script>

Det var allt! Lycka till med att snabba upp din chattwidget

Urgent Fix Required?

Google Search Console failing? I offer rapid-response auditing to identify the failure point within 48 hours.

Request Urgent Audit >>

  • 48hr Turnaround
  • Rapid Response
  • Failure Identification
Ladda en chattwidget med perfekta Core Web VitalsCore Web Vitals Ladda en chattwidget med perfekta Core Web Vitals