I have question concerning optimising application. I have application with multiple directives, so I decided to build single min. css and js file for them all. But at the same time, I was thinking of another way.
What if I would also build one big, minimalised HTML file? Angular allows including templates from script tag:
<script type="text/ng-template" id="tempName">
Template content
</script>
If so, what would be downsides of injecting every directive's HTML in one big file? Would it be any better than multiple small files and firing request when they are needed?
I know, that it wouldn't be so good if we have big application with multiple views, but user only stays at few of them. My idea is to build this file for smaller directives, that shoulnd't cause any problems, right?
What do you think of this?
Like anything there are pros and cons to this approach of caching templates.
Pros:
No need to fetch the template - good for offline capability
If network is slow and this fetch is going to cause some lag as the directive, route, include must resolve the templateUrl. In such cases pre-fetching helps in improving the smoothness of feel.
Pre-fetching also pre-compiles the template ready to be used as it puts in the templateCache.
Cons:
In a large application if all the templates are prefetched we are essentially utilizing more memory to store all the templates when only a handful might get used.
If the prefetched templates are fetched during loading it causes additional request.
If the pros exceed in your application you may want to use some build tool such
as:
gulp-angular-templatecache
webpack-templatecache
grunt-angular-templatecache
... and more
Each file you include is an additional request the browser has to make back and forth, so if u can include it in the same page, then its going to be faster and more efficient.. the main reason for excluding in multiple files is simply for organisation vs the 0.01ms different in page load time.
You can also use something like grunt to work with separate files and then have grunt automatically concat and minify your files for you for on the fly optimization.
Related
I am building a one-page application with Angular JS (1). And I ended with 20 html templates for 20 views/routes.
Now, I am wondering if it's a good idea to simply include all of these templates in the the page directly (using the <script type="text/ng-template" id=" ... .html">), thus eliminating the need for Angular to go and fetch each template separately. Which will definitely better the application performance.
But this of course will be costly on the application loading time; I ended up with 1000+ lines file because of all of these templates being called in the same file.
What do you think is better choice here? I myself comfortable with including all the templates in the page, because this way moving among routes will be much faster.
PS: I know that Angular JS caches the view templates, which of course solves the problem in hand, but any changes I will make on these templates wont be reflected on the user's end, because of the cache! And that's why I think it's a good idea to include the templates in the page, because any changes I make will be surely reflected. What do you think ?
I am working on an enterprise application development in ASP.NET MVC3. Of-course I have different master layouts and multiple views.
My concerns
Including all js/css files in master layout might affect the performance of the page
Including the files in views (where it is required) are creating duplicate references (kick-off jquery/other libraries)
More the references, the more the back&forth requests between client and server - which in turn affect the performance of the output page
My Thoughts
Create a custom list of required resources and store it in ViewBag. Let the master layout refer this object to include the js/css files
Or add the link referring an action with some key (an unique value to identify the page being rendered) and dynamically generate an output with all required resources as a single response. And cache the output (inmem/staticfile) with the unique key for succeeding requests. A kind of custom resource bundling.
Please share your ideas, any thoughts and suggestions are welcome!
EDIT: Sep.17.2012
Below answers are more talking about optimization techniques in web application development world - appreciating those answers.
I would like to discuss from an architectural perspective, focusing on creating a dynamic resource collection required by the page being rendered.
For example, in specific views I would like to use jQuery UI which requires jquery-ui-1.8.11.min.js, and in certain views I would like to use MVC3 ajax which requires MicrosoftMvcAjax.js and jquery.unobtrusive-ajax.min.js
I don't want to include permanent reference in master layout, which will result in loading these js for all views. Rather I would like to include the js files dynamic during runtime.
Hope this might have added clarity!
Thanks for the help - Vinod
You need to think about reducing your download size first:
putting all your js and css into as few files as possible. This is because a client can only open 2 HTTP channels (most browsers now support more, info here) at any one time, all file downloads after this are queued until the previous ones finish downloading.
minify your js and css.
Once you've got this down to a reasonable size then you can think about the above. You want to download, the smallest amount of content upfront, so in the master. This will improve performance because then the client can cache it. Caching is a good thing, this stops the client having to request the js and css every time they visit a page on your site.
You might also want to think about applying HTTP expiry headers.
Yahoo do a good site on lots of these ideas: http://developer.yahoo.com/performance/rules.html
Also don't put your js in the viewbag. This is unnecessary overhead and load on the server. Just add a reference in your pages!
MVC4 now supports bundling
When I write my JS files for a Django project, of course I do some AJAX calls, and for the moment the urls for those calls are hard-coded (which is very ugly).
I was thinking of having the JS files served by django (instead of Apache), so I could take advantage of the template tags ({% url %} !!!).
Is there a reason why I shouldn't do this ?
Or is there a right way to do this ?
(I can give a least one : it will consume a lot of time resending JS files that haven't changed. What would be great is to have an application that generates files when restarting django server, and serves them statically after !)
I would go for a hybrid technique. Serve most of your javascript statically. But in your Django template, have a <script> block that defines various global variables, which are generated by the server-side code - url is a good example. Then your static JS can refer to the variables that are generated in the dynamic code.
I searched deeper in those asset manager applications from djangopackages, have found out that django-mediagenerator provides that feature, even if it is not well documented : you can generate your js or css files as django templates, and then serve them statically (they are also bundled, and caching is managed etc ... so two birds with one stone + it is really easy to set-up !).
In order to have JS files generated as django templates (after having set-up django-mediagenerator), just add the filter :
ROOT_MEDIA_FILTERS = {
'js': 'mediagenerator.filters.template.Template',
}
in your settings.
Dynamically generating Javascript on your server can be a tremendously powerful tool and I've experienced both it's upside and downside in my projects.
In general you want to keep as much as possible static to minimize the work to be done on every request. This includes having the browser cache as much as possible, which might become a problem in your case.
What I usually do is to have a block in the header in my base template. In templates that need to do custom javascript that is only known at runtime (customization based on logged in user, for example), I add it to the block. Here I can dynamically generate javascript that I know won't be cached so I can make some assumptions. The downside is more complexity.
If what you need are just pointing to urls, or have some simple configuration, etc, then I would suggest creating a view that will return a Javascript file with these settings. You can set the correct headers(Etag, Cache-Control, etc) so the browser will cache the file for some reasonable time. When you upgrade your code, make sure the Etag will change.
In the code that needs to use the configuration, you need to always check that the variable you are looking for is actually defined otherwise you will run into problems that are hard to debug when for some reason the configuration javascript is not loaded correctly.
The .js that gets sent to the browser would vary. That could make debugging more cumbersome. Maybe not a problem but something to potentially consider...
Nowadays, the best way to do this is to use Django.js
Here is the doc where they talk about the URL reversing: http://djangojs.readthedocs.org/en/0.8.1/djangojs.html#reverse-urls
Nowadays, we have tons of Javascript libraries per page in addition to the Javascript files we write ourselves. How do you manage them all? How do you minify them in an organized way?
Organization
All of my scripts are maintained in a directory structure that I follow whenever I work on a site. The directory structure normally goes something like this:
+--root
|--javascript
|--lib
|--prototype.js
|--scriptaculous
|--scriptaculous.js
|--effects.js
|--..
|--myOwnScript.js
|--myOwnScript2.js
If, on the off chance, that I'm working on a team uses an inordinate amount of scripts, then I'll normally create a custom directory in which we'll organize scripts by relationship. This doesn't happen terribly often, though.
Compression
Though there are a lot of different compressors and obfuscators out there, I always come back to YUI Compressor.
Inclusion
Unless a site is using some form of a master page, CMS, or something that dictates what can be included on a page beyond my control, I only included the scripts necessarily for the given page just for the small performance sake. If a page doesn't require any script, there will be no script inclusions on that page.
First of all, YUI Compressor.
Keeping them organized is up to you, but most groups that I've seen have just come up with a convention that makes sense for their application.
It's generally optimal to package up your files in such a way that you have a small handful of packages which can be included on any given page for optimal caching.
You also might consider dividing your javascript up into segments that are easy to share across the team.
Cal Henderson (of Flickr fame) wrote Serving JavaScript Fast a while back. It covers asset delivery, not organization, but it might answer some of your questions.
Here are the bullet points:
Yes, you ought to concatenate JavaScript files in production to minimize the number of HTTP requests.
BUT you might not want to concatenate into one giant file; you might want to break it into logical pieces and spread the transfer cost over several pages.
gzip compression is good, but you shouldn't serve gzipped assets to IE <= 6, so you might also want to minify/compress your JavaScript.
I'll add a few bullet points of my own:
You ought to come up with a solution that works for both development and production. In development mode, it should pull in extra JavaScript files on demand; in production it should bundle everything ahead of time. Switching from one behavior to the other should be as easy as setting a flag.
Rails 2.0 handles all this through an asset cache; other web app frameworks might offer similar solutions.
As another answer suggests, placing third-party libraries in a lib directory is a good start. You can also divide your own JS files into sub-directories if it makes sense. Ideally, you'll be able to arrange them in such a way that the files in a given sub-directory can be concatenated into one file.
I will have a folder for all javascript, and a sub folder of that for 3rd party/shared libraries, and sub folders for each component of the site to keep everything organized.
For example:
/
+--/javascript/
+-- lib/
+-- admin/
+-- compnent1/
+-- compnent2/
Then run everything through a minifier/obfuscator during the build process.
I'v been using this lately:
http://code.google.com/apis/ajaxlibs/
And then have a "jscripts" folder where I keep my custom code.
In my last project, we had three kinds of JS files, all of them inside a JS folder.
Library code. A bunch of functions used on most all of the pages, so they were put together in one or a few files.
Classes. These had their own files, organized in folders as needed, but not necessarily so.
Ad hoc JS. Code that was specific to that page. These were saved in files that had the same name as the JSP pages they were supposed to run in.
The biggest effort was in having most of the code on the first two kinds, having custom code only know what to call, and when.
This might be a different approach than what you're looking for, but I've been playing around with the idea of JavaScript templates in our blog engine. In a nutshell, you assign a Javascript template to a page id using the database and it will dynamically include and minify all the JavaScript files associated with that template and create a file in a server-side cache with the template id as a file name. When a page is loaded, it calls the template file which first checks if the file exists in the cache and loads it if it does. If it doesn't exist, it creates it on the fly and includes it. I also use the template file to gzip the conglomerate JavaScript file.
The template idea would work well for site-wide JavaScript (like a JavaScript library), but it doesn't cover page-specific JavaScript. However, you can still use the same approach for page specific JavaScript by including a second file that does the same as above.
I've just started developing an ExtJS application that I plan to support with a very lightweight JSON PHP service. Other than that, it will be standalone. My question is, what is the best way to organize the files and classes that will inevitably come into existence? Anyone have any experience with large ExtJS projects (several thousand lines).
I would start here http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/
This site gives a good introductory overview of how to structure your application.
We are currently using these ideas in two of our ASP.NET MVC / ExtJS applications.
While developing your application your file and folder structure shouldn't really matter as you're probably going to want to minimize the release code and stick it in a single JS file when you're done. An automated handler or build script is probably going to be the best bet for this (see http://extjs.com/forum/showthread.php?t=44158).
That said, I've read somewhere on the ExtJS forums that a single file per class is advisable, and I can attest to that from my own experience.
I suggest users are willing to wait for an application to load, so we typically load all of JS during initial app startup. I suggest loading and eval'ing JS files as needed is unnecessary - especially when all JS will be minified before deployment to production.
I suggest namepsaces, one class per file, and a well-defined and well-documented class hierarchy.
When starting new big project, I decided to make it modular. Usually, in big projects not all modules are used by a particular user, so I load them on demand. F.e., if a project would have 50+ modules, the big probability is that user is working only with 10-.
Such architecture lets you to have the initial code relatively small.
Modules are stored on the server and loaded by AJAX call, eval'uating the responseText in AJAX callback. The only issue with this, you must keep track on module dependencies, which could be stored inside modules as well. I have a class called Module, and I check every new module instance for existance within the task. If it doesn't yet exist, I load it from the server.