Net als Safari is Chrome een doorgang in plaats van één bestemming, en heeft het hetzelfde basisprobleem: het grootste deel van het internet is er doorheen bereikbaar, dus er is geen natuurlijke rand aan een sessie zodra die begint. Chrome voegt iets toe dat Safari's eenvoudigere nieuwe-tabpagina niet heeft: een gepersonaliseerde "Discover"-feed met artikelen, direct onder de adresbalk, op precies het scherm dat vroeger gewoon "typ hier iets" betekende. Een nieuw tabblad openen toont nu op zichzelf al inhoud — geen zoekopdracht nodig.
Wat Chrome écht moeilijk te sluiten maakt
De Discover-feed op Chromes nieuwe-tabpagina betekent dat een leeg tabblad openen nooit echt leeg is — er staat al een scrollbare, algoritmisch gekozen reeks artikelen klaar, wat "laat me even één ding checken" in een browsesessie verandert nog voordat dat ene ding zelfs is opgezocht. Synchronisatie tussen apparaten neemt tabbladen en geschiedenis over van een desktopsessie, dus een onderzoekstraject dat op een laptop begon, verschijnt klaar om verder te gaan op de telefoon, wat één gedachtegang over apparaten heen uitrekt en vaak over de rest van de dag. Als standaardbrowser op de meeste Android-telefoons betekent, net als bij Safari op iPhone, dat een groot deel van de Chrome-sessies begint als bijeffect van ergens anders op een link tikken, niet als een bewuste beslissing om de browser te openen.
De ingebouwde iPhone-route, en waar die het begeeft
Een iOS Screentijd-applimiet op Chrome gedraagt zich zoals bij elke andere app: een waarschuwing, een vergrendelscherm, één knop "Limiet voor vandaag negeren" die alles met één tik opheft, waarvoor je alleen een Screentijd-toegangscode nodig hebt die je zelf hebt ingesteld en kent. Op iPhone is Chrome verplicht om Apples WebKit-engine te gebruiken onder zijn eigen interface, wat beperkt hoe het op systeemniveau kan worden beperkt, verder dan hetzelfde applimietmechanisme dat elke andere app heeft — er is hier geen apart iOS-specifiek gat te beschrijven buiten het gat dat elke app deelt.
De ingebouwde Android-route, en waar die het begeeft
De App-timer van Digitaal welzijn grijst het icoon van Chrome uit bij je limiet en biedt meteen meer tijd aan zodra je erop tikt, op elk moment aan te passen of te verwijderen via Instellingen. Hetzelfde gat als bij de meeste apps hier, plus eentje specifiek voor browsers: omdat Chrome meestal de standaardafhandelaar is voor links die in andere apps worden aangetikt, gebeurt een flink deel van het browsen zonder dat het Chrome-icoon zelf ooit wordt aangetikt, wat de timer geen manier heeft om op te vangen.
Wat er verandert als de tol drie vragen is
Mr. Grummels tol staat vóór het rechtstreeks openen van Chrome, wat een echt deel van de gewoonte dekt — besluiten om de browser te openen om iets op te zoeken of een gesynchroniseerd tabblad voort te zetten. Het is eerlijk om te zeggen dat hij minder doet voor links die Chrome vanuit een andere app openen zonder dat het icoon wordt aangetikt; een volledige aanpak van dat gat betekent meestal dat je ook de app aanpakt die de link genereerde. Waar hij wel van toepassing is, onderbreekt de tol de trekkracht van de Discover-feed voordat een leeg tabblad de kans krijgt om niet meer leeg te zijn.
Een realistische dag
Op dit moment: een nieuw tabblad openen om iets op te zoeken wordt onderbroken door de Discover-feed die er al onder geladen staat, en de zoekopdracht gebeurt nooit helemaal omdat er al iets was om in plaats daarvan te scrollen. Met de tol op zijn plek: het rechtstreeks openen van Chrome loopt eerst tegen drie vragen aan. De specifieke zoekopdracht waarvoor je kwam, wordt nog steeds getypt en beantwoord. Wat wordt onderbroken, is de feed-eerst-gewoonte die een leeg tabblad niet langer ontmoedigt — dat kost nu een paar minuten écht nadenken voordat het tabblad zelfs opent, niet nadat de feed al iets anders te lezen heeft aangeboden.