HEADSmart
Handling CSS and JS more efficiently.
Created by: lugie, Last modification: 15 Dec 2006 (09:34 UTC)
If one were to look into his default-generated tag, he would find numerous calls to CSS and JavaScript cluttering up and hindering the overall performance of his site. No site is fast enough, in my opinion, so i pondered up a solution to cure the HTTP-request clutter. I call it HEADSmart.
Each package would then need a stylesheet associated with it, featuring all the various styling it depends on. Upon a call to our master PHP-driven CSS file, the appropriate styling is retrieved based on the conditions of the user. Of course, this would include the requested page's associated package.
For example, a user requesting the FisheyePackage index page will call a single PHP script for stylesheet information. The PHP script for the stylesheet would grab all the necessary files or data to import. Whether it be stored flat-file or on the database I wouldn't know, but everything is called including the "base" stylesheet, the selected stylesheet for the theme, the layout-gala stylesheet, and anything else which could manage to weasel itself out of inclusion. All definitions can then be parsed into acceptible data which browsers will accept as CSS, and the generated code cleaned up as quickly as possible.
Likewise, a single script for JavaScript functions would be called, including browser fixes/stylehacks, etc. Send me a message if you feel like helping in any way.
The Theory
Sending one large file has advantages over sending many tiny ones. To achieve a singular CSS file, we can use a PHP file in place of our static CSS. This enables us conditionally parse requested stylesheet information into our document, cache it, and relay it back to the browser.Each package would then need a stylesheet associated with it, featuring all the various styling it depends on. Upon a call to our master PHP-driven CSS file, the appropriate styling is retrieved based on the conditions of the user. Of course, this would include the requested page's associated package.
For example, a user requesting the FisheyePackage index page will call a single PHP script for stylesheet information. The PHP script for the stylesheet would grab all the necessary files or data to import. Whether it be stored flat-file or on the database I wouldn't know, but everything is called including the "base" stylesheet, the selected stylesheet for the theme, the layout-gala stylesheet, and anything else which could manage to weasel itself out of inclusion. All definitions can then be parsed into acceptible data which browsers will accept as CSS, and the generated code cleaned up as quickly as possible.
Likewise, a single script for JavaScript functions would be called, including browser fixes/stylehacks, etc. Send me a message if you feel like helping in any way.
Advantages
There are many!- HTTP Request count is lowered, saving page load time.
- Wrapping CSS in a PHP container gives us the ability to interact with stylesheet information in very convenient ways. In particular, it opens a gateway for simplified user/admin font and color styling.
- Overall filesize is decreased by setting up numerous conditions of CSS inclusion.
- Further reduction in size by trimming all comments and whitespace.
- Package development now has an "in" with styling. For instance, packages with special drag-drop things can shove the container styling only into those pages for which it is requested. Of course, standards would need to be implemented which encurage simple positioning and recycling of "base.css" as much as possible.
Disadvantages
- Checking for the existence of a cached file, and of course generating the cached file would take time when requested. Some amount of research would have to be done to ensure this would actually improve upon times we see with bitweaver currently.
- In order for the data returned to truly reduce in size, the CSS parser would need to check for and remove duplicate and redundant code. This may sound simpler than it is.
Comments
neat idea
static css and js file can be larger then PHP-generated, but it loads only once in a while, when generated file will have to be loaded every pageview.
stripping the witespase and comments, and possibly packing with js is the simpliest and non-questionable start. another good thing is that it's already implemented towards js in HEAD release