Home/ Questions/Q 8466513
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T15:21:52+00:00

I’m writing my first HTML5 + jquery.mobile web app. The app is basically a

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.
    • 0