Wijzigingen in het BFCache-gedrag met extensieberichtpoorten

Back/forward cache (of BFCache) is een browseroptimalisatie die directe terug- en vooruitnavigatie mogelijk maakt. We brengen wijzigingen aan in Chrome BFCache die mogelijk van invloed zijn op extensies die berichtpoorten gebruiken. Als u over een Chrome-extensie beschikt die berichten gebruikt om te communiceren tussen inhoudscripts en uw extensie, lees dan verder voor meer informatie over hoe u uw extensie kunt testen en aanpassen.

Extensie berichtpoort

Extensies communiceren met het inhoudsscript of andere extensies via het doorgeven van berichten. Berichten kunnen worden verzonden met eenmalige verzoeken door runtime.sendMessage() en tabs.sendMessage() aan te roepen, of door een herbruikbare berichtenpoort te gebruiken. Zolang de poort actief is, kunnen zowel het inhoudsscript als het extensie-achtergrondscript de poort hergebruiken om berichten naar elkaar te posten.

Zie Bericht doorgeven voor meer informatie.

Achterwaartse/voorwaartse cache

Wanneer u weg navigeert van een pagina die in aanmerking komt voor BFCache , staat de browser toe dat de pagina met al zijn status in het geheugen blijft, maar in de niet -volledig actieve status. Als de gebruiker een geschiedenisnavigatie uitvoert (terug of vooruit) naar de in de cache opgeslagen pagina, zal de browser proberen de pagina vanuit BFCache te herstellen. Dit maakt de navigatie sneller en verbetert de browse-ervaring van de gebruiker.

Terwijl de pagina zich in BFCache bevindt, bevindt deze zich in een bevroren toestand waarin geen JavaScript-uitvoering is toegestaan. Dit betekent dat het de ontvangen berichten niet kan verwerken.

Zie Terug/voorwaartse cache voor meer informatie.

De impact van extensieberichtpoorten op BFCache

Kortom, het verzenden van berichten naar een pagina in BFCache door de extensie kan ervoor zorgen dat de cache wordt verwijderd en de prestaties worden beïnvloed.

Wanneer een pagina met een open extensieberichtpoort wordt opgeslagen in BFCache, blijft de poort open. Zodra de pagina is hersteld vanuit BFCache, kan de oude referentie van de berichtenpoort nog steeds worden gebruikt door de extensieservicemedewerkers om berichten naar het inhoudsscript te posten.

Als de extensie echter probeert een bericht via die berichtenpoort te plaatsen terwijl de pagina zich nog in BFCache bevindt, wordt het bericht verzonden maar niet volledig afgeleverd omdat de handler vastloopt. Het is een uitdaging voor de extensie om over deze situatie te redeneren en deze aan te pakken, omdat zowel het in de wachtrij plaatsen als het laten vallen van het bericht hun eigen problemen hebben.

Om te voorkomen dat we ingaan op de problemen met betrekking tot verloren berichten, wordt in de huidige implementatie van Chrome de hostpagina uit BFCache verwijderd en wordt het bericht verwijderd. Als de gebruiker teruggaat naar de pagina, wordt deze opnieuw geladen, waardoor de extensie een nieuwe verbinding kan opzetten.

Aan de andere kant beperkt deze implementatie de scenario's waarin BFCache van toepassing is, waardoor de prestatiewinst wordt beperkt, vooral voor extensies met broadcast- of heartbeat-mechanismen die regelmatig berichten naar alle verbindingen sturen. Omdat de uitzetting wordt geactiveerd wanneer de extensie een bericht naar het inhoudsscript stuurt, hebben webontwikkelaars bovendien geen middelen om te voorkomen dat hun pagina's worden uitgezet.

Om de algehele prestaties te verbeteren, zijn we van plan een nieuw berichtenpoortgedrag te introduceren.

Nieuw gedrag: het berichtenkanaal sluiten wanneer de pagina is opgeslagen in BFCache

Vanaf Chrome 123 wordt, wanneer een pagina met een open extensie-berichtpoort wordt opgeslagen in BFCache, het onderliggende berichtenkanaal proactief gesloten vanaf de kant van het inhoudsscript. Als gevolg hiervan worden alle berichtpoorten gesloten en ontvangt de extensie een onDisconnect gebeurtenis.

Omdat het kanaal gesloten is, worden er geen berichten naar de pagina verzonden terwijl deze zich in BFCache bevindt. Daarom wordt de pagina niet verwijderd vanwege de extensie.

Zelfs nadat de pagina vanuit BFCache is hersteld, wordt het gesloten berichtenkanaal niet opnieuw geopend. De aanbevolen praktijk voor auteurs van extensies is om naar de levenscyclusgebeurtenissen van de pagina te luisteren en een nieuwe verbinding in te stellen wanneer de pagina wordt hersteld vanuit BFCache, zoals weergegeven in het volgende voorbeeld.

// content script

let port;

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // The page is restored from BFCache, set up a new connection.
    port = chrome.runtime.connect();
  }
});

Lees meer over het WECG-gesprek van vertegenwoordigers van verschillende browsers (onder nummer 474).

Ben ik beïnvloed?

Het nieuwe gedrag zal beschikbaar zijn achter een vlag in Chrome 123, zodat u uw code kunt testen. Zie de tijdlijn voor meer informatie. Gebruik de volgende stappen om uw extensie te testen. Houd er rekening mee dat het slechts een eenvoudige test is. We raden u aan Chrome gedurende een bepaalde periode te gebruiken terwijl de functie is ingeschakeld, omdat het moeilijk kan zijn om te voorspellen welke functies in de extensie problemen kunnen veroorzaken.

  1. Zorg ervoor dat de Chrome-versie minimaal 123 is. Gebruik idealiter Chrome Canary, dat een extra waarschuwing heeft om het testen eenvoudiger te maken.
  2. Start Chrome met de volgende vlag:

    --disable-features=DisconnectExtensionMessagePortWhenPageEntersBFCache
    
  3. Ga naar een pagina die in aanmerking komt voor BFCache zonder dat de extensie actief is (bijvoorbeeld een eenvoudige site zoals https://example.com/ ). Volg de BFCache-tutorial om ervoor te zorgen dat deze wordt hersteld vanuit BFCache.

  4. Installeer en schakel de extensie in en test opnieuw of u in aanmerking komt voor BFCache. U kunt handmatig weg navigeren, enige tijd wachten die lang genoeg is totdat uw extensie een bericht op de BFCached-pagina plaatst, en terug navigeren.

  5. Als de pagina vanwege een uitzetting opnieuw moest worden geladen in plaats van uit BFCache, en het probleem dat herstel verhindert "ExtensionSentMessageToCachedFrame" is, kan deze wijziging gevolgen hebben voor de extensie.

    In Chrome Canary 124.0.6315.0 en nieuwer ziet u ook de volgende waarschuwing op de pagina:

    Waarschuwing weergegeven wanneer een pagina niet wordt hersteld vanuit BFCache.
    Waarschuwing weergegeven wanneer een pagina niet wordt hersteld vanuit BFCache.

Zodra is bevestigd dat de extensie berichten op de BFCache-pagina plaatst, kunt u deze stappen volgen om het experiment geforceerd in te schakelen en te kijken of er logica kapot gaat.

  1. Start Chrome met de volgende vlag:

    --enable-features=DisconnectExtensionMessagePortWhenPageEntersBFCache
    
  2. Ga naar de pagina die niet is hersteld vanuit BFCache vanwege "ExtensionSentMessageToCachedFrame".

  3. Navigeer heen en terug. De pagina zou nu moeten worden hersteld, maar het berichtenkanaal tussen het inhoudsscript en de servicemedewerker moet worden verbroken.

  4. Test of de extensie nog steeds werkt zoals gewoonlijk. Als dit niet het geval is, moet u handmatig opnieuw verbinding maken, zoals gedemonstreerd in de vorige sectie.

Tijdlijn vrijgeven

We zijn van plan het nieuwe gedrag geleidelijk op te voeren, te beginnen in Chrome 123. Hier is het gedetailleerde plan:

Datum Geplande mijlpaal
15 februari Start het experiment voor het nieuwe gedrag in Chrome Canary en Dev.
1 maart Start het experiment voor het nieuwe gedrag in Chrome Bèta.
18 maart Geef het nieuwe gedrag vrij aan 4 procent van de gebruikers in Chrome Stable.
25 maart Geef het nieuwe gedrag vrij aan 50 procent van de gebruikers in Chrome Stable.
2 april Het experiment eindigt, waardoor het nieuwe gedrag de standaard wordt.