2 ms·

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

by cbr 14y ago

WickyNilliams 14y ago
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.
- shawnjan8 14y ago
  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 :)
  - WickyNilliams 14y ago
    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
shawnjan8 14y ago
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.
- cbr 14y ago
  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).

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

by cbr 14y ago

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.

shawnjan8 14y ago
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 :)
- WickyNilliams 14y ago
  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

shawnjan8 14y ago

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.

cbr 14y ago
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).