HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.

RELEASE CANCELED (but code below) - VZippy, Vanilla Packer alternative (Occam's Razor Rules)

TomTesterTomTester New
edited April 2007 in Vanilla 1.0 Help
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.
«1

Comments

  • edited April 2007
    You can send one at dinoboff at hotmail dot com

    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.
  • TomTesterTomTester New
    edited March 2007
    Hey Dino, the archive is on its way.
    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.
  • edited April 2007
    You can check it out at http://vzippy.edinet.co.uk/
  • TomTesterTomTester New
    edited April 2007
    Thanks Dino.

    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/
  • I didn't install yet the addons on the 3 forum. Only the one with the Vanlilla packer has them (to test incompatibility). Let me install the addons.
  • TomTesterTomTester New
    edited April 2007
    Great, thanks.

    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).
  • what about the simplest of solutions (taking the number of connections vs size as the primary problem): use the php include function and treat css and js files as php files. this will result in just one connection for html, css and js and if u want you can add zip on that and vola, I suspect easy and fast gain..
  • You can't do that for css because of the relative path of css image, and because for people with a 56k connection that would make make the page very slow to download.
  • WebSiteAnalyzer doesn't download the gzip version of my css and js files, and doesn't see the css image files.
  • @dinoboff couldnt you combine all css from one folder into one css file though? then you would at least only have 1 connection for html and js and 1 for css and possibly 1 more for a style..
  • it is what i do in the Vanilla Packer.
  • TomTesterTomTester New
    edited April 2007
    Actually Mr. Do, this is also what I do in VZippy, but... as Dino points out, and I've found out, CSS
    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
  • TomTesterTomTester New
    edited April 2007
    PS, so much for my compatibility 'blah' Dino added all extensions he had on his vpacker test site to
    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)
  • edited April 2007
    I didn't installed category overview. http://vzippy.edinet.co.uk/?PostBackAction=Pimped
  • TomTesterTomTester New
    edited April 2007
    Sorry, I was referring to the category TAB.

    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?)
  • edited April 2007
    yep, you need I think (everybody can register).
  • TomTesterTomTester New
    edited April 2007
    @Dino, when I'm not logged in on the vzippy or vpacker test sites the categories tab shows error message (which does not occur when I am logged in):

    EDIT: removed path details at Dino's request
  • I haven't fix it but, the message shouldn't appear anymore
  • Hmm, tried this but just got a completely blank browser window :/

    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 :/ Seems Dinoboff got it working pretty damn nicely though, so great work Tom :)
  • I've experienced the same issue with the SMILE add-on. More than likely this is a plugin-issue,
    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)
This discussion has been closed.