Google wil dit jaar offline-modus en mobiele prestaties Blink-engine verbeteren

Google wil in 2014 de mobiele prestaties van zijn browserrenderengine Blink flink gaan verbeteren. Ook moet zowel het energie- als het geheugengebruik omlaag. Daarnaast krijgen webapps meer mogelijkheden en wordt de offline-modus verbeterd.

In een post op Google Groups heeft Chrome-ontwikkelaar Eric Seidel onthuld wat de zoekgigant in 2014 met Blink voor ogen heeft. Omdat het browsen en het gebruik van webapplicaties steeds meer via mobiele apparaten gaat, wil het ontwikkelteam Blink daar op aanpassen. De belangrijkste aandachtspunten zijn volgens de ontwikkelaars dat er geen haperingen merkbaar zijn bij animaties en scrollen. Ook moeten de laadtijden omlaag en hebben de ontwikkelaars zich als doel gesteld dat Blink als beste scoort in belangrijke mobiele webbenchmarks.

Ondanks de beoogde prestatieverbeteringen zal Blink in de toekomst minder geheugen nodig moeten hebben en ook het energieverbuik moet omlaag. Dit was ook een doel bij de ontwikkeling van Android 4.4 en hierdoor kan de software ook goed presteren op minder krachtige Android-toestellen.

Het nieuwe jaar zal ook verbeteringen en meer mogelijkheden meebrengen voor webontwikkelaars. Ten eerste komen er nieuwe tools om ontwikkelaars te helpen bij het maken van webapps en webpagina's. Daarnaast komen er meer mogelijkheden voor webapplicaties, zo moeten webapps push-notificaties kunnen ondersteunen en kunnen ontwikkelaars hun apps aanpassen aan bepaalde eigenschappen van het apparaat zoals de schermgrootte.

De ontwikkelaars willen de offline-modus voor webapps ook sterk verbeteren, al geeft Seidel nog geen indicatie wat er precies gaat veranderen. Het verbeteren van de offline-modus en webapps mogelijkheden geven die normaal alleen aan normale apps toebehoren, zou ervoor moeten zorgen dat ontwikkelaars hun webapps meer gaan richten op de Chrome-browser en Chrome OS.

Google besloot vorig jaar om Webkit te forken en verder te gaan met Blink. Het werd volgens Google steeds moeilijker snel te innoveren omdat zowel Webkit als Chromium, het opensource-project waar de Chrome-browser en Chrome OS onder vallen, steeds complexer werden. De ontwikkelaars van Google hebben de code van Blink naar eigen zeggen al flink kunnen opschonen en de complexiteit verminderd, het komende jaar zal dit proces worden voortgezet.

Reacties (47)

[creator1988]

De offline verbeteringen zullen waarschijnlijk bestaan uit het implementeren van Service Workers (https://github.com/slightlyoff/ServiceWorker/). Mozilla is ook al bezig met implementatie.

Verder zijn het verbeteren van animaties ook voor Mozilla een prio, we hebben nu betere hints voor wanneer een element zal worden geanimeerd (zie https://groups.google.com.../wI-jbAwucFA/T1EKv-0XgpwJ). Ik vermoed dat Google iets soortgelijks zal gaan doen.

Push notifications kunnen al in Gecko, dus ik hoop dat Google de SimplePush API ook zal gebruiken, i.p.v. met iets nieuws te komen.

Deze week land overigens de vibration API in Chrome for Android stable, dus Google is al bezig met een begin qua ondersteunen van nieuwe device-specific APIs, in navolging van Mozilla.

[_Thanatos_]

Notifications zitten al heel lang in Chrome, en al enige tijd zonder prefix. En Het werkt in zowel Gecko als WebKit/Blink gewoon met de standaard. Geen reden om met iets nieuws als SimplePush te komen dus, wel dan?

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 18:05]

[creator1988]

Notifications en Push notifications zijn iets heel anders.

[Verwijderd]

Betekent dat dat alle webkit css properties nu -blink- voor de naam krijgen?

[jorikdelaporik]

nee, experimentele opties zijn vanaf nu aan te zetten in about:flags. gelukkig.

[_Thanatos_]

Ik hoop van harte dat er geen lieden ten tonele komen die denken dat dit nodig is nu WebKit door Google omgedoopt is tot Blink. Net als de -khtml-, -ms-, en -o- prefixen zijn veel daarvan complete bullshit, en in geen enkele versie van de respectievelijke engines doen ze iets*.

* JA ik weet dat er ook properties zijn waar deze prefixen wél nut hebben, maar daar heb ik het hier dus niet over!

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 18:05]

[HMC]

Altijd mooi dat gepraat hoe 4.4 en nu apps beter draaien op minder sterke hardware, maar, ten eerste zijn nieuwere smartphones per definitie sterker qua prestaties, en ten tweede, de oudere modellen met oudere, minder sterke hardware krijgen geen updates naar 4.4

[Zae]

Je kan zelf je telefoon updaten naar kitkat via een van de onofficiele roms, ik draai ook 4.4 op mijn nexus S, en het werkt bijzonder goed voor zo'n oude telefoon.

[HMC]

Helaas zit dat er voor MT6589 (jiayu G4) nog niet in voorlopig.
Dat deed ik idd op mijn oude LG Optimus One ook.

Ik bedoel slechts dat ze iets uitbrengen voor zwakkere (dus, lijkt mij, vaak oudere) phones goed zou zijn, maar de update komt niet uit voor die phones.
Was met dat Project Butter (of zo) ook. Zelfde verhaal. Past op 500MB phones.
Maar dat waren toch echt de oudere, en die kregen via fabrikanten allang geen udates meer. Inderdaad alleen via Cm zelf te doen.

[GigaPixels]

Dat wilt toch niet zeggen dat mensen met een smartphone die <Android 4.4.2 draait, niet gebaat zijn bij een snellere browser die minder energie verbruikt en minder RAM nodig heeft?
Idem voor natuurlijk laptops bijvoorbeeld, die eveneens op een accu werken een vaak beperkter aantal RAM hebben tov desktops.

[Iblies]

Het is maar de vraag in hoeverre een correlatie is tussen snellere browser en oudere hardware.
Wat je wel ziet is dat een browser steeds meer gebruikt maakt van de gpu-gedeelte. Dat zie je terug op de desktop. Ipv laten afwerken door CPU assisteert de gpu steeds vaker en/of neemt taken over. Als dat ook de bedoeling is, is het even afwachten hoe het zal uitwerken. Een telefoon met een waardeloze gpu zal dan nog steeds niet vooruit te branden zijn.

[KoalaBear84]

Het batterijverbruik is sinds Android 4.4 en de nieuwste versie van Google Play Services anders behoorlijk verbeterd, ook dat is erg belangrijk, ook bij nieuwe telefoons.

Maar je gedachte is compleet duidelijk.

[Superkanjo]

Er kunnen toch nieuwe "budget" toestellen uitgebracht worden die wel 4.4 draaien? Dus niet per definitie sterker qua prestaties. En als een model met "mindere" hardware er profijt van heeft dan heeft een "high end" model hier ook voordeel aan.

[vide]

Minder geheugengebruik lijkt me zeker positief, veel nieuwe android toestellen (uiteraard in het goedkopere segment) hebben nog steeds maar 1GiB RAM.

[johan13v]

Maar op welke manier is het geheugengebruik van Chrome de bottleneck voor de prestaties van een telefoon? Ik heb een Oppo R819 met 1GB Ram, maar ik heb nog nooit meegemaakt dat deze meer van 300mb nodig had.

En op mijn mac trekt Chrome op het moment 191mb met 16 tabs open. Het geheugengebruik van Chrome is dan misschien niet efficient, maar dat ga je toch niet heel erg in de prestaties van een telefoon merken? Behalve misschien in het energieverbruik?

[Reactie gewijzigd door johan13v op 22 juli 2024 18:05]

[cornedor]

Minder garbage collection etc als het geheugen efficienter wordt gebruikt. Dat zou 1 van de voordelen kunnen zijn.

[halofreak1990]

Ja, maar met wat jij zegt, leg je het probleem bij de developer van de app; het is immers de developer die de grote hoeveelheid garbage creëert door sloppy coding.

Niet dat ik dit erg vindt, want ik ben van mening dat bugs in programma's moeten worden opgelost door de maker van het programma, en niet door de, in dit geval, browsermaker.

[batjes]

Probleem is dat andere browser bouwers het wel doen voor de brakke app developers. En dan kan Google niet achterblijven.

[halofreak1990]

En daar ligt het probleem; geen enkele browser bouwer of bijv. OS developer moet de problemen van de daarvoor geschreven software gaan oplossen. Dat brengt alleen maar meer problemen mee doordat developers die bugs dan gaan zien als normaal gedrag.

[batjes]

Standaard bij Operating Systems al sinds begin der computer-tijden.

En gezien browsers nu een heel deel van de OS taken zitten over te nemen. Komt dit ook onder de browser taken te vallen. Je gaat nooit alle developers zo ver krijgen fatsoenlijk richtlijnen te volgen, enige manier is het enigszins forceren zoals Apple en MS nu doen, maar dit werkt ook maar half (gezien de hoeveelheid brakke kut apps in beide stores).

OS/Browser bouwers moeten hier wel bij in schieten, want anders gaat het nooit goedkomen.

1 van de redenen dat Firefox toen zo populair is geworden, is omdat het enorm veel developer fouten wegwerkte, negeerde of verbeterde.

[Enai]

Microsoft heeft zo ooit eens een lijn in het zand getrokken en de softwareleveranciers laten weten dat het hun taak was om hun software regelconform te maken.

Om de veiligheid te verbeteren, voerde Microsoft de maatregel in dat gebruikers in Vista slechts over beperkte rechten beschikken tenzij ze admincredentials kunnen voorleggen. Microsoft had al jaren gecommuniceerd dat software die geen goede reden had om adminrechten te eisen dit ook niet mocht doen, maar niemand trok zich hier iets van aan want wie was er nu geen admin in XP?

Resultaat: het regende UAC-popups.

Wie kreeg de schuld? Microsoft, natuurlijk..

[halofreak1990]

Hetzelfde verhaaltje was met Vista en de zogenaamde brakke drivers van, jawel, Microsoft, terwijl juist de hardware fabrikanten verantwoordelijk waren voor die rotzooi.

Ik durf te wedden dat minstens een kwart van de kwetsbaarheden in Windows zit in de backwards compatibility en het via de API patchen van developer fouten.

[kamerplant]

Web apps kunnen wel behoorlijk wat geheugen gebruiken.

[_Thanatos_]

CSS3 transitions die niet eens heel spannend zijn*, lopen houterig om mijn gloednieuwe Nexus 5. Het mocht dus fucking tijd worden dat daar iets aan gedaan wordt.

* Geen paniek, ik weet waar ik over praat

[creator1988]

Worden die transities wel op de videokaart afgespeeld (translate-z: 0 zetten voor de hint)?

[_Thanatos_]

Geen idee. Het boeit me niet wat voor de rendering zorgt, en het is ook niet aan mij om de browser te instrueren welk stuk hardware hij daarvoor moet gebruiken. Dat bepaalt ie zelf maar.

Als translate-z:0 daarvoor nodig is, dan is dat een hack die niet nodig hoort te zijn, dus misschien moet dat dan opgelost worden. Ik doe die hack dan ook *nooit*. Als een browser traag is, dan is-ie traag. En er is een reden dat de browser ervoor kiest een rendering op de CPU te doen ipv op de GPU - dat kan luiheid van de developers zijn, of te weinig vertrouwen in GPU-rendering, of simpelweg een bug. Either way niet iets waar de webdeveloper zich druk om moet maken.

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 18:05]

[creator1988]

Sorry hoor, maar dit is hetzelfde als bitchen op native code omdat je animatie die je in CPU code schrijft niet vloeiend genoeg is. Ook daar zal je moeten gaan specificeren waar wat moet gebeuren. Je kan als browsermaker niet op elk moment weten wanneer je een animatie kan offloaden. Alles afhandelen op de GPU heeft namelijk ook nadelen, waaronder de overhead die je hebt om textures naar de GPU te pushen. Als je dat vaak moet doen is het verstandiger om de animatie op de CPU te doen.

Als je meer in depth wil weten, kijk eens naar de presentatie Fluid User Interface with hardware acceleration van Ariya Hidayat (slidedeck hier als je geen tijd hebt).

[_Thanatos_]

Een website is te high-level om je druk te mogen om zoiets low-level als op welk stuk hardware iets gerenderd wordt. Het zal me echt een enorme kontworst wezen wie een pixel rendert, het is de taak van de browser om te bepalen hoe dat het beste kan gebeuren.

Strak dan heb ik zo'n hack erin zitten, en dan hebben ze browsermakers door hoe ze het goed moeten doen. En dan werkt die hack misschien wel averechts, dat translate-z:0 juist voor CPU-rendering zorgt ofzo. Nee dankje.

Ik zorg heus wel dat m'n site goed in elkaar zit. Ik zorg er echt wel voor dat het optimaal kán zijn. Maar ik ga niet de browser voorkauwen hoe ie z'n werk moet doen.

[pieterdebie]

Ik volg _Thanatos_. Een webdev moet geen css hacks gaan uitvoeren (utopie, ik weet het) om een browser te hinten dat hij iets hardwarematig moet gaan uitvoeren.

Web developpers zijn geen game developpers^* die in C++ alles zodanig schrijven dat een objectje een halve kB minder geheugen inneemt of dat een stukje code regel 13541 in DirectX overslaat.

Begrijp mij niet verkeerd, een webdev moet zeker wel optimalisaties doen, maar dat noem ik dan ook geen hacks.

^* Dit is zeker niet denigrerend bedoelt

[Verwijderd]

Ik weet niet hoor, maar de webdeveloper moet zich er juist WEL druk mee bezig houden. Dat is namelijk hetzelfde als je een App schrijft voor een mobiel.

Zoals niet teveel DOM manipulaties doen. Dit maakt een website ook trager o.a. Als webdeveloper ben je echt wel verantwoordelijk voor de snelheid en soepelheid van jou website.

Moet je trouwens eens met je Nexus 5 naar deze website gaan:
http://mrdoob.github.io/t.../css3d_periodictable.html

Werkt bij mij op de Nexus 4 heel smooth. Dan moet het bij jou ook zeker smooth werken.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:05]

[_Thanatos_]

Niet echt een real-world website... En tuurlijk, als je het helemaal uitoptimaliseert, kun je een heel eind komen, maar de browser moet zelf kunnen inzien wat de snelste/beste manier is om een taak uit te voeren.

[WoutervOorschot]

Koop een Windows Phone of een iPhone!

Maar serieus, de renderengine van IE10/11 of die van safari mobile zijn gewoon heel erg goed.

[Verwijderd]

Met welke mobieltjes heb je dat precies getest en met welke websites naast elkaar? Waar zijn je onderzoeksresultaten? Of zeg je dit alleen omdat je fan bent van Windows Phone.

Trouwens, de iPhone gebruikt ook Webkit net als Chrome.... even dat je het weet hoor.

[WoutervOorschot]

Idd, maar vooral de renderengine van WP(ie10 mobile) schijnt heel snel te zijn.

[_Thanatos_]

Maar om daarvoor nou alle conventies van usability in de wind te slaan? Nee dankje. Als IE11 voor Android uitkomt, zal ik het overwegen. maar ik betwijfel het (hoewel er wel degelijk een ARM-build van moet bestaan... maar dat is nog maar de helft van het werk)

Maargoed, Chrome is gewoon heel snel. Alleen is het een soort allrounder. Andere browsers, zoals IE10/11 doen zich gewoon heel snel voor door bijvoorbeeld alles wat visueel is, voorrang te geven. Chrome doet dat minder, en is daarom met andere dingen weer de winnaar.

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 18:05]

[Verwijderd]

Het is indrukwekkend hoe hard Google aan het web timmert, maar helaas komt veel alleen terecht in Chrome/Blink. Het hele idee bij web development is dat features breed beschikbaar moeten zijn.

[batjes]

Ze zouden van blink iets anders moeten maken dan het eeuwen oude archiatische document-viewer browser. Ga over op een (soortgelijke) manier zoals MS met IE gedaan heeft.... Anders gaan ze achter de feiten aan blijven lopen.

[mae-t.net]

Hadden de Archiaten dan al document-viewers? Misschien bedoelde je "de archaische", wat ongeveer hetzelfde betekent als "de eeuwenoude", maar dan met de bijsmaak van "sterk verouderde".

Voor zover mij bekend, is blink helemaal geen browser maar alleen een rendering-engine. Daar kan je dus alles omheen bouwen wat je maar wilt.

@hieronder: je bent denk ik bezig dynamische rendering van de layout (zoals bijvoorbeeld in Presto en tegenwoordig vast ook wel in MS Trident - voorheen juist niet) en (java)script stevig door de war te halen. Een layout engine hoeft niets met (java)script te doen, althans in principe. Hij moet natuurlijk wel samenwerken met eventueel aanwezige script-engines die ongeveer doen wat jij beschrijft, ongeacht de fabrikant van de scripttaal. Zonder HTML en CSS om de layout te kunnen renderen, is het gemiddelde script bovendien waardeloos.

[Reactie gewijzigd door mae-t.net op 22 juli 2024 18:05]

[_Thanatos_]

Dat doet V8 (de javascript engine van Blink) ook.

Maar of javascript nou uiteindelijk als machinetaal wordt uitgevoerd of dat het door een interpreter wordt gehaald, maakt alleen een verschil in performance. Het maakt een layout engine niet een fundamenteel ander beestje. Ook de Trident 7 engine (van IE11) is gewoon een HTML viewert.

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 18:05]

[Godgeneral16]

serieus? beetje rare post. dit deed je ookal bij het bericht over Call of Duty Ghosts.

Maar even ontopic:

Beter dat er minder ram verbruik is
Als je kijk naar het RAM verbruik vandaag de dag wordt je soms niet goed. er gaan soms gigabytes RAM naar iets wat niet eens zo zwaar zou hoeven draaien.

[Reactie gewijzigd door Godgeneral16 op 22 juli 2024 18:05]

[David Mulder]

Ach ja, de kunst is op zich niet eens zo weinig mogelijk geheugen te gebruiken, maar het beschikbare geheugen zo efficiënt mogelijk te gebruiken. Niks mis met 100% geheugen gebruik zodra je browser minder gaat gebruiken zodra een ander programma geheugen nodig heeft (dat is ook het mooie van je browser als "OS" want geheugen gebruik word best mooi gereguleerd tussen "apps"(=websites) ).

Hoe dan ook, het zal wel niet gebeuren, maar het mooiste zou zijn als ze dezelfde API's zouden implementeren als mozilla heeft ontworpen die HTML5 apps toegang geven tot device specifieke functies (van contacten tot settings to vibrate) genaamd webAPIs. Op FirefoxOS moet je wel een webapp eerst "installeren" voordat hij die dingen kan aanspreken (komt neer op toestemming geven I guess), maar dat zou ook echt super ideaal zijn als dat op android ook komt . Maja, probleem is, er is niet echt veel reden momenteel voor android om zich te houden aan 1 of andere standaard... als ze willen kunnen ze zonder problemen hun eigen standaard definiëren, maar er blijft een kans bestaan... het is google waar we het over hebben (veel vrijheden bij ontwikkelaars)

[Reactie gewijzigd door David Mulder op 22 juli 2024 18:05]

[jarrin]

Nouja, volgens mij heeft ook Android steeds meer focus op webapps zodat de code op meerdere apparaten (OS's) werkt.
Dus Google zal zich zelf behoorlijk in de voet schieten als ze die standaarden niet volgen, want dan moet er alsnog aparte code voor Android geschreven worden. (Nee, dit zal je niet helemaal kunnen voorkomen).

[Verwijderd]

Niks mis met 100% geheugen gebruik zodra je browser minder gaat gebruiken zodra een ander programma geheugen nodig heeft

Roep ik al jaren. Maar daar moet je OS dan wel een API voor hebben natuurlijk.

[mae-t.net]

Ik mag hopen dat het RAM-verbruik 0 is, anders blijf je naar de winkel lopen voor nieuw geheugen... Waarschijnlijk hebben ze het RAM-gebruik sterk kunnen terugdringen, en dat is altijd handig. Ik hoop dat dit voor de desktop-browsers ook gevolgen heeft; ik heb nogal de neiging om veel tabs open te hebben staan. Opera 12 (Presto) kan daar prima mee overweg, maar ik heb de indruk dat andere browsers sneller uit hun geheugen lopen.