1

I'm using bits of javascript on my website for an image gallery, smooth scrolling, etc. These scripts are not used on every page (not every page has an image gallery for example). However, the scripts aren't very big and most users will have to download them eventually (the image gallery is very central to the website).

Now what would be the pros and cons of these two (mutually exclusive) ways of including the scripts:

  • add them to every page (so that they'll all be cached after one page view)
  • add them only on the pages on which they are used (so they're cached only when they're needed, but some pages will take a little longer)?

I'm not asking for opinions, I'd just like to know if there are any pros and cons I've overlooked.

Improve this question

3 Answers 3

Reset to default
2

I do not know what considerations you have made. My recommend would be that you load into each page only what you need to load that page. And then lazy load everything. Make the lazy loading something you can switch on and off easily.

This will make initial page load as fast as possible on the first page you encounter. The lazy loading will speed up the second page load. And you can QA with lazy loading off to be sure that everything that is needed for a page is actually loaded. (Else it would be easy to miss the fact that a user could get JavaScript errors because they are trying to interact with something that hits a library that isn't there yet.)

Improve this answer
5
  • That is a good idea, I hadn't even thought of lazy loading (it's the perfect compromise). I've looked around and found lazyload.js. However, can I just let lazyload.js try to load all the scripts used on the entire site, and let the browser decide if it is already in the cache or not? That way I could include any crucial scripts in the head and the rest will be lazy loaded by lazyload.js. That saves me from having to do any further testing in js (and I'm willing to accept the overhead of a couple of extra requests being made). Would that work?
    – user73454
    Commented Aug 11, 2013 at 20:21
  • Depending on your application, lazy load can make it really slow.
    – Florian Margaine
    Commented Aug 11, 2013 at 21:08
  • @FlorianMargaine, in what use cases would lazy loading make things slower?
    – user73454
    Commented Aug 11, 2013 at 21:16
  • @Samuel It is all about user perceptions of speed. If the application is not usable until after unnecessary things are loaded, then your application will be perceived as slow. But if your application is loaded and working it will be perceived as responsive even if you're preloading more stuff in the background.
    – btilly
    Commented Aug 11, 2013 at 21:18
  • This is why I recommended not doing the general lazy load until after everything used on page is loaded. Even if some of the interactive stuff is lazy loaded, it should be lazy loaded ahead of stuff which is just being loaded to fill a cache.
    – btilly
    Commented Aug 11, 2013 at 21:22
1

If they're a bunch of small scripts, just roll them into one. Loading a few small files is slower than loading one file with equal size. The sum of size of all the files might be even smaller if they're compressed (i.e. by the http server). It's easier for both the server and the clients to use one file.

Another consideration is, sometimes we put random bits in script file name so browsers see it as a different file from the cached one. Having one file makes it easier to manage this too.

Improve this answer
-2

Another consideration is maintenance. If you have code in 10 files, that's 10 files you have to check in order to make one change.

Re lazyloading: that's an extra file that has to be loaded (the jquery plug-in)? How big? Why would you want to add code that probably isn't necessary. For example, you could pre-load the first 5-6 images with your HTML, then include the rest once the page has loaded/rendered.

If you're really worried about load times, try both...time it.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.