Google Chrome voegt prestatiemodi toe om geheugen en accu te sparen

Google rolt twee prestatiemodi uit naar de Google Chrome-browser. Hiermee wordt automatisch geheugen van inactieve tabbladen vrijgemaakt en wordt de accu van een laptop minder belast door achtergrondtaken en visuele effecten te beperken.

De prestatiemodi zijn in te stellen via de instellingen van de browser. Volgens Google moeten deze tot 40 procent minder geheugen gebruiken. Bij de Memory Saver zal een icoon van een snelheidsmeter tonen of een tab actief of inactief is, met daarbij het eventueel bespaarde geheugen.

De Energy Saver-modus beperkt onder meer animaties, smooth scrolling en framerates van video's. Hierdoor moet de accu van een laptop minder snel leeglopen. Het is mogelijk om de modus onder meer automatisch in te schakelen als het accuniveau onder de twintig procent daalt.

De prestatiemodi voor de Chrome-browser werden in december bekendgemaakt door Google en worden de komende tijd uitgerold voor Windows, macOS en ChromeOS. Gebruikers kunnen de functies voor die tijd al activeren via de flags 'chrome://flags/#battery-saver-mode-available' en 'chrome://flags/#high-efficiency-mode-available'.

Beeld: Google

Reacties (91)

[DamirB]

Gebruik het nu een maand ofzo in beta, nadeel is wel dat het niet heel intelligent werkt. YouTube bijv, dropped veel frames tijdens playback en om dat normaal te kunnen kijken op je laptop accu moet je besparing voor heel chrome uitzetten, niet per tab helaas. Voor de rest prima maar het verschil is relatief minimaal op een MacBook

[Patrick22221]

Waarom gebruik je chrome op een macbook ?

[djwice]

Safari ondersteunt bijvoorbeeld nog geen http/3. Dat scheelt 300ms laadtijd per pagina voor elke website die het ondersteunt.

Ook WebMidi wordt niet ondersteund door Safari, dit wordt gebruikt om in browser synthesizers te kunnen bedienen met een 🎹 (in Chrome werkt dat zelfs op je telefoon met je midi apparaat aan de usb), maar ook diverse onderwijs tools en games gebruiken het WebMidi protocol.

Dit zijn maar een paar voorbeelden van features die al flink wat jaren in Chrome en Edge en FireFox zitten die nog niet in Safari zitten.

Maar denk ook bijvoorbeeld aan ondersteuning voor HTTPS DNS records voor nog meer snelheid en veiligheid, welke nog niet ondersteund wordt in Safari.

[Olaf van der Spek]

Dat scheelt 300ms laadtijd per pagina voor elke website die het ondersteunt.

Alleen als de latency naar die website hoog is toch?

[latka]

Minder als de latency lager is, maar http/3 vermijd zowiezo de tcp roundtrip latency voor het opzetten van de verbinding is is dus altijd sneller (over udp dus)

[satya]

En dan hebben we het eigenlijk ook over het QUIC protocol, volgens sommigen nog een security probleem wat in menig firewall uit te schakelen is. Toen ik het weer inschakelde kreeg ik klachten, maar dat kwam omdat het UDP flood protectie te scherp stond afgesteld

[latka]

Ik ben er ook nog niet over uit of ik een fan ben van http/3: het is effectief een herimplementatie van tcp over udp maar dan in de browser. What could go wrong?

[djwice]

Heb je het protocol doorgenomen? Want volgens mij ga je iets te kort door de bocht.

Ben je er bewust van dat het al 10 jaar wordt gebruikt? Onder andere voor het serveren van alle Google advertenties die je met Chrome bekeken hebt.

[Reactie gewijzigd door djwice op 22 juli 2024 22:06]

[latka]

Mijn punt is meer dat quic in de browser zit en niet als onderdeel van het os wat het lastiger maakt om over een serie applicaties flow control goed te doen. Iedere applicatie die quic doet moet dat zelf regelen inclusief de complexiteit van flow control . Als de historie van tcp bekijkt is dat niet heel erg triviaal.

[djwice]

Dat het niet in de OS laag zit is ook al zo met HTTP/2, daarvoor is de kernel van Windows herschreven zodat IIS HTTP/2 kon gaan ondersteunen.

Verschil met HTTP/3 en HTTP/1.1 is dat je nu de data als een stream krijgt, dus niet meer als losse pakketjes. Dat scheelt een hoop in je flow control. En opend de weg naar parallelle verwerking van de data zonder stalling. Je kunt je data daardoor al verwerken terwijl die binnen komt, zelfs al beginnen met response voordat de request volledig binnen is. Bij een goede implementatie scheelt dat veel memory en idle tijd.

En met server push kun je al extra files naar de cliënt sturen die hij straks nodig heeft, nog voordat de cliënt weet dat die nodig gaan zijn.

[Reactie gewijzigd door djwice op 22 juli 2024 22:06]

[GertMenkel]

Ik zie nu dat Windows blijkbaar een kernel mode HTTP server heeft (wat eng!), maar dat heeft verder niet zoveel met browsers en andere software te maken. Microsoft heeft ervoor gekozen om HTTP al in de kernel te doen, dus iedere toevoeging aan het protocol moet dan natuurlijk in de kernel gebeuren.

[djwice]

Dat was zo voor http/1.1 en lager. HTTP/2 en hoger juist niet.

[latka]

En kernel mode printer drivers, en kernel mode display drivers. Effectief zijn ze MS-Dos aan het herimplementeren maar dan met een Win32 API

[latka]

Wot? Hoe bedoel je dat je dat in een stream komt? Een stream van UDP pakketjes bedoel je neem ik aan. En dat scheelt precies niets in flow control. Zowiezo zijn die UDP pakketjes 1500 bytes per stuk (minder, maar 1500 is zo lekker herkenbaar) dus tenzij je hele kleine webpagina's bekijkt zijn het gewoon een heleboel pakketjes. Er zitten alleen geen ACKs op de pakketjes dus als er een uitvalt... dan moet de applicatie dat herstellen (resend etc.). En omdat de server niet weet wat er aangekomen is zonder ACK moet deze toch de data vasthouden in het geval er wel een re-send nodig is. En wat jij beschrijft over parallele verwerking is TCP flow-control met een sliding window: pakketjes verwerken ook als zijn ze nog niet allemaal binnen/ge-ack'ed. Dat kan natuurlijk alleen maar als de pakketjes wel in volgorde aangekomen zijn (als je de 2e helft van een ZIP stream ontvangt kun je niets omdat je dictionary niet compleet is).

Server push staat hier redelijk los van. Dat kon al met IE5/pushlets en wat JS.

[djwice]

Vanaf HTTP/2 kan een cliënt in een request meerdere verzoeken doen. En een server in een response meerdere verzoeken retourneren.
Ook kan worden uitgewisseld welke files de server denkt dat je nodig hebt via de link header. Waarop de cliënt haar cache kan valideren en met een verzoek de juiste files kan opvragen.
Zo kunnen bijvoorbeeld de juiste CSS en JS bestanden opgevraagd worden voordat de HTML geparced is.

[Reactie gewijzigd door djwice op 22 juli 2024 22:06]

[latka]

Ah, pipelining, Dat zit ook in HTTP/1.1 en verbeterd in http/2. Maar even terug naar de kern: TCP flow control in user-mode applicaties (browsers) is minder goed dan in de kernel omdat het dan over _alle_ verbindingen gelijkaardig werkt. De rest van de features in HTTP1.0/1.1/2.0/3.0 whatever vind ik minder interresant dan de fundamentele keuze om UDP te gaan gebruiken en flow-control er even bij te doen. We klagen enerzijds dat browsers logge grote dingen geworden zijn, maar accepteren dan wel dan een deel van het OS geherimplementeerd wordt in de browser. We zijn bijna zover dat we Chrome alleen nog maar naar MS-Dos hoeven te porten en met een Vesa driver de video aansturen.

[djwice]

Nee, dat is anders. Pipelining is connectie hergebruik. Dit is een verzoek (past in een pakketje) dat meerdere files in een keer opvraagt.

[latka]

"HTTP pipelining is a feature of HTTP/1.1 which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses" : dus meerdere verzoeken staan uit/open. Ik snap niet helemaal wat je bedoelt met 'meerdere files in een keer opvragen'?
Zo van GET /some/file en dan 2x een HTTP 200 status code met content ontvangen?

[The Zep Man]

Ben je er bewust van dat het al 10 jaar wordt gebruikt? Onder andere voor het serveren van alle Google advertenties die je met Chrome bekeken hebt.

Ik ben niet @latka, maar ga toch antwoorden.

Ik gebruik geen Chrome, en ik zie geen Google advertenties. Ergo, QUIC gebruik ik nog niet zo lang.

Verder is QUIC natuurlijk niet enkel bestemd voor browsers. Zo kan Syncthing het bijvoorbeeld ook gebruiken voor bestandssynchronisatie tussen nodes.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 22:06]

[djwice]

Jep en voor DNS-over-QUIC waarmee een encrypted DNS query even snel is als een unencrypted query.

[Reactie gewijzigd door djwice op 22 juli 2024 22:06]

[latka]

Nee, trager: je moet encrypten/decrypten. Ik heb daarvoor een lokale resolver wat nog sneller is want het meeste verkeer gaat het netwerk niet eens uit.

[djwice]

Nee, niet. Want het protocol is compacter en sneller dan http/1.1.

[latka]

We hadden het over DNS-over-QUIC toch? DNS loopt normaal unencrypted via UDP over poort 53. In het artikel zetten ze DNS-over-QUIC uit tegen DNS over TLS/HTTP. Dat moet je idd. niet willen. DNS over UDP (het 'oude' DNS) is sneller dan DNS-over-QUIC, maar daar vergelijkt men het niet eens mee.

[djwice]

Zie daarvoor dit onderzoek:
http://essay.utwente.nl/89441/1/Batenburg_BA_eemcs.pdf

[latka]

Yup: daarin staat DNS over UDP zonder encryptie is sneller behalve soms en we weten niet waarom en de resultaten zitten zo dicht op elkaar dat je je af moet vragen of je niet in de foutmarge zit te meten. Dus staat er effectief niets. Logisch is het ook niet: je doet DNS over UDP (een binair superefficient protocol) en DNS over DoQ wat effectief DNS verkeer is maar dan encrypted (= meer werk). Het zou raar zijn als het sneller is (maar daar stapt het paper overheen omdat alle ogen gericht zijn op de efficientie t.o.v. DNS over TLS wat niet bijster efficient is).

[djwice]

Comparing DNS over QUIC to DNS over UDP we see in Table 1 and Figure 3 that locally DNS over UDP is quicker, but when the testing goes over the Internet DoQ becomes quicker. This is surprising as both protocols run over UDP so should behave similarly. DNS over QUIC also requires a connection to be set up and maintained where as DNS over UDP doesn’t use connections.
The effect of this setup time can be seen clearly in Table 2 where in the EU, US and AU scenarios that use the Internet the variance of DoQ is clearly higher than that of DNS over UDP.
As to the reason that DoQ is still faster on the Internet than DNS while requiring that setup, we can sadly only theorize. That theory is that because DNS over QUIC keeps the connections open where as DNS over UDP has no connections network equipment handles DoQ differently from DNS over UDP.
The way that firewalls work is that new connections have to be processed in CPU, where as the established connections are hardware offloaded. This causes the packets for DNS over UDP to have to take the CPU processed route which can be slower. Especially when the firewall is handling a lot of packets like it would in a cloud system like Azure. While the continuous connection of DoQ is already established, and can thus be handled by the faster hardware path.
This theory is also supported by the result of the local set up where there is no network in between the 2 machines that have this effect.

Dus DNS over QUIC marginaal sneller of even snel als DNS over UTP, ondanks dat je encryptie toevoegd.

[Reactie gewijzigd door djwice op 22 juli 2024 22:06]

[latka]

Ik ben wel Latka en ik gebruik Firefox ;-) Geen Quic hier (maar wel een pihole en wat andere blockers). Dus ik weet niet helemaal wat reclame is. Voor filesync doe ik, lekker eigenwijs, nog WebDAV over HTTP/1.1 zodat ik het lekker via een reverse proxy kan laten lopen.

[supersnathan94]

Ah. Goeie reden dus om het in de firewall al te blokkeren .

[deadinspace]

Minder als de latency lager is, maar http/3 vermijd zowiezo de tcp roundtrip latency voor het opzetten van de verbinding is is dus altijd sneller (over udp dus)

RTT van hier naar tweakers.net is 5ms, TCP handshake vermijden scheelt... 5ms. In de meeste situaties is dat niet echt een heel overtuigend argument.

[keejoz]

Dat webmidi niet ondersteund wordt lijkt me eerder aan de ontwikkelaars van die library te liggen... vdo.ninja kan dit bijvoorbeeld wel, al blijft Chrome de aangeraden browser.

[Christoxz]

Note that, in 2020, Apple has announced that they would not natively support the Web MIDI API (and a host of other APIs) in Safari because of fingerprinting concerns.

Nee, de browser moet het ook ondersteunen.

[oscar oscar]

http3 ondersteuning is beging 2020 toegevoegd in Safari, en kan je eenvoudig via developer menu activeren...
De reden dat het standaard niet aan staat is waarschijnlijk omdat het nog geen standaard is maar nog in draft.

WebMidi kan je trouwens via extensies activeren in Safari en andere browsers die het nog niet standaard ondersteunen.

[djwice]

HTTP/3 is afgelopen zomer na 10 jaar geen draft meer: https://datatracker.ietf.org/doc/html/rfc9114

Net als HTTP/3 is WebMidi een W3C standaard: https://www.w3.org/TR/webmidi/

Er zijn niet veel browsers die WebMidi niet ondersteunen: https://caniuse.com/?search=WebMidi

[Reactie gewijzigd door djwice op 22 juli 2024 22:06]

[GertMenkel]

"Alle browsers behalve Safari en Firefox for Android" is toch wel het merendeel van het web. Ik heb er zelf geen nut voor, maar als zelfs Firefox het heeft dan zou ik het gewoon gebruiken. De sporadische Safari/Firefox for Android-gebruiker kan wel een browser pakken die het protocol wel ondersteunt als het voor de kern van je website nodig is.

[Patrick22221]

Aah dankjewel voor de fijne uitleg!

[Keypunchie]

Hoewel ik zelf Chrome zou afraden (het is in principe spyware, maar dan van Google), moet iemand dat op zich zelf toch weten.

Helemaal als je in het ecosysteem zit van Google en je allerlei zaken hebt gesynchroniseerd is het een legitiem gebruik.

Persoonlijk gebruik ik hoofdzakelijk Firefox, soms Safari en soms Vivaldi ipv. Chrome.)

[DamirB]

Als je beetje je best doet kan je dmv extensies het toch redelijk privacy vriendelijk maken.

[The Zep Man]

Gezien Google een handje heeft van extensies handicappen, zou ik daar niet op vertrouwen.

[Fluttershy]

Met een goede firewall en de juiste instellingen kan je ook een spotgoedkope en naamloze webcam van AliExpress veilig maken.

Maar daarom is het nog geen goed product.

[deighton]

Hoeveel redenen heb je nodig?

https://caniuse.com/ciu/comparison

[Mr.Veng]

Dit, absoluut dit - zowel Safari als Firefox lopen achter als het aankomt op ondersteuning van webstandaarden. In Safari merk je geregeld de "koppigheid" van het overkoepelend bedrijf om bepaalde standaarden niet (volledig) te ondersteunen en in Firefox werkt bijvoorbeeld een nieuwere CSS selector zoals :has() nog niet out-of-the-box; enkel als de gebruiker ze activeert via een flag in de configuratie.

Voor een frontend developer zijn Chrome / Chromium / Edge echt veel aangenamer op het vlak van webstandaarden. Je zal ook veel sneller tegen visuele bugs aanlopen bij gebruik van Safari, het is zeg maar "de nieuwe IE (Internet Explorer)" onder de browsers.

[Reactie gewijzigd door Mr.Veng op 22 juli 2024 22:06]

[Meiklokje]

Firefox of Opera is toch wel een betere keuze hoor. En daar ducktogo als search engine. Ik zou echt niets anders willen. Opera heeft een ingebouwde vpn en is helemaal gratis zolang je de pro versie niet nodig hebt. Beiden browsers zijn cross platform en je kan je favorieten over syncen met alles in huis. Je mac meer als een linux computer, als safari voor jou niet voldoende is. Probeer eens open source.

[DamirB]

Voornaamelijk omdat dat wat beter samenwerkt met m'n Android dan Safari doet. En de extensies

[noes]

Je bedoelt; waarom gebruik je geen safari?

Omdat safari kansloos achterloopt in web technieken. Het is de nieuwe Internet Explorer.

[Oon]

Waarom niet? Safari is niet te gebruiken als je een echte browser gewend bent

[skaars]

Mijn eerste vraag zou zijn: Waarom niet? Safari is een ondergeschikte browser op meerdere fronten. Mijn tweede vraag zou zijn: waarom geen Firefox developer edition?

[Janusch]

Bepaalde extensies die Chrome heeft.

Dezelfde instellingen op zowel je Macbook hebben als op je windows PC, als ik daar een dag op werk. Want die ondersteunt wel 2 beeldschermen in tegenstelling tot mijn 8 jaar nieuwere Macbook Air M1

[dipje2]

Iedereen gebruikt chrome op een Macbook?

Waar edge altijd het verweit kreeg 'alleen gebruikt om chrome te downloaden ' is precies hetzelfde (nog niet erger) voor Safari

[Geekomatic]

Een effectievere manier om energie en geheugen te besparen
is om je favorieten goed op orde te houden en snel toegangkelijk op de Favorites Bar
en alle tabs te sluiten bij het sluiten van je browser.
.
Terwijl ik dit typ heb ik 1 tab open in Edge (Chromium),
en die app gebruikt 322 MB geheugen (!).
En veel sites doen tegenwoording aan processing op de achtergrond.
.
Edit: Chrome doet het wel beter met 218 MB voor deze ene tab, zie ik nu.

[Reactie gewijzigd door Geekomatic op 22 juli 2024 22:06]

[sfranken]

Heh, dan gebruikt jouw Edge met 1 tab net zoveel hier nu als mijn Firefox met 8 tabs (waarvan 1 YouTube). Firefox hier op Fedora gebruikt nu (op het moment van schrijven) ~311 MB geheugen.

[m_snel]

Ik sluit alles af wat ik niet gebruik, dus ook FF.

[sfranken]

Ik ook. De 8 tabs zijn dus ook in gebruik.

[GertMenkel]

Tip: check chrome://serviceworker-internals/ en zet de serviceworkers van sites die je niet nodig hebt uit. Er zit wel wat logica in de scheduling van die serviceworkers maar ik merk in Firefox in elk geval dat de browser net wat beter presteert als je die onzin opschoont.

Als je nooit notificaties of andere achtergrondverwerking gebruikt, kun je overwegen om serviceworkers in het algemeen uit te zetten, alhoewel ik niet zou weten of het in Chrome/Edge/Safari mogelijk is.

Je kunt ook kijken waar al dat RAM naartoe gaat als je met rechts klikt op de titelbalk en kiest voor "taakbeheer", dan laat Chrome per tabje zien hoeveel bronnen er nou precies gebruikt worden. Best handig om addons op te sporen die je browser trager maken.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 22:06]

[Geekomatic]

Poeh, dit is wel erg bewerkelijk en trail and error.
Nog een kleine anekdote, een kennis wilde een nieuwe computer kopen
omdat haar huidge te traag werd, zo zei ze.
Na de uitleg hoe te browsen met een minimaal aantal open tabs,
was een nieuwe computer niet meer nodig.

[Reactie gewijzigd door Geekomatic op 22 juli 2024 22:06]

[Gamebuster]

Ik ben benieuwd hoe dit technisch gezien werkt; wordt de state van een JS app opgeslagen op de SSD? wordt de tab gewoon "gesloten" en opnieuw geladen? Krijgt een JS app notificaties/events van eventuele "hybernate"?

[Henno Keers]

Functionaliteit ontwikkeld door Microsoft, overgedragen aan het Chromium project en nu uitgerold door Google?

[wildhagen]

Ja, waarom niet? Dat is nou net het hele idee van Open Source, iedereen kan bijdragen aan een project. Lijkt me alleen maar positief ook.

[Henno Keers]

Het enige wat mij stoort is dat het in het artikel en in het bericht wordt gebracht als een innovatie van Google.... Not.
Geef dan credits. Doet men wel over en weer bij het vinden en doorgeven van beveiligingslekken.

[Karimpje]

Het betreft de Google Chrome browser en Google rolt het uit. Nergens krijgt Google de credits hiervoor, maar eerlijkheidshalve ook Microsoft niet. En van de andere kant, ik zie Microsoft ook nergens pochen over het feit dat ze gebruik maken van het Google opensource project Chromium. Microfoon doet het vaak voorkomen alsof het hun uitvinding is. Hoe dan ook ik heb er geen last van, beter goed "gejat" dan slecht verzonnen zal ik maar zeggen.

[Red hot]

Zit dit al in Edge?

[Henno Keers]

https://blogs.windows.com...ng-tabs-beta-performance/
https://www.microsoftedgeinsider.com/en-us/whats-new

[Reactie gewijzigd door Henno Keers op 22 juli 2024 22:06]

[dipje2]

Volgens mij al 6+ maanden. Sleeping tabs zie ik tenminste al een eeuwigheid.

[CH4OS]

Je kunt het als feedback aan de redactie geven; forum: Geachte redactie

[Gamebuster]

Mooi he, open source projecten

[Henno Keers]

Ja!

[m_snel]

Werd tijd , een paar tabbladen van Crome vragen al je geheugen op.

[Fox Hound]

Dit komt een beetje over als kunstgrepen om de geheugenhonger en stroomverbruik van Chrome in te dammen. Ik vraag me af waarom Chrome dit nodig heeft terwijl efficiëntie bij een browser als Safari gewoon ingebakken zit.

[Inflatable]

Omdat Safari alleen op Apple hardware draait en Chrome op allerlei verschillende soorten hardware moet kunnen draaien misschien?

[iAR]

Google had ook moeite kunnen doen om gewoon specifieke builds te maken.

[supersnathan94]

Het punt van een Operating system met allerlei APIs is toch juist dat je die abstractielagen hebt waardoor dat helemaal geen zak uitmaakt?

Chrome voor windows zou gewoon net zo efficiënt moeten kunnen zijn als safari voor macOS.

Sure chrome zal iets meer versies moeten ondersteunen (safari was immers gekoppeld aan het OS), maar ook dat is niets in verhouding met het aantal Mogelijke hardware configuraties.

[GertMenkel]

Chrome heeft onder andere meer geheugen nodig vanwege allerlei beveiligingsfeatures. Chrome maakt een heel proces per tab waar andere browsers processen delen als je meer dan vier of vijf tabs open hebt. Dit verbetert onder andere de browser tegen allerlei theoretische aanvallen en maakt het mogelijk om allelei aannames te kunnen doen over waar een proces bij mag, maar zorgt wel dat bepaalde datastructuren/caches/code dubbel wordt ingeladen.

Safari is op macOS wat beter voor de hardware geoptimaliseerd en is ook beter op het OS afgestemd zoals Edge dat ook op Windows is. Het mist daarentegen weg features en defence in depth die Chrome wel kan.

Qua stroomgebruik is de grootste impact die ik gezien heb gewoon de hoeveelheid javascript en video's die websites door je strot proberen te drukken. Chrome's engine is ontzettend snel, waardoor er ook meer code wordt uitgevoerd, waar ik het idee heb dat Safari liever de achtergrond-JS naar een efficiency core duwt dan dat het een performance core op volle turbo gooit.

Wil je serieus stroom besparen in je browser, welke dan ook, zet dan standaard Javascript uit; dat scheelt toch al snel één à anderhalve CPU core aan nutteloze achtergrondscripts in mijn ervaring.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 22:06]

[jabwd]

ook gebruikte technieken maken hier uit. Als chrome VP9 content gaat zitten decoden op de cpu kost dat gewoon veel meer unit aan energie per frame. Beide browsers hebben gewoon andere prio's in die zin. Daarnaast moet apple is opschieten met hardware AV1 decoding support, maar helaas ook nog niet in M2..

[GertMenkel]

Dat klopt, Youtube gebruikt bijvoorbeeld zo veel mogelijk codecs waar ze niet voor hoeven te betalen als ze in zo'n beetje elk apparaat zitten. AV1 in software, iets dat op lagere resoluties door Youtube wordt gebruikt, is nogal zwaar op de CPU.

M1 en nieuwer zou als het goed is wel al VP9 moeten ondersteunen. Chrome maakt daar standaard ook gebruik van voor zover ik weet. AV1 zal nog wel even duren, net als het bij VP9 even heeft geduurd voordat iOS-gebruikers ook normaal filmpjes konden kijken.

[HollowGamer]

Jammer dat er nooit aan Linux wordt gedacht, deze hebben toch ook gewoon API's lijkt me?

Dat is niet perse specifiek voor Chrome, Firefox heeft er ook last van.

Misschien is het ook een goede manier om energie te besparen tijdens dingen als Google Meet, YouTube, etc. Daar gaat de accu heel snel van leeg.

[m_snel]

Er is volgens mij geen browser die zoveel ressources gebruikt als Chrome.

[HollowGamer]

Firefox kan er ook wat van hoor. Maar inderdaad, zeker als je kijkt naar iets als Electron, wat in feite gewoon een Chrome browser proces is (kort door de bocht).

[m_snel]

Ik kom op mijn werk als externe veel virtuele werkplekken tegen die maximaal 8 Gb geheugen hebben, meestal zelfs minder. Elk tabblad van Chrome gebruikt minimaal 300mb en zelfs als je er een open hebt zie meerdere processen met 300mb. En als je dan naar de inhoud kijkt dan is de dat bijzonder veel.

[Vexxon]

Ze kunnen de prestaties misschien ook verbeteren door minder aan tracking te doen

[moonlander]

Dat ligt dan voornamelijk aan de websites die je bezoekt.

[Vexxon]

Want Google Chrome harkt geen data van je bijelkaar en tracked niet denk je?

[moonlander]

https://www.google.com/intl/nl/chrome/privacy/
Valt allemaal reuze mee dus, het is maar net hoe je het hebt ingesteld. Maar dat is in elke browser zo.

Ben je ingelogd met een google account in je browser of niet? Gebruik je google services of niet?

[Vexxon]

Laat ik het zo zeggen, als je privacy belangrijk vindt moet je ver weg blijven van Google. Je gaat Chrome nooit zo in kunnen stellen dat het helemaal niks van je binnenhaalt of jou tracked. Als je dat wel gelooft is dat vrij naïef

[Oon]

Dat valt heel erg tegen. Het beetje data dat Google zelf verzamelt heeft weinig impact op je performance, want Chromium (open source zonder Google integraties) is even snel/langzaam.

Daarnaast zijn andere browsers ook niet sneller, er zijn er veel die zelfs langzamer zijn.

[Frame164]

Dus iets wat Safari (en wellicht andere browsers ook) al jaren heeft.

[Annihlator]

Ik zie het ook vooral als een poging om meer/beter te competeren met Opera/Opera GX, ook chromium-based, maar beiden bieden al vergelijkaardige opties (en bij GX wordt dat middels interfaces zelfs aardig gebruiksvriendelijk getoond)

Ik was zelf inmiddels ook over, vooral vanwege chromes, al jaren, beruchte eindeloze geheugenhonger

[Roel1966]

Ik gebruik eigenlijk zelden tot nooit meer dan 2 a 3 tabs tegelijkertijd binnen zowel Edge als Google Chrome omdat ik anders de draad kwijt raak van wat open staat. Mijn vast pagina's heb ik als bookmarks staan en ik eerlijk gezegd weinig tot geen verschil merk met openen. Dus verschil wanneer ik de tab open laat staan met de pagina of dat ik even op de bookmark klik.

En ja verder kan je processing op de achtergrond bij het sluiten van de browser volgens mij bij beiden, Edge als Chrome uitschakelen. Ook dat scheelt best wel een boel en ik ook het nut er niet van inzie dat een browser in afgesloten toestand nog dingen doet. Soms heb ik dan ook wel zoiets dat al dat z.n. versnellen alleen maar nadelig is en echt niet zo versnellend werkt als men denkt.

[Ralph84]

Ik ben sinds een maand of twee overgegaan naar Edge, wauw wat heeft dat zoveel meer handigere features dan Chrome