Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
RELEASE CANCELED (but code below) - VZippy, Vanilla Packer alternative (Occam's Razor Rules)
TomTester
New
ANNOUNCING: VZIPPY - a site speed-up alternative
I've been following the Vanilla Packer developments and made some remarks re: simplicity vs results
in this thread: A tad un-needed? # 6
Finally putting my money where my mouth is, I've developed a simple alternative that skips CSS, JSMini,
etc. and just packs all JS files into the page header, then forces GZipped page delivery to the browser.
Since PHP is not my strong suit I'd love to have it alpha-tested by some other peeps. Volunteers please
whisper your email to me in this thread and I'll send it to you (I don't want to upload it into the regular
add-on section until it's been properly vetted, no time to support it at this stage).
It works really well on my test site, reducing 244kB to a mere 44kB, and the number of connections for
that page from 24 to 10, resulting in a significant speed increase.
INSTALLATION NOTES
My VZIPPY alternative packer is easy to install (simply add a new theme VZIPPY, then copy the styles
from your vanilla install to a STYLES subfolder in the VZIPPY theme. It does not require changes to
core files, add-ons, ranking of scripts etc. etc. etc. and should be compatible with most vanilla styles.
I've found no problems with any installed extensions yet, except one (SMILE). JQMedia and JQ seem to
work just fine too. Need more variation in PHP, servers and extensions to get a better feel for problems/
issues (if any).
PS Hail to Dino for the great idea.
update: april 4, 2007
Somehow LOCAL installs seem to fail for several people, but LIVE installs work. I have to look into this.
update: april 5, 2007
I've decided to cancel public release altogether because making it work for everyone would take much
more time than I could realistically make available. Vanilla packer looks like a great alternative, more
complex than I'd like, but also better results (if saving bits is your thing).
For those interested I've included the release notes and final code below.
I've been following the Vanilla Packer developments and made some remarks re: simplicity vs results
in this thread: A tad un-needed? # 6
Finally putting my money where my mouth is, I've developed a simple alternative that skips CSS, JSMini,
etc. and just packs all JS files into the page header, then forces GZipped page delivery to the browser.
Since PHP is not my strong suit I'd love to have it alpha-tested by some other peeps. Volunteers please
whisper your email to me in this thread and I'll send it to you (I don't want to upload it into the regular
add-on section until it's been properly vetted, no time to support it at this stage).
It works really well on my test site, reducing 244kB to a mere 44kB, and the number of connections for
that page from 24 to 10, resulting in a significant speed increase.
INSTALLATION NOTES
My VZIPPY alternative packer is easy to install (simply add a new theme VZIPPY, then copy the styles
from your vanilla install to a STYLES subfolder in the VZIPPY theme. It does not require changes to
core files, add-ons, ranking of scripts etc. etc. etc. and should be compatible with most vanilla styles.
I've found no problems with any installed extensions yet, except one (SMILE). JQMedia and JQ seem to
work just fine too. Need more variation in PHP, servers and extensions to get a better feel for problems/
issues (if any).
PS Hail to Dino for the great idea.
update: april 4, 2007
Somehow LOCAL installs seem to fail for several people, but LIVE installs work. I have to look into this.
update: april 5, 2007
I've decided to cancel public release altogether because making it work for everyone would take much
more time than I could realistically make available. Vanilla packer looks like a great alternative, more
complex than I'd like, but also better results (if saving bits is your thing).
For those interested I've included the release notes and final code below.
0
This discussion has been closed.
Comments
I will but it on the testing forum.
Also, I suppose you parse the css files to change the relative path. I would be interested to add to the packer.
Also, I suppose you parse the css files to change the relative path. I would be interested to add to the packer.
I actually do not parse *anything* and *ignore* CSS at the moment (after encountering some annoying
issues like MEDIA=, external CSS calls, etc. etc. I gave up on that). I have some small enhancements
planned though (* see below).
My solution is the simplest 60-80% solution really. My goal was maximum effect with minimal effort/
change. I wanted something that was simple to install, simple to maintain, and required no changes
to core files, CSS, add-ons etc.
I've thus foregone anything as complex as parsing, or even caching(*) and just modified the default
theme's HEAD.PHP AddScript code to insert the full Javascript into the file, exactly where Vanilla
would insert it, i.e. where the links to the external files used to be, and then force GZIP on the end
result.
Since Vanilla reverts to default theme PHP if files are missing from the theme, all I needed to do to
install the new 'head.php' code is create a new theme with one file (HEAD.PHP), and installation requires
adding that the VZIPPY and copy at least one style (or all) from the default vanilla theme into a subfolder
(you could also replace the default vanilla HEAD.PHP but that touches core code, which I want to avoid)
I do NOT change or add any CSS etc. which helps keeping things compatible (I anticipate it's compatible
with most existing styles based on the default Vanilla theme because things are kept simple).
The only issue I've encountered with JS is add-ons that use dynamic JS includes (e.g. SMILE add-on).
As you've noticed the another big culprit/problem is our good friend scriptaculous. Instead of keeping
things smart, I just acted dumb and force included all scriptaculous components into the file as opposed
to any type of smart linking, as soon as I encountered the scriptaculous reference.
Gzip compression does the rest, don't see much need for any kind of minifying to squeeze out the last
few bits, or combining CSS files on-the-fly (better include one fewer graphic in your template or post).
TT
(*) P, some planned additions:
(#1) Add forced compression on the CSS files as well, by substituting a PHP link for the CSS file,
(e.g. global.css.php) and simply pipe the original CSS through a compression stage (but add
a CSS mime type header) to reduce bandwidth
(#2) Experiment to reduce the number of connections by merging the default vanilla libraries into
one package on-the-fly (known entities, so easy to check for conflicts) and including only CSS
styles from add-ons dynamically.
(#3) Experiment to see if caching the JS files into one BIG external JS file (packages, like yours),
again force-compressed, to see if it offers significant benefits over the present 'include into
the main HTML and compress he whole darn thing' method. It will have some effect, but
perhaps not worth it for most pages (caching -> problems).
TT.
What's your impression (speed vs complexity/compatibility)?
Compression results (via http://www.whatsmyip.org/mod_gzip_test/):
vzippy - http://vzippy.edinet.co.uk/
vpacker - http://www.edinet.co.uk/
normal - http://test.edinet.co.uk/
Look at this comparison (not sure if it's trustworthy):
http://www.iwebtool.com/speed_test 1 and the other way around (in case there's any caching on that test server)
http://www.iwebtool.com/speed_test 2
Shows that vzippy is bigger but still faster? Is this a fair comparison, i.e. did you install the same set of
extensions in the vzippy forum (so we can actually compare speed gain vs overhead?)
ADDED #1:
Ignore that speed test, it is flaky... sometimes VZIPPY beats VPACKER and sometimes the other way around.
Does anyone have a better speed test method? (firebug is not an alternative either due to local caching)
Found this one (shows connections, but very little on actual timing)
vzippy: http://www.websiteoptimization.com/services/analyze/wso.php?url=http://vzippy.edinet.co.uk/
vpacker: http://www.websiteoptimization.com/services/analyze/wso.php?url=http://www.edinet.co.uk/
normal: http://www.websiteoptimization.com/services/analyze/wso.php?url=http://test.edinet.co.uk/
Perhaps that may explain why vzippy almost matches vpacker (theoretically it shouldn't,
I think, unless the CSS packing process is somehow very slow/resource intensive).
is a different story... so I've limited myself to JS only (whereas Dino attacks the whole header).
VZippy and VPacker are very similar. Dino's approach is way more advanced, but IMHO also way
more complex and as my experience teaches me, complexity -> problems.
JS
So I've picked the simpler subset of packing only JS files *INTO* the HTML/PHP file header, which
is rarely a problem because order does not really matter. The main issue is that SOME of 'smart'
JS libraries (like scriptaculous) dynamically 'link' custom modules on-the-fly...
CSS
CSS is a different story because it's cascading (i.e. later definitions override earlier definitions) so
the order in which CSS files are included actually matters.
Moreover, one can define different CSS files for different media (e.g. SCREEN, PRINT vs HANDHELD,
etc.). Your browser will include/load only the CSS file that applies to the current task/media at hand,
but the packer cannot guess what the user is doing at the moment, so it would have no other choice
but to merge/pack ALL CSS files. This increases the total size *plus* the media issue required would
requires modification of the CSS code using @MEDIA etc. to ensure it continues to function as planned
(either by the add-on developer or on-the-fly by the packer).
On-the-fly modification requires the packer add-on to parse/understand the intricacies of each CSS
file to avoid incompatibilities. I'm too dumb for that, and the advantage seems limited, so I've skipped
dealing with CSS altogether. I think VPacker is actually encountering some of those issues right now...
In short:... VZIPPY does NOT get the maximum gain possible, but remains easy to install and I expect
it's a little more compatible with existing themes, add-ons etc. I'll look into some of other optimization
over the next week, and if no serious errors occur, I will release VZippy to the community at large.
Cheerio,
TT
the VZippy site and category overview doesn't seem to work.
Dino, did you install 'vanilla bling' perhaps so I can install the same add-ons and figure out what's
happening? (I've had problems with the SMILE add-on only thus far)
Thanks for the pimped add-on, but it does not work for me (can't get past the first screen, think I need to be logged in?)
EDIT: removed path details at Dino's request
I see the approach that you're taking - including all JS in the PHP file, so no separate server requests - the Google approach if you will, I'm just not sure it makes sense for a forum
e.g. a dynamically loaded JS file. Unfortunately Vanilla/PHP isn't easy to debug remotely without
access to the server's PHP/Apache error logs (if you do, please send met the error message).
Anyway, I'm merely a PHP noob, the quick and dirty code meant to prove that SIMPLE actions
can make a big difference... (as it does on the vzippy site dino put up).
Looking at Dino's code, I could probably demonstrate the same thing by disabling his CSS packing
code, JSMini & dynamic caching altogether... (and note how many of the issues in the vpacker
discussion topic disappear)