简体   繁体   中英

html5: a good loading approach?

I'm writing my first HTML5 + jquery.mobile web app. The app is basically a menu which redirects to internal pages (data-role="page") defined in the same index.html. I do not write pages as external files to avoid reloading and rewriting the - substantially - same <head>: I suppose it's faster to jump to an internal tag than loading a new page...

Now, I have a page which needs some specific jquery plugins and some specific css. No other page needs these plugins or css.

Of course I could load these js/css in the main <head> section, but this approach would slow the first page loading, uselessly.

I could solve the problem with CSS, with:

$('head:first').append('<link rel="stylesheet" type="text/css" href="' + file + '" />');

I could even solve the problem with JS, but only for 'standard' JavaScript, with something like:

<script>
    $(document).ready(function() {
        $('#page-availability').live('pageinit', function () {
            $.getScript("js/jqm-datebox.core.js");
            $.getScript("js/jqm-datebox.mode.calbox.js");
            $.getScript("js/jquery.mobile.datebox.i18n.en.utf8.js");

            $('#datepicker').data({
                "mode": "calbox",
                ...
            });
            ...
        });
        ...
    });

Unfortunately this approach seems not to work (firebug croaks: "TypeError: a.mobile.datebox is undefined"...) with jquery plugins: it looks like they are not evaluated... (even if they are there, before the end of the <head> section, viewing at the "Generated Source"...).

I'm using Firefox (15) to debug, but I suppose this isn't the point...

Any hint?

The one page approach can be good for mobile if:

  1. You don't have to load too much extra content in order to support all the content the user might show from that one page.
  2. You don't have to load too much code to support all the behaviors.
  3. The typical user actually does go to several different virtual pages so the scheme saves them load time and makes things quicker on subsequent virtual page loads.

Done well, the user gets OK performance on loading the first page and very quick performance when going to the other "embedded" pages that don't have to load new content over the network.

The one page approach is not so good if:

  1. The initial load time is just more than it's worth because of the volume of stuff that must be loaded.
  2. You have to dynamically load content for the sub-pages anyway.
  3. You have SEO issues because the search engine can't really find/properly index all your virtual pages.

So, in the end, it's a real tradeoff and depends very much on how big things are, how many things you're loading and what the actual performance comes out to be. A compact mobile site can serve server-loaded page views from one page to the next pretty quickly if the pages are kept very lightweight and there are very few requests that must be satisfied for each page.

In general, you want to pursue these types of optimizations:

  1. Compress/minify all javascript.
  2. Reduce the number of separate items that must be loaded (stylesheets, javascript files, images).
  3. Reduce the number of sequential things that must be loaded (load one, wait for it to load, load another). Mobile is bad at round-trips and loading lots of resources. It's OK at loading a few things.
  4. Make it easy for the browser to cache javascript files. Use a few common javascript files that each serve the needs of many pages. Loading a little more at the start and then allowing the javascript file to be loaded from cache on all future pages loads is way, way better if the user will be visiting many successive pages on your site. The same is true for external CSS files.
  5. Very very careful of lots of images, even small images. Lots of http requests in order to load a page is bad for load time on mobile and every image you request is an http request (unless it comes from the browser cache).
  6. Make sure your server is configured to maximize browser caching for things that can be effectively cached.

Other things to be aware of:

  1. By default dynamic loading of script files is asynchronous and unordered. If your script files must execute in a specific order, then you will have to either not load them dynamically or you will have to write code (or use a library) that serializes their execution in the desired order.

$.getscript is a shorthand AJAX function, it takes a callback as the second parameter. Check out the docs: http://dochub.io/#jquery/jquery.getscript

You could concatenate those scripts and then do your stuff in the callback.

This is not so dissimilar to old Flash asset loading issues.

My strategy for that? load only whats necessary for the initial page view. When its loaded and the page / app is viewable by the user, progressively load all other assets.

If the assets were particularly heavy, then I would disable the link to that specific page until its required assets were loaded.

In this case, you might disable the link to the particular page at the outset, initiate the load of its assets, and when they are ready, enable the link.

Not sure if you're having any syntax issues, but you can certainly just inject a new script element into the head with the correct source, and it will instigate a download (like you are doing with css. But you probably know that ;D )

Cheers

I would just combine/minify and compress all the JS in one file and always load that. This is something (with correct caching) which is only downloaded once so you don't have to worry about performance much.

Of course I could load these js/css in the main section

I often just add it just before the </body> and tag. Also note that besides the fact that .live() is deprecated it is also slow as hell . So don't use it, but use .on() .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM