This is *very* jarring if you visit a page and see three stacked content divs, and then a second later they all disappear and a tabset shows up in place of it. Worse, you have JavaScript like jQuery-UI tabset plugin which actually drastically reorganizes your page with new script-enabled widget goodness. This is a good approach (loading javascript functionality in layers)… but the main key there is that Primer is loaded synchronously/blocking, so it’s guaranteed to be there before a user can start interacting.Ģ. This is especially jarring if you’re already typing into a text box and all of a sudden JavaScript arrives and takes over the box and redoes it, etc.įacebook has Primer, where they define some default (JavaScript-driven) fallback behaviors for all (or most) of their page widgets. content that has the web 1.0’ish fallback functionality (like form posts in lieu of ajax), such that if you interact with the page too quickly, you’re getting the degraded experience. It’s a different spin on the more well known FOUC regarding content displaying before CSS is present to make it look pretty.įUBC becomes a much more noticeable problem when you have content (and CSS) that is displaying before the JavaScript arrives. I call it FUBC (Flash of Un-Behaviored Content). Great article as always, and very timely.īut I’m concerned that you’ve glossed over a really important point when you start “deferring” JavaScript by a noticeable amount on pages. When I mention this idea these are the typical arguments I hear for why this won’t work: I’ve been talking this up for a year or so. Achieving this goal is going to involve advances from multiple camps – changes to browsers, new web development techniques, and new pieces of infrastructure. My #1 goal right now is to figure out ways that web sites can defer all JavaScript execution until after the page has rendered. But anyone who disables JavaScript in their browser can attest that sites feel twice as fast. I don’t have scientific results that I can cite to substantiate this claim (that’s part of the big projects I’m working on). This is the biggest obstacle to creating a fast user experience. If asynchronous scripts arrive while the page is loading, the browser has to stop rendering in order to parse and execute those scripts. Getting the content in front of the user as quickly as possible is the goal. The downside is – although web sites are doing a better job of downloading scripts without blocking, once those scripts arrive their execution still blocks the page from rendering. And 8 of today’s Alexa Top 10 US sites use advanced techniques to load scripts without blocking: Google, Facebook, Yahoo!, YouTube, Amazon, Twitter, Craigslist(!), and Bing. Most JavaScript frameworks have async script loading features – two examples are YUI and LABjs. There has been more research on async script loading from folks like Google, Facebook and Meebo.
Months for a single chapter! I wasn’t the first person to do async script loading – I noticed it on MSN way before I started that chapter – but that work paid off. It took me months to research and write the “Loading Scripts Without Blocking” chapter from Even Faster Web Sites.
But, I agree that an email response that only a few people might read is not the best investment of time.
I started to type up my lengthy response and remembered one of those tips for being more productive: “type shorter emails – no one reads long emails anyway”. But I got an email today about asynchronous JavaScript loading and execution. I’m in the middle of several big projects so my blogging rate is down. To achieve this JavaScript loading and execution has to be deferred. The key to creating a fast user experience in today’s web sites is to render the page as quickly as possible.
0 kommentar(er)
