Proposal: Enhance HeroElement

HeroElement is proposed by @panicker. We extend it a bit here. In short, HeroElement is an important element in web page which is specified by web developer.

Why HeroElement?

With HeroElement, user agent could easily distinguish critical part of web page and optimize it. Web developer could have a clear picture of the important element.

The basic idea of HeroElement

• For User Agent:

  • Get the element that named as HeroElement
  • Optimize and monitor
    • Speed up: speed up the process of HeroElement
    • Monitor and generate events
      • Dom constructed
      • All subresource loaded
      • Fully layouted
      • Fully painted
    • ElementTiming: Had been discussed at TPAC 2016

• For web developer:

  • Specify a HeroElement, listen to the corresponding events
  • The HeroElement will be speed up
  • Trigger other movement when events fired
  • Analysis the performance of HeroElement by ElementTiming

How to use?

• HTML grammar:

    <div heroElement="needspeedup needTiming" onFullPainted="foo()">
    // or
    <div markAsHeroElement="true" speedup="true" elementTiming="..." onFullPaintted="foo()">
  

• HeroElementAttr:

  • element
    • The element specified as HeroElement
  • needspeedup
    • According to HeroElement，control the parsing process of HeroElement. E.g. Once HeroElement be parsed don’t break parsing until got its end tag, after that, stop parsing immediately and do next process: layout, paint…
    • Record the sub-resource of HeroElement as key-point sub-resource，high priority them, or cache them before hand.
    • others
  • needTiming
    • ElementTiming
  • events
    • finish dom constructing: Got the end tag of HeroElement
    • finish loading: All relevant subresources downloaded
    • finish layouting： The first layout pass after finishing load
    • finish painting： The first paint after finishing layout

Use cases

• Use case 1:

  • Speed up the process of first screen paint. The time of first screen paint is when the first screen content fully painted. From first screen paint users could read web content. User agent would speed up the first screen paint. User agent guesses which elements belong to first screen content. That isn’t accurate usually. With HeroElement, user agent could easily know that.

      <!-- All the nodes inside heroElement will be handled in one parse pass -->
      <!-- or <div markAsHeroElement="true" speedup="true">first meaningful paint</div> -->
      <div heroElement="true false">
        <!-- First screen content begin -->
        <h1>first meaningful paint<h1>
    
        <!-- This image will be speed up -->
        <img src="...">
    
        <!-- Lots of element -->
        ...
        <!-- First screen content end -->
      </div>
    

    QQBrowse has implemented speedup optimization of first screen paint by HeroElement. Cooperating with sogou search page, this optimization speed up the first screen paint of sogou search page in wifi by ** 25% ** on average. See the comparing video here

    Tracing data screenshot compare:

    • without HeroElement Optimization

      

      without HeroElement Opt1878×615

    • with HeroElement Optimization

      

      with HeroElement Opt1880×613

• Use case 2:

  • Show the HeroElement on screen after it finish paint. With a mask this could reduce the appearance of white screen. But it couldn’t be sure if the images has been drawn. “FullPaintFinished” fired when all subresouces finish loading. So “FullPaintFinished” could be a signal of HeroElement been fully painted. This solution used a lot in hybrid apps which listened “onPageFinished” of webview to switch views. However, “onPageFinished” is not the exact time of content fully painted. Go a little further, maybe WebViewClient could consider of adding a “FullPaintFinished” API too.

     <!-- Mask -->
     <div id="mask" style="position:fixed; width:100%; height:100%; background-color:blue;"></div>
    
     <!-- Content -->
     <!-- or <div markAsHeroElement="true" onFullPaintFinished="foo()" id="hero" style="visibility: hidden;"> -->
     <div heroElement="false false" onFullPaintFinished="foo()" id="hero" style="visibility: hidden;">
       <!-- Contains lots of images -->
       ...
     </div>
    
     ...
    
     <script>
     	function foo() {
     		document.getElementById("mask").style.display="none";
     	}
     </script>
    

Continue

• Specify sub-resources that involved in “finish loading”
• Others

Related

We found the optimizing of first screen content paint will be more effective if we know the exact elements which are shown in the first screen. The concept of HeroElement proposed by panicker@ is used in ElementTiming. We add speeding-up into HeroElement. According to QQBrowser’s experiences we know web developers care about the first screen content paint’s finishing time. So we add the event notification into HeroElement. Baidu once proposed first screen paint optimization with render optimization policy in 2014. After discussing with them, we think we could work in this direction further.

I’m not sure if this stuff about HeroElement has been discussed before. Any suggestion is welcomed:) @igrigorik, @panicker

Aren’t browsers already processing every element as fast as they can? What should the browser do differently to speed up the element?

This sounds like it could be simplified to a straightforward priority system. It sounds like you just want to assign “high priority” to an important element. It might also be useful to assign low priority to less important elements. As it stands you only have a boolean priority (hero element, or not), whereas I think more control would be useful.

We could try these two ways speed up the element:

1. Control the process of parse: As we want to show “HeroElement” on screen as soon as possible. After the begin tag of HeroElement being parsed we could stop parsing when meet the end tag of HeroElement, so that HeroElement will be layout and painted immediately after its sub dom tree constructed. As we could see from “use case 1”, this optimization could save 183ms for the first parse pass.

2. High priority of sub-resource related HeroElement.

Priority system of elements is very thorough. We could make good use of resource during the early stages of navigation.

I don’t think you ever want the browser to stop parsing. That would slow down the overall page load. It sounds like you just want to force a layout after that element is loaded.

I think I basically agree with AshleyScirra, associating prioritization thing into the Hero Element idea seems to limit several potentially interesting usage scenarios, it feels that problem should be separately addressed by the Hero Element idea that was inherently designed for different purpose-- i.e. measurement?

Yes, that’s right:) Besides speeding up, the content of next paint could be forecast.

Yes, I do agree with priority system idea.

I’m thinking the scenarios of using low priority(Suppose we have 3 priorities: high\middle\low). Such as: We could ‘low priority’ comments, folded content… With a certain parse policy, the whole page load could be speedup. Or other interesting scenarios? Besides changing parse policy and sub resouce priorities, do we have other ways to optimize? @AshleyScirra @kinuko

If this is a hint to browsers for rendering wouldn’t it fit more into CSS?

CSS already has will-change so there’s precedent for these sort of attributes there. It also means we’re not having to make changes to our documents for presentation purposes.

Even more useful is that you may actually want to change your prioritization based on media queries.

Thanks for replying:)

As we want to optimize the process of parse, we need to distinguish “the important element” during parsing, so we should use element attribute instead of CSS for CSS could locate an element only after it has been applied.

List some scenarios of element priorities here:

similar to the discussion about “call to action” links Proposal - optional role for <a> to indicate if it is a ‘call to action’ to a screenreader user, i’d say that instead of making one specific new element or attribute to denote a hero, it would be far more sensible and flexible to allow for a more generalised way to define importance/priority (as an attribute, rather than new element type)

I’d be worried about misuse. I can already see developers wrapping every element with HeroElement because they think or were told it would “speed things up”. But of course if everything is a hero, nothing is a hero.

It sounds like the idea here is mostly for things like “hero slideshows” at the top of the page, some sort of way for speeding up the performance of sites that utilize that pattern because those can get heavy. First I’d examine what patterns are available today to not run into such a optimization bottleneck in the first place (lazy loading).

I feel like a lot of emphasis is put into rendering “above the fold” content, but there is no fold in web design. If your websites supports the URL hash to deep link half way down pages, which it should, then a user might not land at the top of the page at all. So I would be considered with an element that is off canvas being “sped up” because that means the things I’m actually viewing are slowed down.

I think web components and progressive rendering should also be considered in this discussion. It is possible that within the next few years, modern web apps will become much more modular. The app could consist of independent components, each with their own top-level custom element, JavaScript module tree and set of style sheets (no more global bundles), and these components would then be sequentially rendered, as they’re encountered in the HTML document.

I think the risk with even just a prioritization system is that browsers already have pretty good heuristics around how to prioritize the requests and rendering of a page. I think there’s a good chance a dev will naively make some big element a high priority, and actually end up de-optimising the page, because it blocks something actually more important like the CSS for it. We should try to avoid performance primitives that are easy to use incorrectly. But I don’t know how this could be adjusted to be difficult/impossible to use incorrectly.

Agree. Using priority is more generic. “Call to action” link looks like a perfect use case to element priority system.