I have been optimizing my website but the one problem that stands in my way is all the jQuery functions that I do not use. The only ones that I use are for a smooth page scroller. It just seems like such a waste of download time.
My question is: Is there any script or program that will remove the jQuery code that I do not need and leave the 1 or 2 functions that I do need.
There's no way to do this, especially since it's not that simple. For example .fadeIn() is one method, but it calls the whole animation section of jQuery to fade the element, but that's after your selector has accessed the traversal section including the Sizzle selector engine...that's how most frameworks are, it'd be very tricky to remove pieces because of so many dependencies inside the framework itself.
That being said, if you're delivering jQuery correctly, it's minified and gzipped, and you're only sending about 24kb to the client which they cache so it's just sent once, not every page load. Also, they may have already cached it from another site, the more people who point their site to the same CDN (the page you're viewing does) the more likely this is to happen.
Google has a CDN, details here, for example from there you can grab jQuery, or jQuery UI:
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.0/jquery-ui.min.js
Previous versions of these as well
Also, Microsoft has a CDN, details here, you can fran jQuery and the validation library from it:
http://ajax.microsoft.com/ajax/jQuery/jquery-1.4.2.min.js
http://ajax.microsoft.com/ajax/jQuery.Validate/1.6/jQuery.Validate.js
Full list of validation files here
Note: these are the current versions as of the time of this answer, don't use these explicit links if you're finding this later, there may be more recent versions available.
Just reference the library from Google, chances are it will already be cached on the client...
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js">
</script>
This will also save you bandwidth. StackOverflow and many other sites do this.
Related
I read a post answer that you can do search for the code I need from an old version of jQuery and copy it and paste it into a newer version jQuery script. This way I don't have to try and have two versions of jQuery to load at the same time which was unsuccessful. Both the jQuery scripts I have are .min
How do I do this? See the person's answer below
Why would you need two jQuery libraries anyway?! Just use the newer one! ... Let's even say you needed the old one because you need some functions that aren't available in the new framework. Just look them up in search mode and copy past them one by one to the new framework (can only be done if you use jQuery offline like me, which saves loading time during developpement cause it gets cached.) P.S: I hope this doesn't cause any copyrights infrigments.
Editing jquery is very bad practice, do it only for very small projects which maintenance won't have any work with jquery or component updates at all!
Better try using Jquery Noconflict library.
I have a problem with integrating my header and footer in whmcs. Everything works perfectly. Although a strange problem came along. It has something to do with the jquery.js file in my custom layout.
when I comment out the jquery.js in my footer.tpl the dropdown menu in the header does not work on pages where whmcs generates tables. (invoices and domains)
But when I do use that jquery file the tables are still generated fine and the menus work, but then I can't order domains.
No button or text fields appear when ordering a domain.
I know this is not a good and a vague question but this has got me puzzled for quit a while now.
Anyone with who can push me in the right direction to find a solution? Or someone with a similar experience with whmcs integration?
thanks in advance!!
Not sure if you found a solution on this, but likely the culprit is one of two things:
1) The jquery library loading second is clobbering the first one so it no longer exists. To fix this you should call jQuery.noConflict(); prior to loading the second jquery library, this way the $ shortcut gets pushed over to use jQuery and frees up the $ for the new jquery. This however may become a problem if any of the javascript relies on the $ shortcut and must point to the first jQuery library, in which case all shortcuts should be renamed to jQuery.
2) The scripts executing the later jQuery library aren't compatible. This can be problematic if the versions are very different as some methods and capabilities have changed over time.
Best thing to do is always to use only one jQuery library, and use the newest one if possible. Older scripts that rely on the older jQuery should be updated if possible.
My website uses about 10 third party javascript libraries like jQuery, jQuery UI, prefixfree, a few jQuery plugins and also my own javascript code. Currently I pull the external libraries from CDNs like Google CDN and cloudflare. I was wondering what is a better approach:
Pulling the external libraries from CDNs (like I do today).
Combining all the files to a single js and a single css file and storing them locally.
Any opinions are welcome as long as they are explained.
Thanks :)
The value of a CDN lies in the likelihood of the user having already visited another site calling that same file from that CDN, and becomes increasingly valuable depending on the size of the file. The likelihood of this being the case increases with the ubiquity of the file being requested and the popularity of the CDN.
With this in mind, pulling a relatively large and popular file from a popular CDN makes absolute sense. jQuery, and, to a lesser degree, jQuery UI, fit this bill.
Meanwhile, concatenating files makes sense for smaller files which are not likely to change much — your commonly used plugins will fit this bill, but your core application-specific code probably doesn't: it might change from week to week, and if you're concatenating it with all your other files, you'd have to force the user to download everything all over again.
The HTML5 boilerplate does a pretty good job of providing a generic solution for this:
Modernizr is loaded from local in the head: it's very small and
differs quite a lot from instance to instance, so it doesn't make
sense to source it from a CDN and it won't hurt the user too much to
load it from your server. It's put in the head because CSS may be
making use of it, so you want it's effects to be known before the
body renders. Everything else goes at the bottom, to stop your
heavier scripts blocking rendering while they load and execute.
jQuery from the CDN, since almost everyone uses it and it's quite heavy. The user will probably already have this cached before they
visit your site, in which case they'll load it from cache instantly.
All your smaller 3rd party dependencies and code snippets that aren't likely to change much get concatenating into a plugins.js
file loaded from your own server. This will get cached with a
distant expiry header the first time the user visits and loaded from
cache on subsequent visits.
Your core code goes in main.js, with a closer expiry header to account for the fact that your application logic may change from
week to week or month to month. This way when you've fixe a bug or
introduced new functionality when the user visits a fortnight from
now, this can get loaded fresh while all the content above can be
brought in from cache.
For your other major libraries, you should look at them individually and ask yourself whether they should follow jQuery's lead, be loaded individually from your own server, or get concatenated. An example of how you might come to those decisions:
Angular is incredibly popular, and very large. Get it from the CDN.
Twitter Bootstrap is on a similar level of popularity, but you've got a relatively slim selection of its components, and if the user doesn't already have it it might not be worth getting them to download the full thing. Having said that, the way it fits into the rest of your code is pretty intrinsic, and you're not likely to be changing it without rebuilding the whole site — so you may want to keep it hosted locally but keep it's files separate from your main plugins.js. This way you can always update your plugins.js with Bootstrap extensions without forcing the user to download all of Bootstrap core.
But there's no imperative — your mileage may vary.
When building a jQuery plugin, do you think it's bad practice to embed the source of another plugin or library that it depends on?
It seems to me that it's a better way to go than requiring users to do multiple <script src="..."> calls or compressing the multiple source files themselves.
I would stay away from embedded in most cases, especially if you're depending on another jQuery plugin. Some cases to consider:
What if I'm already using that plugin, a newer version, an older one?
At best you're adding the download weight twice, possibly a different version
At worst you're breaking my code :)
What if I'm trying to debug, is a bug in your plugin?, the other?, still yours because you included it?
Which author do I contact?
There are few upsides to this besides saving a few <script> tags, which should be cached on the client anyway...and in my case as well as many others (like SO) the scripts get compressed into one or a few requests.
Most jQuery plugins require dependencies to be added with their own <script> tags, in this case by not going with what most do serves more to confuse or complicate rather than save time. Personally, I'd stay away from the embedding, but to each their own.
Personally, as a potential plugin user, I'd prefer the multiple <script src='...'> way. First, it gives me more flexibility and control and second, if I already have some of the plugins in my own code, having them in your plugin as well means they'll be included twice.
Imagine what would happen if every plugin author included all dependencies in the source. What you think is convenient now will turn out to be a maintenance nightmare later.
some time ago, I was reading an article(a library built by some guy) about how his library can do
lazy loading of JS
resolve dependencies between JS
(typically encountered when trying
to "include" one js from another)
include files only once. thought
specified multiple times regardless
of how they are called (either
directly specifying it as file or
specifying it as one of the
dependencies)
I forgot to bookmark it, what a mistake. Can some one point me to something which can do the above. I know DOJO and YUI library have something like this, but I am looking for something which I can use with jQuery
I am probably looking for one more feature as well.
My site has asp.net user controls
(reusable server side code snippets)
which have some JS. Some of them get
fired right away, when the page is
loading which gives a bad user
experience. Yahoo performance
guidelines specify that JS should
be at the bottom of the page, but
this is not possible in my case as
this would require me to separate the
JS and the corresponding server side
control into different files and
maintenance would be difficult. I
definitely can put a jQuery
document.ready() in my user control
JS to make sure that it fires only
after the DOM has loaded, but I am
looking for a simpler solution.
Is there anyway that I could say "begin executing any JS only after DOM has loaded" in a global way than just writing "document.ready" within every user control ?
Microsoft Research proposed a new tool called DOLOTO. It can take care of rewriting & function splitting and enable the on-demand js loading possible.
From the site..
Doloto is a system that analyzes
application workloads and
automatically performs code splitting
of existing large Web 2.0
applications. After being processed by
Doloto, an application will initially
transfer only the portion of code
necessary for application
initialization. The rest of the
application's code is replaced by
short stubs -- their actual function
code is transferred lazily in the
background or, at the latest,
on-demand on first execution.
OK I guess I found the link
[>10 years ago; now they are all broken]
http://ajaxian.com/archives/usingjs-manage-javascript-dependencies
http://www.jondavis.net/techblog/post/2008/04/Javascript-Introducing-Using-%28js%29.aspx
I also found one more, for folks who are interested in lazy loading/dynamic js dependency resolution
http://jsload.net/
About the lazy-loading scripts thingy, most libraries just adds a <script> element inside the HTML pointing to the JS file to be "included" (assynchronously), while others like DOJO, fetches it's dependencies using a XMLHttpRequest and then eval's its contents, making it work synchronously.
I've used the YUI-Loader that is pretty much simple to use and you don't need the whole library to get it working. There are other libraries that gives you just this specific funcionality, but I think YUI's is the safe choice.
About your last question, I don't think there's something like that. You would have to do it yourself, but it would be similar to using document.ready.
i did in my framework a similar thing:
i created a include_js(file); that include the js file only if it isn't included reading and executing it with a synchronous ajax call.
Simply put that code in top of the page that needs dependencies and you're done!