Welcome Guest, Not a member yet? Register   Sign In
Numerous CSS and Scripts Loading in Every View

Each include is another HTTP request. So Xwero's approach would be ideal, rolling them into one. I worked with a company whose CMS was made to roll all the CSS files into one and name is a hash of all the files, that way every time you change which files you're combining, the name changes too. It saves your browser from caching new CSS.

My opinion is that you'd be better off combining everything and having the client download code they might not need, then to have them download 15 different files. They might have to download code they don't need, but your JS can be minified and it will likely be faster for the user having less requests and little higher filesize. Not to mention, all the CSS & JavaScript for your site will now be cached, so the user will already have what they need for new pages - sort of like prefetching.

EasyLancer posted a link to a an online tool which takes multiple files and compresses them all into one
thread here | Direct link

jdfwarrior why make the controller responsible for adding files it isn't aware of in the first place? I think it's worse than Dregond's solution.

In the response you quoted i stated "they also should contain as less unneeded code as possible". If you add a little more code than needed to the common file you can prevent of needing the controller to manage the inclusions.

Because it's jquery Fielder should check out Lazy - The on-demand jQuery plugin loader. people write all sorts of crazy plugins for jQuery Wink

With lazy loading, would you not get a small delay when you want to use some jquery functionality, as it then downloads it?

I guess, it would be foolish to think it would cause no performance loss. I was exploring options to load plugins.

I think the best way is to put JS files at the end of the HTML, so they only get loaded once you've rendered the HTML

Is this what you're looking for - http://www.websiteoptimization.com/speed/tweak/defer/?


Another way to look at it is that putting your scripts in the head allows the JS to be executed as soon as the dom is ready. If the page loads and a few seconds later your JS runs, the user might be confused, or might've scrolled past the effect, whereas if the JS is already loaded and executes as soon as the page loads, your user gets the desired effect.

At least the DOM loading has a visual cue, and users are familiar with waiting for the page to load. However they won't know to wait for the JavaScript load.

I vote for leaving JS in the head. It's also more developer friendly as all the scripts can be found in one place.

@gary: I agree this wouldn;t work, but if all you're JS is for on click events and stuff (aka not immediatly visual) then there is no loss with loading it at the end, as I doubt anyone will trigger an event before its loaded
It may not be the best or cleanest solution (as you said its no longer keeping the imports in the normal place) but its an idea which would make the perceived load time a little quicker as the number of initial requests to render the page is reduced

Makes sense. Perceived load time is real load time to the user. Worst case though is if the user DOES click something that should've had an event binding before the JS loads, your page will load fast, but seem broken. This has a high potential of happening since, in my experience, I've seen a lot of servers lag a bit on some of a page's includes. I've noticed it a lot with including jQuery through google. Sometimes google will take a few seconds to fill the request.

I guess it really depends on what you're doing with JavaScript. In many cases, it doesn't need to be there onDomReady.

Theme © iAndrew 2016 - Forum software by © MyBB