Page Visibility Performance Boost

On SitterSat’s home page, the latest two blog posts are fetched from another domain, namely SitterSatBlog.com.  In this post, I wrote about how I asynchronously fetch those posts and temporarily cache them in the user’s browser for faster performance using the convenience of Modernizr‘s sessionStorage check.

All is well

I put that code in a nice tidy common .js file that makes me happy.  It is working nicely.

All is not well

And then oops.  I created another separate web page to do something else, something that has nothing to do with fetching sittersatblog.com posts or showing them in any way.  In creating that web page, I reference this same tidy common .js file I created earlier.  Therein lies the problem, I’m now using code in both pages, code that is in a nice tidy common .js file, but code that isn’t so common after all.  I need that in the home page only, not in this secondary page I created.

Well, that’s an easy fix.  Just don’t do dat anymore (mispelled, yes, I know, lame humor).  Just move that out of the nice tidy common .js file and put it somewhere else or perhaps create a new .js file for the new web page.  Whatever, you get the point, it’s very easy to fix.

In comes page visibility API

But something registered with me, something I’d read about some time ago and thought was really cool.  It was the Page Visibility API on html5rocks.

So rather than fix this, I will use this mistake as an opportunity to test out a new API I thought was really cool.  Why not.  So here’s how it goes.  Oh and real quick, for a really useful example, something that actually makes sense, check out the Play and Pause a Video way down on the html5rocks page.  I just needed to mention that as a potentially useful example!  :>  So, again, here’s how it goes.

1.  You remember that function doLoadBlogRoll I wrote about earlier.  If you don’t, that’s the function I use to fetch the blog posts (either in session or via sittersatblog.com)  Well, now I don’t call it, I call the function visChange instead.


//Call this function which will do the work of rendering if needed
visChange();

2.  Here’s what visChange does.  It finds out if there is an element on the page called div_blogroll.  Look at my previous post and you’ll see that element is what contains the actual blog html text on the home page.  So if the div element is not visible (say, you’re that different secondary page I spoke of), don’t call the doLoadBlogRoll function.  If it is visible, call it.


    //check if the div_blogroll is visible on the page, if so, render it
    function visChange() {
        var divBlog = document.getElementById('div_blogroll');
        if (divBlog) {
            if (!isHidden())
                doLoadBlogRoll();
        }
    }

3.  And finally here’s all the other supporting functions right off html5rocks as well. It’s a bunch of nice tidy helper stuff courtesy of html5rocks.


    //pagevisibility API
    function getHiddenProp() {
        var prefixes = ['webkit', 'moz', 'ms', 'o'];
        // if 'hidden' is natively supported just return it
        if ('hidden' in document) return 'hidden';
        // otherwise loop over all the known prefixes until we find one
        for (var i = 0; i < prefixes.length; i++) {
            if ((prefixes[i] + 'Hidden') in document)
                return prefixes[i] + 'Hidden';
        }
        // otherwise it's not supported
        return null;
    }

    //helper function
    function isHidden() {
        var prop = getHiddenProp();
        if (!prop) return false;
        return document[prop];
    }

    //use the property name to generate the prefixed event name
    var visProp = getHiddenProp();
    if (visProp) {
        var evtname = visProp.replace(/[H|h]idden/, '') + 'visibilitychange';
        document.addEventListener(evtname, visChange);
    }

All is well again

The end result? The fetch code is not called unless I’m on the home page. While on the secondary page, the code is ignored. Of course, that is, if the browser supports the Page Visibility API. So in the spirit of browser compatibility, cleaner separation of code and increased performance (not calling code unnecessarily even if just a few lines), I should probably undo this and just separate out the code.  Still, this was a fun experiment.

Advertisements
Leave a comment

1 Comment

  1. Bad Weather Coming « about ss

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: