I am developing a very large/complex Single Page Application and I'm experimenting with different techniques to speed up my performance.
My app makes use of many ui widgets (both from jquery ui, and the jqWidgets library), and currently I load all the html and initialize all the widgets upon pageload (regardless of whether the widget is used, i.e. popup windows are initialized and remain hidden until called upon).
I realized that I could save some resources by only loading the widgets that the user is going use, right before they are needed, pretty standard. So I basically have two choices here:
1.) I can move all the HTML into a javascript file that injects (appends) the relevant html, then initializes the widget right before the call to the widget, something like this:
$("#widgetWrapper").append("<div id='newWidgetID'></div>");
$("#newWidgetID").methodToCreateWidget();
2.) I can do basically the same as above, except retrieve the HTML from the server via ajax.
Pros/Cons
I am not well versed on client-server performance but I see some obvious pros and cons here, by moving the HTML into a javascript file that does all my DOM manipulations, I am not decreasing the amount of data that my site requires on pageload, im only shifting the data from the html body, to a js file, BUT I am DRASTICALLY reducing the number of initial DOM elements.
My only fear of method 2 is that a slow client-server connection might cause a non trivial delay in my ui response time.
Are there any suggestions on how to tackle this issue? I'm heavily leaning towards method 1, what are the industry standards? Or should I just say "to hell with it" and go ahead and load and init everything upfront (long wait at login, but fast ui response) and hope that browsers continue to make leaps and bounds in the area of JS performance (with the exception of IE of course).
Mixing 1 and 2 solutions can be your best option here. Use an ajax call to retrieve only the "data" and a JS function to transform this data into a complete HTML interface, at the time you need it.
I think you need to look at what your audience is. I would also lean towards #1, for the simple reason that loading something when you actually need it is way more user-friendly, especially for users on a roaming connection. A nasty side effect can be personalized content, you need to prevent caching: http://api.jquery.com/jquery.ajax/
#1 is superior in my opinion, because it reduces the bandwidth in the initial load, reduces the DOM loading on initial load (which improves a lot for users with older browsers and slower connections or mobile devices). The downside is that not all "frames" or "widgets" are loaded when the page is loaded but I would take that for granted with a small spinner or something similar.
After reading over your question, I think you have overlooked perhaps the easiest answer. You are currently thinking of loading everything at the page load, or only just before it is needed. With the first situation, you end up increasing your page load time, while the second risks a noticeable delay in UI response.
Your solution is to instead load the extra stuff immediately after the core functionality is ready to be used, this means that the UI will be ready for interaction, while the extra functionality is being loaded in the background.
Thus, your script should look somewhat like this:
// Code that has to run while the page is loading
/* YOUR CODE */
// Code that has to run when the DOM is ready
$(document).ready(function(){
/* YOUR CODE */
})
// Code that has to run when the core functionality has been loaded
$(window).on('load',function(){
/* YOUR CODE */
})
By adding your ajax calls in the third section, they are made only after the core UI is loaded, thus speeding up your initial load time without risking UI delay. You should program your application properly though to make sure you dont try and call on any of the 'extra' functionality untill it has been loaded.