jFinalizer joomla plugindocumentation, how-to and support
Releases & download: v1.0.11for joomla 1.5.10+, PHP5
right click, copy URL and paste into joomla for installing by URL. Otherwise, just download the plugin and upload manually. See changelog. License: GPL, no registration required, free of charge. Component developers please see the tech notes. Please bugreport to This e-mail address is being protected from spambots. You need JavaScript enabled to view it or feel free to leave bug reports and comments below Warning: Do not install jFinalizer on PHP 4!
OverviewUse jFinalizer if you want to reduce HTTP requests to site, reduce traffic, speed up page loading or decrease HTML page size if you have big templates. On big templates, you can gain 10+ YSlow points, sometimes more than 20. There are many other libraries which do similar things, but we built and run jFinalizer because most of the templates we used would not work with other plugins. Key Features:
Do not use jFinalizer if you want the last bit of compression. Its designed for runtime performance, not for super-high compression. Do not use jFinalizer if you have components, extensions or templates which generate dynamic CSS on the fly (no - you usually don't have that, even on complex templates). Do not expect jFinalizer to work out of the box. Default settings are compatible for most sites, but tuning HTML output is a tricky task and highly depends on your template, CSS, Java Script, components, plugins and modules. Give yourself 10 minutes to get this plugin configured properly. DemoSimply right click and view the source of this page or view the source code of our corporate main site www.farbfinal.de to see what jFinalizer does. Actually, both use the same joomla! installation but different templates. DescriptionThe idea of jFinalizer is to replace tons of JS and CSS files with a single CSS and JS file. This is done by processing the final joomla output HTML. Additionally, you can compact & compress a few things and make your HTML look more compact. jFinalizer uses another approach than most libraries we've found: It does not do anything to CSS, HTML and JS code except for stripping whitespaces and stuff which is not needed. The plugin merges all CSS and JS files used in a page into a single file, preventing the loading order of the html source. Note that only CSS and JS files within the region are processed. We've found that processing body CSS and JS usually harms on complex templates. jFinalizer is designed for live performance. This requires a bit more tuning on the developer side, but reduces runtime CPU usage at runtime a lot. jFinalizer has its name not only because our company is called farbfinal, but also because its usually the last plugin in the system chain and finalizes your output. Your goal is to develop your site, then turn on jFinalizer and see what happens. If your code is clean, you're on the way to go. Even though joomla! is a great CMS, it has a few drawbacks. Joomla's flexibility is awesome, but at the same time it introduces a lot of file I/O on the application server. jFinalizer can help a little to improve that. It does not check for updated CSS or JS files since the developer knows anyway when design is changed. Imagine you have a template with 9 CSS and 7 JavaScript file includes. Makes 16 all together. jFinalizer reduces it to 2 (see limitations). This reduces Server file I/O. Since jFinalizer does not check the modified date of the source files, 14 file system calls are saved. Limitations
PerformanceIn Production mode, the plugin performs quite well and does not consume a lot of CPU. For performance analysis and before / after comparison, please use external tools such as YSlow (FF Plugin). Since jFinalizer is a system plugin we want to keep it slim, there are only a very few analyis options build into plugin (see configuration). Installation Workflow1. install the plugin and set it to plugin order "last" Tip: Whenever you change a CSS or JS file later or install new joomla! components / plugins, turn jFinalizer into Development Site Mode and check life site again. Tip: While configuring, do one thing at a time. If you want HTML compression, start there and disable all CSS / JS processing. See HTML setup guide Don't give up tuning to fast. Allow yourself 10 minutes to get it working properly. If there is no combination to get your template working, this plugin is probably not for you. Try a different approach like CssJsCompress or JACompress. When installing a jFinalizer upgrade, simply install it. The plugin does not need to be uninstalled before. Configuration TipsIf your site does not work properly, your goal is to turn jFinalizer off, see your HTML source code, then turn the plugin on, reload, see your source code again and compare. First steps for setup could include this procedure:
Tip: Any Compacting can break layout. If your server supports runtime gZip compression, thats probably not a big deal and you can turn it off Tip: if your site uses many joomla components, make sure to also check the pages where they appear! For example, you could get a perfect layout and performance with HTML compression set to ultra, but some poorly coded component might break it or not work as expected. Tip: If HTML compression is what you want most, work the other way around. Disable CSS and JS processing first, enable HTML processing and be sure to try all available modes! If you have the system.cache plugin enabled, disable it while tuning. Try to start with Safe Mode C. Read the HTML Setup Guide. To see an example, right click and look at the source code of this page. Farbfinal.de is run against jFinalizer with HTML processing mode set to fast using moderate compression and check contitional exceptions, JS on and optimize, CSS on and optimize, remove comments and deliver using gzip htaccess. Warning: do not use Tidy HTML compression mode on production sites. This option is available for your personal debugging / designing workflow only and will almost certainly break design, slow your site down and make it unusable. Setup Guide: HTML compressionHTML processing is the most tricky part. Stick on this workflow to get it working. Be sure your browser reloads properly and dont try to get CSS / JS aggregation to work before HTML processing if you want both.
Tip: for bypassing HTML processing for only a specific block of Text or content plugin, wrap it with My bypassed content goes here in the article editor. Setup Guide: CSS / JS processingIf you dont want HTML output processing, try this workflow to setup CSS / JS processing properly. This may help to to get your site working a bit faster.
Setup Guide: use both togetherSee instructions above. Be sure to first get HTML compression working properly at first, then start CSS / JS file processing - not the other way arround! Optionsthe default configuration should work for most installations:
Site ModeYour most important switch while tuning and developing. Controls how jFinalizer handles its internal cache. Yes, you want cache! The cache system on jFinalizer operates independent of all joomla! cache settings, because its always content independent. Caching in jFinalizer means that JS and CSS files are stored to disk and not re-processed on every page load. HTML output is never cached by jFinalizer. Using jFinalizer without cache does not make sense because you would decrease HTTP requests but at the same time increase execution. While developing design (CSS) or functionality (JS) you want to turn Site mode into development. When your site is up, fixed, steady and running - go for production. Note: development mode reduces performance big time - your site will slow down drastically. Tip: while in designing layout in development mode, disable JavaScript & CSS compacting
process HTMLProcess joomla! output HTML and compact it. On an average Template, you save 5-30% Bytes. For Developers, there is a Tidy option included which beautifies output. Tidy breaks layout in many cases. Note that Tidy must be enabled on your server if you want that option. The fast option uses quick built in routines and strips unused stuff with different compression levels. It does not take care of the last saved byte, but its very fast and recommended for live sites. See compression level for more info. Tip: while tuning the plugin, turn on process HTML and then check different compression levels to see which ones work for your template. Please not that HTML compression might not work on all templates and can break design.
compression levelSets the compression level of HTML output. Only active if process HTML is set to fast. Depending on how clean your template is, you can reach different compression levels. Compression levels also affect CPU usage on the server side a bit. Please note that the most efficient and fastest mode is ultra, but unless your template is super-clean, ultra mode will probably break your layouts. All modes try to remove as many white spaces as possible. Ultra also removes all line breaks. The difference in the operating modes is how deep the plugin digs and how much whitespace is removed. Some modes do additional checking to prevent design breaks. Please try and see which option works best for your template. The different options are available because the idea if jFinalizer is to perform as fast as possible and do as few checks as possible at runtime.
Tip: Published starting at jFinalizer 1.0.10, Safe mode C+ seems to be most compatible. Its also the current installation default setting jFinalizer. HTML commentsKeep or remove HTML comments. It takes a bit CPU but usually is a good thing if you want to clean your output. Please note that multiline comments are always kept!
Pre Tag SupportNever touch <pre> tags. Don't remove linebreaks, whitespaces etc. This option is available on jFinalizer 1.0.11+. Useful for plugins like CodeCitation. If you know your site does not have any <pre> tags, turn it off for a tiny bit of extra performance.
Generator TagKeep or remove the joomla! generator meta tag. Can help a bit to not expose joomla. Note that there are other ways to do that but they require joomla ource code editing.
process JavaScriptDoes what it says. Process all JavaScript tags, read the files, merge them into one and cache them. Note that having external url (from another server) javascript within your <head> tag will probably break the script. All JavaScript files outside the header <head>...</head> tags are ignored.
compact JavaScriptremove whitespaces and other unused stuff from JS files. Usually saves a couple bytes. In some cases, compacting JS can break JavaSvript functionality. If thats the case, try disabling it. Performance note: compacting JavaScript files is usually the most time consuming task of jFinalizer. While this is not a problem in production (cache) mode, you might want to turn JS compacting off when in development mode.
process CSSsame thing as as process JavaScript but for CSS files compact CSSsame thing as compact JS but for CSS check conditional ExceptionsCheck it the template contains conditional <!--if... --> CSS includes for client browsers. If it does, they are ignored. The option is available because if YOU KNOW your template does not have any conditional includes, you can turn this option off and save some extra performance.
gZip outputcompress cached JS and CSS files using gZip. gZipping JS & CSS files can drastically reduce file size and download time. When run in .htaccess delivery mode, additional PHP calls are bypassed and runtime compression by the delivery server (eg. apache) is skipped. This can reduce overall load and File I/O on your server. Please note that .htaccess mode is not available on all platforms. If you run a dedicated server, this option is for you to tune the last bit. The modes explained for experts: PHP delivery: the client browser calls a PHP file which delivers the JS / CSS file dynamically and adds necessary css headers. The files are already compressed, but PHP needs to be opened and a fopen() function is involved. .htaccess delivery: a .htaccess file is placed into the delivery folder (usually /cache/assets). The web server checks if gZipped content is accepted by the client and rewrites the request file name to deliver the gzipped version. Fast, no additional PHP calls. On apache, mod_rewrite must be enabled and allow_overrides must be properly set for the cache path. If Apache is set to compress .js and / or .css files by default on the fly using DEFLATE, this will be bypassed for those files saving CPU time. To customize the content of the .htaccess file depending on your server configuration, copy the file /plugins/jfinalizer/htaccess.default.php to htaccess.custom.php and edit this file. This way, your changes remain after you upgrade jFinalizer. Note: .htaccess configuratio requires jFinalizer 1.0.4+ Please note that apache knowledge is required when editing the .htaccess file contents. The goal of the .htaccess file is to check if the client accepts compressed data, and if thats the case redirect the request to the gzipped version of CSS / JS files.
cache lifetime in sAs CSS and JS files dont change once you finished designing, cache lifetime is usually set to 0 meaning the files never expire. However, you have the option to enter an amount of seconds to force rebuilding the merged files after that period. Do not confuse "expired" here with http expiring / client cache lifetime: HTTP send Headers are not touched by jFinalizer.
debugAppend some debug info comments or show performance data Debug mode help you to see what jFinalizer does and how it performs. In html comments mode, a html comment containing the name of the removed JS / CSS files is placed into placed into output HTML source code. This can be useful if you want to see what files were merged. In full and performance mode, jFinalizer displays performance data such as total runtime of the plugin, number of merged files an HTML byte savings on top of your site. Full & performance breaks design and cookies. So don't use it on a live site - or if you do, turn it off quickly again. While tuning jFinalizer compression settings, don't run full and performance since you can't see compression design breaks.
Advanced: Place Tagswhere to place output file tags in HTML. By default (auto), the first found tag (CSS / JS) in your source template is replaced by the merged output file. However, you can optimize tag placement by manually placing tags. For example, if you have a minimal template which has not a lot of JavaScript, you could move all JavaScript from the <head> to the bottom of your body. Anyways, manual template editing is necessary. If you want to do so, call the loading event at the appropriate place within your template and then switch to manual . Usually this is the section which outputs head data. It does not matter if other CSS or JS files are loaded after manual placement. The parsing and collecting always comes later. PHP Placement code CSS: $mainframe->triggerEvent('getCompressedCSS'); ($mainframe refers to the joomla mainframe object).
Advanced: Delivery Pathdelivery output path for CSS and JS files in client HTML Now thats tricky. By changing the delivery path, you can tell the client to load the merged JS and CSS files from another source path. Its great for hiding the default joomla /cache/xxx directory. Cached files are always stored physically on disk into the joomla cache directory, subfolder /assets. So, usually thats /cache/assets. You can't change that because thats the only way to clean jFinalizer cache using the joomla builtin cache manager. Re-routing the delivery path works by placing a symlink to /cache/assets. You need shell access. Login to your server and create a softlink. For example on linux, if you want you delivery path to be example.com/inc, you would create the symlink using bash># ln -s /my/absjoomlarootpath/cache/assets /my/absjoomlarootpath/inc and then insert inc/ into the delivery Path field. Note that Apache might check symlink permissions. They need to be set correctly.
tips, tricks, troubleshooting
known issues
changelog1.0.0 Comments & Bug ReportsWhen posting a bug report or problem, don't forget to post the jFinalizer version. If you use HTML compression, tell us what Mode you use. |
Comments
- Problems compress html. The plugin is putting js in a declared CDATA and not closing this parameter correctly. This causes the extensions that use js to stop work. In my case the plugin rokbox and a module for the LiveZilla
Even so, I stopped using CssJsCompress because JFinalizer is a little more sophisticated, it provides some features (which does not work) that does not provide CssJsCompress. As the compression of html.
To solve the problems I encountered, I deactivated compression html (which was what most excited me) and put to gzip using PHP instead of htccess: (
If you resolve the problems, the plugin will most wanted genre without a doubt.
My site is the site-desenvolvimento .com.br and my personal e-mail the rdeprera@gmail.com
Also, as of release 1.0.4 we added the ability to have a custom .htaccess file for specific server configurations. I hope that can help you serving gZip using htaccess. Unfortunately, .htaccess delivery highly depends on server configuration and need almost expert apache knowledge to configure. Please see the gZip config section of this page for some more hints on how to implement.
So whoever wants to use it: Read what the developers say everywhere and consult the documentation!
Thanks for this plugin!
Ich vermisse die Möglichkeit bestimmte css und Jacscript auszuschließen.
Ich habe bei mir jomsocial und Cometchat am laufen, bei beiden werden danach die css und javascipt Dateien nicht richtig geladen.
lg
one short question. in tidy mode the charset in source code is set to "us ascii" but i need UTF8. how can i change it to the right setting?
cheers
sascha
You cannot really change this by yourself since its hardcoded. But you are right, utf8 makes more sense. Unfortunately, Tidy does not recognize the input char encoding automatically. Thanks for the hint!
Please remember to not use Tidy on production sites since it will add lots of unnecessary bytes.
Everything works really well. The only thing I had to limit was the html compression level due to a googlemap plugin (extensions.joomla.org/.../1147).
Only safe mode A worked, otherwise I believe that "if" & "else" statements in the javascript written without brackets { } break...
Safe mode C+ is almost identical to Safe Mode C but keeps a little bit more whitespaces. Its also a very efficient / fast algorithm.
Fantastic pluging !!
But i have the same problem with google-maps.
I believe this due to the fetching of js from google-server and not from local filesystem ?
Would be great if this could somehow be considered and solved in upcomming release.
thx very much
Frederik
Warning: get_class() expects parameter 1 to be object, array given in C:\wamp\www\its mypik\plugins\s ystem\jfinalize r.php on line 152
for now i have disabled the plugin .
i cant get the firststep to work lol .
forget about goin to next once X_X
Thanks for Jfinalizer. I have started to use it but got a problem that I think can have to do with Jfinalizer but not sure. I have a register page that work fine in Firefox but it doesnt work in IE 8.
travelmate.com/.../... Here is the reg form that doesnt work as it should in IE 8. Thanks!
developers.facebook.com/.../
Of course, the idea of having a "recompile joomla!" button in the backend sounds very charming :)
Great plug in! Was wondering if there were any implications with using the htaccess method if you are already using an htaccess file on a site.
Thanks again.
But please note: make sure the jFinalizer .htaccess file is compatible with the settings of your own .htaccess file. Maybe you do path overrides that need to be included.
This is how jFinalizer .htaccess works: it copies a .htaccess file into /cache/assets. Only this directory is influenced by the jFinalizer .htaccess file. However, you can edit the jFinalizer .htaccess file to your personal server needs.
Please read the gZip documentation on htaccess very carefully (especially on how to copy the file)!
So am thinking that I would have to add
AllowOverride (Path to the plug in htaccess file.
That correct?
Did you try to use htaccess delivery already out of the box of jFinalizer? What happens? For example, if you use joomla SEF URLs with mod_rewrite, everything should be correct already.
If some of your htaccess files disallow htaccess files for the /cache directory or deeper by using AllowOverride None, then you might need to change it somewhere to AllowOverride All.
A simple check to see if htaccess files work in a specific subdirectory it to place a htaccess file in there which disables total access by asking for a valid User. But before doing that, make sure you can manually delete the file again using ftp / shell access! example .htaccess file:
RewriteEngine on
AuthType Basic
require valid-user
If everything works, Apache must give you an misconfiguratio n error when you try to access this directory since no password file is found. So if you get an ERROR, you know that htaccess files WORK :)
Currently using mod rewrite with no problems. SEF urls and non www redirect as well
I'll have a look at what you're saying and let you know!
If your template totally breaks (looking like there is no css file at all), you might have to adjust the htaccess file (see gzip notes above - again).
You can check if gZipped htaccess delivery works be using firefox with the firebug plugin: If you load your site, take a look at the Network tab, locate the /cache/assets/xxxxxxxxxxxxxx.css file and see if the headers say that its compressed (gzipped).
There are several issues on customizing the htaccess file. Take a look at htaccess.default.php and understand what it does. For example, if your server compresses CSS files by default and the disable deflate switch would not work as expected, your files get double-compressed and the client cannot open it anymore.
I'm sorry we cannot really help here. But as stated above, htaccess delivery highly depends on your very specific server setup and usually needs to be adjusted, which requires a bit apache rewrite knowledge.
Interestingly enough I have it on another domain (same server) where it works fine in htaccess.
I'll have to compare the two more closely!
Wenn ich habe "protsess CSS" und "check conditional exception" umgehängt, entstandene zwei Probleme:
-"Core Designe Login" Modul arbeitet nicht so korrekt - popup Fenster ist immer vordergründig.
-im Bauteil K2 ändert Größe und Stil von Einreise.
Ich benutze in meine Seite VirtueMart Software mit VM Junction, Blade Ausstattung. Wenn ich habe "fast - builting crunch"
umgehängt, dann tab arbeitet nicht im Seite Beschreibung von Produkt.
joomla 1.5.14 - WIMP - jfinalizer last version
I have problem with process CSS: yes and gzip: PHP
jslow says me new css is
www.people4you.it/.../
but nothing in assets, the url is not correct and the file i see in jslow is like this:
[removed]
If no files are in the /cache/assets directory, it might be possible that the directory is not writeable by joomla. Could that be the case?
The URL you posted is missing slashed. They seem to be URL encoded. jFinalizer does not do that, it always uses the joomla DS constant for adding directory separators.
The plugin works on HTML and CSS but cant seem to work on IE when I enable javascript processing. From what i understand from my IE developer debugger, it seems unable to load the mootools library because it keeps on saying that the addEvent method of window doesnt exist...
solving this would really help alot.
Thanks for the plugin anyway! ;)
2. turn off CSS and HTML processing totally, just enable JS processing
3. If the error you mentioned still happens, give us another feedback.
So far, mootools loaded fine on all sites we've tried on. Maybe we need a bit more information on your issue...
to the developer: VERY GOOD JOB!
We will try to get a hold on the developers of jomsocial and see if we can grab a developer copy. Its an important component to joomla, we understand that. We really need to do tests, but as you can imagine, we just cannot buy comercial components for testing :(
We will get back on you, but it will probably take a couple days...
thank you
The only two problems I have run into so far is the issue with Googlemaps (HTML compression Safe A fixes that), and highslide.js seems to break as well.
Not bad for a plugin that does so much. Thanks again and keep working on it :)
The jQuery conflict resolver might become an option at one of the following releases.
Zipping is a different approach. By removing whitespace, the file gets more compact, its size decreases. When simply zipping a file, the client browser (or search engine) unzippes all data and the size is the same as before.
Some search engines rate a file-size-to-readable-content ratio. In this case, optimization might help a bit!
Also, most web servers gzip output anyway. So when you use jFinalizer, your compacted HTML gets gzipped before delivery. This way, you get smallest possible document size using both methods together.
fFinalizer Error: cannot write to file jFinalizer
Anyway there are a lot of things to implement - correct client side caching for assets, correct (CPU efficient!) HTML minify / comments striping, dynamic files handling. And so on. Good luck :)
Line 355: Premature end of data in tag html line 1
…r) {}
Both are not working :
tools.yootheme.com/.../...
extensions.joomla.org/.../...
Thank you for your hard and excellent work.
Can you tell us what was specifically not working for you?
RSS feed for comments to this post.