Vlákno názorů k článku
Firefox 57 zpožďuje načítání analytických skriptů
od PajaC - Hmm, místo optimalizace jejich JSE (IonMonkey?) nebo nahrazení...
-
PajaC (neregistrovaný)
Hmm, místo optimalizace jejich JSE (IonMonkey?) nebo nahrazení podstatně efektivnějším V8 (licence?) se ustupuje k takovým workaroundům.
Zajímavé že přes všechny proklamace a oslavné (PR?) články je Firefox 57 na mnoha stránkách s rozsáhlejším javascript kódem a/nebo obsahem (kvanta CSS a textu, velké obrázky) výrazně pomalejší a řadově víc zatěžuje procesory
-
Filip JirsákStříbrný podporovatelNejde přece o provádění skriptů, ale o jejich načítání. Prohlížeč musí navázat spojení se serverem (analytické skripty se zpravidla načítají odjinud, než samotná stránka), server mu musí odpovědět a musí skript poslat. Pokud server odpovídá pomalu, rychlejší javascriptový engine s tím opravdu nic neudělá.
Bylo by ale fajn, kdyby tu prioritu načítání mohl ovlivnit autor stránky a nezáviselo to na nějakém seznamu domén zabudovaném v prohlížeči.
-
Dashiel (neregistrovaný)
Což může už dávno – script může být označen za async/defer a je pak stažen a spuštěn s nižší prioritou (typicky) až po načtení stránky.
Pokud tomu správně rozumím, tak ve FF57 bude blacklist serverů, ze kterých se budou takto skripty stahovat i když je autor webu naprasí přímo do hlavního vlákna stránky.
-
Ano, to může. Pořád je v rukou prohlížeče, jak se k tomu postaví a jak si načtení naplánuje. Spolehlivější by bylo takové skripty přidat dynamicky s cíleným zpožděním třeba pomocí window.setTimeout() nebo až po události načtení stránky.
V případě FF 57 je to rozhodnutí načítat sledovací skripty až po všech ostatních. "The delay is engaged only for scripts added dynamically or as async. Tracking images are always delayed." z původního článku pak říká, že pro zpoždění musí být skripty přidané jako asynchronní. Jinak by to bylo porušení standardu. Sledovací prvky pak identifikují podle stejného seznamu jaký je jinak použitý pro ochranu proti sledování. Ta stejné prvky rovnou zablokuje.
-
Filip JirsákStříbrný podporovatel
Ve zprávičce se píše „úprava se týká jen asynchronně načítaných skriptů“. Takže předpokládám, že jde opravdu jen o asynchronně načítané skripty, a ta úprava znamená, že i asynchronně načítané skripty se budou načítat s různou prioritou.
-
PajaC (neregistrovaný)
Ale odložení načtení asynchronních skriptů je z důvodu zrychlení odezvy a jelikož objemově jsou vzhledem k celkovému obsahu malé, dns resolving rychlý protože jde z keše tak v konečném důsledku _jde_ o jejich provádění. Srovnával jsem stejné podmínky, kdy žádný ze skriptů nemá atribut async a Firefoxu to přesto trvá podstatně déle než vyrenderuje obsah a začne reagovat na vstup.
-
Filip JirsákStříbrný podporovatel
PajaC, 19:15: Myslím, že nedá tolik práce přijít na to, že odkládání spuštění skriptu na později nemá za cíl to, aby byl skript dokončen dříve. Ta nová funkce se týká jen asynchronních skriptů nebo skriptů vkládaných dynamicky. Jejím účelem je nezatěžovat počítač a linku skriptem, který je možné stáhnout a provést později – tím pádem zbyde víc pásma a výkonu právě na to zobrazení stránky, které zajímá uživatele.
-
Celý JS engine se jmenuje SpiderMonkey. IonMonkey je JIT, ale to je jenom detail.
Mít vlastní JS engine a vůbec celé jádro dává smysl z pohledu diverzity. Pokud bude ve všech prohlížečích Blink a V8, může si Google začít diktovat, jak budou vypadat samotné webové standardy. S ohledem na to, jak jeho různé služby fungují jenom v Chrome a do ostatních prohlížečů (i když mají Blink) pošle nějakou ořezanou verzi, nebo je úplně zablokuje, to vidím jako reálný scénář.
Výkon samotného JS enginu se těžko porovnává. Výpočetní benchmarky něco ukážou, ale jsou daleko od reálného použití při přihlížení. A tam je JS jenom jedna z mnoha komponent. Ve Firefoxu je tradičně "brzdou" vykreslování. To snad změní WebRender.
-
koroptev (neregistrovaný)
presne tak, ta brzda je nekde jinde a picusci to neumi odlisit; jedna vec je rychlost provadeni kodu, druha vykreslovani; ve vsech benchmarcich, ktere delam, vychazi rychlost js ve ff bud lepe nebo az radove lepe (treba 6x a to uz to kleslo od doby, kdy to bylo jeste 2x horsi) a nemluvim o nejakych mikrobencmarcich, je to sice specificka v kontrxtu frontendu ale ta stejna cast aplikace, ktera naostro bezi; stran nezrejme vyznamnych mikrobenchmarku je to to same, ff je bud on par nebo rychlejsi, plati tak pro 95% pripadu, ktere me zajimaly
ČLÁNKY DO MAILU