Manipulate the DOM before any resources have loaded using Capturing | Hacker News Reader

Manipulate the DOM before any resources have loaded using Capturing

hacks.mozilla.org

61 pointsshawnjan811 comments

Sadly it's not a native API, but a clever hack that effectively comments-out source of the page with a legacy `<plaintext>` element (proving that old cruft is really hard to kill in HTML :)

Some of my coworkers made a firefox os app installation page that had both <marquee> and <blink>. At first I thought they were doing some crazy css animation thing to get scrolling, flashing text on the phone. Nope, just marquee and blink.

Capturing as a native feature of the browser is something that we really hope to see down the line. There are many reasons you might want to disable the pre-parser, and our goal is to empower the developer to make that decision themselves. I'd default it ON though :)

Adding a blocking javascript resource that disables speculative resources loading is going to speed up pageloads?

I had the same thoughts. You may be able to reduce bandwidth if you're doing something like responsive images (even then, over a mobile connection, I'd rather low-res images be sent to phone despite the pixel density of my screen), but at the expense of taking longer to start rendering. There's probably a sweet spot between time to render and page weight, but I think this probably makes things worse. I'd rather see things load slowly than double parse the document and see nothing but a blank web page (which i might interpret as the site being completely unresponsive).

Perceived load time is often as important as actual load time. A site that takes 10 seconds to load but spend 80% of that is showing a white screen may feel slower than a website that takes 15 seconds to load but only 10% of the time is white screen.

Hundreds of websites use Mobify.js today, and the feedback we get has always been the same - how do you make it so fast?! I completely agree about perceived load time - it is just as important to consider as actual load time, and if Capturing caused a 10 second white screen, then the technology would be not very useful. Luckily, Capturing is very quick, and with the speed of mobile devices greatly outpacing the speed of networks, Capturing becomes even more useful. Plus after the first load, every subsequent page is EXTREMELY fast, due to the library cached and optimized by the JIT.

Of course, if you find that the initial white screen is taking longer then you would like, you could easily render out your logo and background color before capturing the document to improve perceived load time :)

Thanks for the response. I will look into this as it's something I am interested in. Can you give me an example of a site using it? So i can get a feel for what's possible

Yep :). There is some initial slowdown (from our testing, it ranges from 60 to 300 ms on average), but the benefits of being able to determine which resources you want to load through the properties of the browser can cause you great gains in performance. Plus, after the library has been downloaded once, the library is cached, and optimized by the JIT on every subsequent load.

I would love to see some waterfalls or ideally real-user measurements.

Actually, just a few sample pages, one with the Capturing version and one with the standard (media query) version would be helpful.

I made some comparison pages myself, but I don't think they're very good:

    http://www.jefftk.com/test/capturing/off?ModPagespeed=off
    http://www.jefftk.com/test/capturing/on?ModPagespeed=off

And when I ran webpagetest it didn't speed up download time on desktop or mobile (time to onload ("plt") decreased, but only because the images were postponed until after the onload event).

I didnt know this was a thing, wouldnt this be a really nice place to be doing l10n?

or you know, you can use some inline scripts, brand new lib coming out next week i guess.

Reply on news.ycombinator.com