Asynkron distribution asynchronous-deployment
Prestanda och en icke-blockerande driftsättning av JavaScript-bibliotek som våra produkter kräver blir allt viktigare för Adobe Experience Cloud-användare. Verktyg som Google PageSpeed rekommenderar användare att ändra sitt sätt att distribuera Adobe-bibliotek på sin plats. I den här artikeln beskrivs hur du använder Adobe JavaScript-bibliotek på ett asynkront sätt.
Synkron jämfört med asynkron
Synkron distribution
Bibliotek läses ofta in synkront i taggen <head> på en sida. Exempel:
<script src="example.js"></script>
Som standard tolkar webbläsaren dokumentet och når den här raden. Sedan börjar webbläsaren hämta JavaScript-filen från servern. Webbläsaren väntar tills filen har returnerats, tolkar och kör sedan JavaScript-filen. Slutligen fortsätter den att analysera resten av HTML-dokumentet.
Om tolken träffar på <script>-taggen innan synligt innehåll återges, fördröjs visningen av innehållet. Om den JavaScript-fil som läses in inte är absolut nödvändig för att visa innehåll för dina användare, behöver besökarna inte vänta på innehåll. Ju större bibliotek, desto längre fördröjning. Därför flaggar prestandatestverktyg för webbplatser som Google PageSpeed eller Lighthouse ofta synkront inlästa skript.
Tagghanteringsbibliotek kan snabbt bli stora om du har många taggar att hantera.
Asynkron distribution
Du kan läsa in alla bibliotek asynkront genom att lägga till ett async-attribut till <script>-taggen. Exempel:
<script src="example.js" async></script>
Detta anger för webbläsaren att när skripttaggen tolkas ska webbläsaren börja läsa in JavaScript-filen, men i stället för att vänta på att biblioteket ska läsas in och köras bör den fortsätta att analysera och återge resten av dokumentet.
Att tänka på vid asynkron distribution
I synkrona distributioner pausar webbläsaren parsning och återgivning av sidan medan taggbiblioteket i Adobe Experience Platform läses in och körs, vilket beskrivs ovan. I asynkrona distributioner fortsätter webbläsaren däremot att analysera och återge sidan medan biblioteket läses in. Variabiliteten i när taggbiblioteket kan slutföra inläsningen i relation till sidtolkning och återgivning måste beaktas.
För det första, eftersom taggbiblioteket kan slutföra inläsningen före eller efter sidans nederkant har tolkats och körts, bör du inte längre anropa _satellite.pageBottom() från sidkoden (_satellite är inte tillgängligt förrän biblioteket har lästs in). Detta förklaras i Inläsning av taggarna bäddar in kod asynkront.
För det andra kan taggbiblioteket slutföra inläsningen före eller efter att webbläsarhändelsen DOMContentLoaded (DOM Ready) har inträffat.
På grund av dessa två punkter är det värt att visa hur händelsetyperna Library Loaded, Page Bottom, DOM Ready och Window Loaded från Core-tilläggsfunktionen när ett taggbibliotek läses in asynkront.
Om taggegenskapen innehåller följande fyra regler:
- Regel A: använder händelsetypen Library Loaded
- Regel B: använder händelsetypen Sidunderkant
- Regel C: använder händelsetypen DOM Ready
- Regel D: använder händelsetypen Window Loaded
Oavsett när taggbiblioteket har lästs in, kommer alla regler garanterat att köras och de kommer att köras i följande ordning:
Regel A → Regel B → Regel C → Regel D
Även om ordningen alltid används, kan vissa regler köras direkt när taggbiblioteket har lästs in, medan andra kan köras senare. Följande inträffar när taggbiblioteket har lästs in:
- Regel A verkställs omedelbart.
- Om webbläsarhändelsen
DOMContentLoaded(DOM Ready) redan har inträffat körs regel B och regel C omedelbart. Annars körs regel B och regel C senare när webbläsarhändelsenDOMContentLoadedinträffar. - Om webbläsarhändelsen
load(inläst fönster) redan har inträffat körs regel D omedelbart. Annars kommer regel D att köras senare när webbläsarhändelsenloadinträffar. Observera, att om du har installerat taggbiblioteket enligt instruktionerna, avslutas inläsningen av taggbiblioteket alltid innan webbläsarhändelsenloadinträffar.
När du tillämpar dessa principer på din egen webbplats bör du tänka på följande:
- En regel som använder händelsetypen Library Loaded kan köras innan datalagret har lästs in helt. Detta kan leda till att regelns åtgärder körs med data som saknas eftersom data ännu inte var tillgängliga på sidan. Den här typen av problem kan åtgärdas genom att du anpassar regelkonfigurationen. I stället för att ha en regel som aktiveras av händelsetypen Biblioteksinläsning kan du i stället använda händelsetypen Anpassad händelse eller Direktanrop som aktiveras av sidkoden så fort datalagret har lästs in.
- Händelsetypen Sidundersida ger inte särskilt mycket värde när biblioteket läses in asynkront.Överväg i stället att använda händelsetyperna Library Loaded, DOM Ready, Window Loaded eller någon annan.
Om du ser saker som inte fungerar som de ska är det troligt att du har timingproblem att gå igenom. Distributioner som kräver exakt timing kan behöva använda händelseavlyssnare och händelsetypen Custom Event eller Direct Call för att göra implementeringarna mer stabila och konsekventa.
Inläsning av taggar bäddar in kod asynkront
Med taggar kan du aktivera asynkron inläsning när du skapar en inbäddningskod när du konfigurerar en miljö. Du kan också konfigurera asynkron inläsning själv:
-
Lägg till ett asynkront attribut i taggen
<script>för att läsa in skriptet asynkront.För taggarnas inbäddningskod innebär det att du ändrar detta:
code language-markup <script src="//www.yoururl.com/launch-EN1a3807879cfd4acdc492427deca6c74e.min.js"></script>till detta:
code language-markup <script src="//www.yoururl.com/launch-EN1a3807879cfd4acdc492427deca6c74e.min.js" async></script> -
Ta bort kod som du tidigare har lagt till längst ned i taggen:
code language-markup <script type="text/javascript">_satellite.pageBottom();</script>Den här koden anger för plattformen att webbläsarparsern har nått sidans nederkant. Det är troligt att taggar inte har lästs in och körts tidigare. Därför genereras ett fel om
_satellite.pageBottom()anropas och händelsetypen för sidnederkant kanske inte fungerar som förväntat.