I stumbled across Closure earlier today & it occurred to me that I should be able to run the larger drupal JS files through http://closure-compiler.appspot.com/home and have them run more efficiently.

I was going to just do this with Apache, but then remembered that that wouldn't affect the pages if caching was enabled.

I'd rather not insert compressed versions of libraries in core, but realized that Closure was making 5-60% savings on files that were already compressed by Drupal.

There's got to be a way to make better use of this tool to integrate with Drupal sites. Certainly for the bigger 5 or so javascript files.

Comments

pounard’s picture

pounard
Primary language French
commented

Seems a nice idea! I'd try to see how to figure out a proper way to use it.
This is also a good argument for making a core CSS/JS handling mecanism fully pluggable, you shoud probably tell about this idea somewhere like there:
http://drupal.org/node/1014086

pounard’s picture

pounard
Primary language French
commented
Assigned: Unassigned » pounard
mgifford’s picture

mgifford
he/him
Primary language English
commented

For me this all came from reflecting on how to leverage the http://code.google.com/apis/libraries/ better.

I came to this from:
http://encosia.com/2008/12/10/3-reasons-why-you-should-let-google-host-j...

It seemed like an easy thing to implement, but it hasn't been so far.

There are a lot of JS files being added and Drupal's being constructed with lots of good line docs. Great for programmers, but it does increase load times.

I'll post a note to #1014086: Stampedes and cold cache performance issues with css/js aggregation - thanks!

mfer’s picture

mfer commented

A couple things to consider. First, jQuery as shipped with D7 already minified with closure compiler. The newer versions of jQuery use UglifyJS which produces smaller files (unless you are using the advanced features in closure compiler that strip our parts of the file). No need to minify there.

Closure Compiler takes time to minify a file. You can often measure this time in seconds which is too slow to pass through at generation time.

There's an issue to make the JS/CSS processing pluggable right now.

When it comes to minifying we need to be careful when automating it. For example, we want to strip comments but not the license comments (these need to be there). Closure Compiler has a way for handling comments you don't strip. But, there are a lot of libs that don't do this. We can run into problems.

If you want to use the google ajax libraries for jquery / jquery ui just install the jquery update module and you can select to use them on the performance settings. There is even a fallback to local files if the cdn is not available as some companies and countries block them.

How we minify our files is not a simple thing. There are a lot of complexities. For example, what happens when JS extends jQuery in a custom manner and only provides something minified. What are the licensing issues? I know of at least one company currently concerned with this very issue.

mgifford’s picture

mgifford
he/him
Primary language English
commented

Thanks @mfer - I hadn't heard of UglifyJS before Looks simple enough to use http://marijnhaverbeke.nl/uglifyjs

Automatically passing scripts through a tool like Compiler is an interesting concept, but it really wouldn't need to be done all that often. I was simply thinking of doing it manually for the larger files, but certainly if it could be done with cron in the background that would be better.

Good point about the licensing comments. I've been concerned about using http://drupal.org/project/jquery_update becauseI really don't need the latest version of jQuery. I'm worried that this will add new complexities that I don't want to deal with. I just want it from a different source.

Adding this in a module is the approach I'm playing with now which seems to work fine for now:

  if (isset($javascript['misc/jquery.js'])) {
    $javascript['misc/jquery.js'] = array(
            'group' => '-100',
            'weight' => '-19.997',
            'version' => '1.4.4',
            'every_page' => 1,
            'type' => 'external',
            'scope' => 'header',
            'cache' => 0,
            'preprocess' => 1,
            'data' => 'https://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js',
    );
  }

  if(isset($javascript['misc/ui/jquery.ui.core.min.js'])) {
    $javascript['misc/ui/jquery.ui.core.min.js'] = array(
            'group' => '-100',
            'weight' => '-10.989',
            'version' => '1.8.7',
            'every_page' => 1,
            'type' => 'external',
            'scope' => header,
            'cache' => 0,
            'preprocess' => 1,
            'data' => 'https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.7/jquery-ui.min.js',
    );
  }

I hadn't thought about using a fallback to local files. That's a neat option.How that would work with caching is another issue.

The licensing issues can be a pain. Our work is GPL which simplifies things a bit, but still.

mfer’s picture

mfer commented

A backup to a local version of jquery is something that's all on the front end. works with caching. for example:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="/path/to/jquery-1.4.4.min.js">\x3C/script>')</script>

If the jQuery object is not available it pulls it from a second location.

jQuery Update provides jQuery 1.5 which is API compatible with 1.4.4. Some custom scripts that do some crazy things might have problems. But, working with it day in and day out I have not run into anything. So, pulling jQuery 1.5 from Google CDN should be good.

Where are you adding your code snippet? hook_library_alter?

mgifford’s picture

mgifford
he/him
Primary language English
commented

@mfer - window.jQuery || document.write -- That's an amazing oneliner. Quite a nice solution.

Good news about jQuery Update. Sounds like it should be fine to use it. The site's already running HTML5 & CSS3 with ARIA, so why not through jQuery 1.5 at it and see what happens :) -- Sounds like if the API is compatible we should be able to work with it.

And ya, sorry, the code snippet was just added in function MY_MODULE_js_alter(&$javascript) - I should have included that when pasting in the code.

I hadn't actually stumbled over http://api.drupal.org/api/drupal/modules--system--system.api.php/functio...

pounard’s picture

pounard
Primary language French
commented
Status: Active » Closed (won't fix)

Following the core discussion about this topic, it seems that kind of support is not mine to do, not right now. I close this issue as won't fix. I may reopen it later, I really don't know. This thread should definitely continue on core issues, not here.