Dial-up users vs broadband users; compression trigger minimum file default/admin defined size limits.
vividgates - July 21, 2009 - 01:35
| Project: | Javascript Aggregator |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Jump to:
Description
From reading some of the issues for this module, I've found that one user disabled this module, due to the number of users his server has because it affected the performance of his site. In general, turning this module on would impact the server's ability to serve more broadband users, but this module is very helpful to dial-up users.
I request that this module detects the dial-up status of the browser of the user to turn compression on or off, and minimum settings for when this module would be used. For example, if the total aggregate js/css files is over, say a 250k default (or user defined), it would compress, if it is under the set limit, then it would not compress.
It would be a good addition to this module. Thoughts?
#1
Why would this module have such an impact on the servers performance? It minifies and gzips the javascript file (aggregated by Drupal core) and caches this file. It does this only when core aggregated a new file. NOT on every pageload.
#2
Hi derjochenmeyer,
Thanks for the response. Some servers have to deal with unique scripting requirements on a page for security, role, and versioning requirements.
I was referring to the post here which got me thinking about server load times: http://drupal.org/node/484422
This post was interesting: http://carsonified.com/blog/features/webapps/serving-javascript-fast/
Obviously caching complicates things below but how does this module aggregate external javascript from external sites? Depending on the modules that a site has, (and with upcoming drupal 7), if the modules are changed dynamically or upgraded, some of the javascript can be changed easily. It becomes a functionality vs performance tradeoff at the moment.
How does the page load for different roles and languages?
It’s a problem for dynamic websites, such as for games. Depending on the objects presented on the screen, different javascript updates can be requested depending on a user's increasing permissions on a page.
As for security, obfuscation versioning of the file name of the javascript can occur, while for businesses, timestamping of javascript file names can occur, which is in some cases is the failure to follow best practices, but giving an option to this module mitigates such concerns.
They’re all problems which add up on cpu load.
It is at least something to be aware of, and it gives an avenue for improvement for this module.
Regards,
vividgates
#3
Update!! Earlier today, I read up on: http://www.angrydonuts.com/new-panels-3-ui-screenshots
Earl's use of "variants" in the panels module, which is showing a different page to a person who has different user permissions can potentially cause js differences for a page, especially for a busy site that creates many pages.
#4
Yep... its tricky to develope a logic how to serve ONLY the right js and css files as stated in the blogpost you mentioned in #2
But thats something that Drupal Core could do. A module developer can now include his css or js files only when a certain theme functions is actually called. Or you could write a custom function that excludes certain javascripts or css files on your forntpage to speed it up.
In Drupal 7 you can choose if the js file should be aggregated or not (http://api.drupal.org/api/function/drupal_add_js/7)
But this module ONLY minifies and gzips the files in addition to the aggregation done by Drupal core.
The logic how to include or exclude files for certain pages, users, roles, etc has to be implemented at the core level and can only be managed by module developers.
On post
#484422: Performance issues?
I need more information. It seems that the jsminification done by jsmin.php takes a lot of time and memory BUT it should only run if a new file is served by drupal core the first time!
After that all the magic should be done by the generated htaccess file. Javascript Aggregator then only checks if the cached file exists. Maybe the caching of our files os buggy. Will check...