Kommende Chrome halverer RAM-forbrug - siger Google

Illustration: Google Inc
Opdatering af Google Chrome ventes på gaden 6. december. Indtil videre har holdet bag løftet sløret for væsentlige hastighedsforbedringer.

Hvis du er en af de millioner af brugere, der dagligt benytter sig af Google Chrome, så har du måske nok en ide om, hvor langsom din computer bliver, når du åbner browseren.

I takt med, at hjemmesider og online-værktøjer kræver mere og mere af din computer, bliver browseren hurtigt en stor byrde for hastigheden. Det skriver thenexweb.com

Holdet bag Chrome har i lang tid arbejdet på at forbedre browseren, og de er snart klar til at præsentere en opdatering, der vil halvere brugen af hukommelse.

Ved at inkludere en ny JavaScript-motor i Chrome 54 vil hukommelsesforbruget på tunge JavaScript sites være lavere end i de tidligere versioner.

Test viser store forbedringer

Google har testet sider som Imgur, Twitter og Youtube, og her viste det sig, at browseren brugte 50 procent mindre RAM i gennemsnit end tidligere, og det er en væsentlig forbedring.

Hvis din computer allerede har en masse hukommelse, eller du systematisk lukker faneblade for at spare på hukommelsen, vil virkningen af opdateringen være mindre.

Hvis du derimod bruger en mobil enhed med mindre RAM, eller generelt har for mange faneblade åbne, vil der være en mærkbar forbedring af belastningen.

Holdet bag Chrome ser det her som et skridt i den rigtige retning, men de håber på at kunne frigive flere hukommelsesbesparende opdateringer i fremtiden med særligt fokus på low-end-enheder, der har mindre end 1 GB hukommelse.

Opdateringen ventes at blive tilgængelig 6. december, men hvis ikke du kan vente, er der mulighed for at teste en betaversion et par uger før.

Læs også: Google vil køre Javascript hurtigere i Chrome uden at bruge al hukommelsen

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Rune Jensen

Chrome halter bagefter firefox i renderings-hastighed ved avanceret CSS3 mobile media queries.

I hvert fald på Linux...

Givet, at Firefox halter en smule i selve forståelsen af CSS3 ifht. Chrome, men jeg tvivler på, det er dét, som gør forskellen.

Det er fint, at Google gerne vil optimere sin javascript-motor. Meeeen. At firefox kan rendere CSS3 hurtigere, bør indikere, der også er arbejde at gøre her for Google.

  • 0
  • 0
Bjarne Oldrup

Nu har jeg det sidste års tid benyttet chromebooks til mit daglige computer-behov, og jeg er da alligevel lidt overrasket over hvordan de bare bliver en lille smule bedre ved hver opdatering (som man kan holde vejret imens den installeres). Det er ret fedt. Det er ikke ment som endnu et indspark til nogen religionskrig - jeg hiver skam min windows pc frem når jeg skal virtualisere eller klippe film - mener bare, ny version betyder oftere større krav til systemet, fint nogen trækker i den anden retning...

  • 1
  • 0
Rune Jensen

OK, under alle omstændigheder.

Jeg har sat en baggrund med gradients, som kan se ved fuld visning af siden, dvs width>1100px eller så.

Når bredden af vinduet kommer under denne vidde, så fyldes siden ud til hele vinduet, sådan man ikke kan se baggrunden.

Så her er hvad der ser ud til at ske.

Chrome; Lader til at tagne baggrunden først, derefter finde ud af, nåhnej, den er ikke nødvendig her og så fyldes hele vinduet med siden.

Firefox lader til at gå udenom baggrunden, hvor den alligevel ikke kan ses, og tegner straks hele siden som den skal være. Så er det klart, hvis den ikke skal bruge tid på at tegne gadienter først, som alligevel ikke skal bruges, så er den hurtigere til at rendere.

Slutresultatet er i begge tilfælde det samme i designet, men lader til at Google kunne kigge lidt på, hvad der er nødvendigt at tegne for det færdige resultat.

Jeg har iøvrigt sat mine media queries logisk, sådan at testrækkefølgen burde passe. F.eks. sætter jeg som udgangspunkt en ren farve, og sætter kun gradienter ved vidde større end 1100px, for så fylder selve siden ikke vinduet helt ud, og så skal baggrundsgradienterne kunne ses. Så lidt mærkeligt, at Chrome i det hele taget bruger den media query ved vidder mindre end 1100px. Den burde slet ikke være aktiv dér.

Anyways, lidt off topic, men lidt interessant synes jeg, at Google ikke har kig på dette.

  • 0
  • 0
Henrik Madsen

Det der gav den største hastigheds forbedring var for mig, at installere en adblocker.

Det er oftest reklamerne der trækker kræfterne og gør hjemmesiderne langsomme at hente og rendere.

  • 11
  • 1
Henrik Madsen

At lægge reklamerne på egen server løser kun problemet med at siden bliver langsommere til at vises pga. eksternt indhold som kommer fra en langsom server.

Det tager vel reelt set lige lang tid for min PC at skulle rendere alle de reklamer.

Dertil kommer at det heller ikke ændrer på at reklamerne opfører sig ekstremt ADHD/Se mig, se mig, se mig agtigt.

Man KUNNE også lave reklamerne mere simpelt, uden animering, lyd og så videre, det ville både gøre dem mindre og dermed hurtigere at hente, meget mindre irriterende at se på og meget nemmere for min PC at rendere.

Med min løsning tror jeg at der er flere som ville undlade adblockeren.

Det virker på mig som om, at for hver gang antallet af adblock brugere stiger, så gør man bare reklamerne ENDNU mere irriterende og svære at ignorere.

  • 2
  • 0
Mikal Schacht Jensen

Nu er CDN's jo ofte en god ide, netop af performance årsager.
1. Brugeren henter content fra en sted der er geografisk tættere på ham
2. Sandsynligheden for at en .js fil eller lign. allerede er cached er væsentlig større hvis man bruger et CDN der benyttes af andre sites som brugeren besøger.

Sikkerhed et bestemt et issue med CDNs, og man bør derfor have 100% tillid det CDN man benytter. Men at påstå at de ødelægger performance er dårligt råd, et af deres formål er jo netop at forbedre performance (vil dog ikke udelukke at der findes CDNs som har dårligere ydelse end hvis indholdet var hosted sammen med resten af websitet)
Desuden så påvirker svartiden på http requests jo ikke browserens ramforbrug. Hvilket jo er hvad artiklen handler om.

  • 1
  • 0
Sebastian Paaske Tørholm
  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize