Performance Benchmarks of Styles 'n Scripts Extension?
Charlie Robbins
Charlie
Sean Cribbs
have that many in your page, I can believe that it's slow. Keep in mind
that anything going through Radiant has to invoke the Rails stack, which
is going to be much slower than your web server serving up a static
file, even with Radiant's caching.
However, for the case where you need a few files that are fairly small
in size, the performance should be adequate. For example, I wouldn't
store a JS (e.g. Prototype) or CSS (YUI Grids) framework in Radiant, but
I would my own customizations and application-specific behavior.
Sean
Tim Gossett
Well yes, if you have all of your JavaScript files uncompressed and you
have that many in your page, I can believe that it's slow. Keep in mind
that anything going through Radiant has to invoke the Rails stack, which
is going to be much slower than your web server serving up a static
file, even with Radiant's caching.
However, for the case where you need a few files that are fairly small
in size, the performance should be adequate. For example, I wouldn't
store a JS (e.g. Prototype) or CSS (YUI Grids) framework in Radiant, but
I would my own customizations and application-specific behavior.
Sean
Sean hit the nail on the head. You have too many individual assets managed in Radiant. First, move any static files out of the DB and into RADIANT_ROOT/public. Then, create an aggregate CSS and JS file that includes all the others you want to manage in the DB, and compress the output. (You'll need sns_minifier for that). With the aggregated output, you can keep the asset files separated, but you won't have to deal with 10 serial downloads.
Also, install Yslow for Firebug and make sure you're firing on all cylinders.
--
Tim
Daniel Collis-Puro
>
> Sean hit the nail on the head. You have too many individual assets
> managed in Radiant. First, move any static files out of the DB and
> into RADIANT_ROOT/public. Then, create an aggregate CSS and JS file
> that includes all the others you want to manage in the DB, and
> compress the output. (You'll need sns_minifier for that). With the
> aggregated output, you can keep the asset files separated, but you
> won't have to deal with 10 serial downloads.
In terms of CSS / JS aggregration, I've been meaning to fiddle around with:
http://code.google.com/p/bundle-fu/
Assuming it does what's on the can, it may be an excellent fit for a
Radiant site.
--DJCP
--
-**---****-----******-------********---------**********
Daniel Collis-Puro
Software Engineer
End Point Corp.
d...@endpoint.com
(office) 781-477-0885
**********---------********-------******-----****---**-
Charlie Robbins
1. edit my uncompressed Javascript / CSS in the Admin interface separating it out into logical files.
2. Run a "bundle" task to create a single JS and/or CSS file
3. Include that JS and/or CSS file using a simple <r:javascript:bundle /> tag
4. You could do something like <r:javascript:bundle:debug /> to use the uncompressed javascript (when debugging headaches with Firebug or something like that).
I'm currently in the process of converting Scribbish to a Radiant theme, but when I get some spare cycles, I will definitely continue on this one. Thanks again
Charlie
Jim Gay
Charlie Robbins
My tests were against putting all of my CSS / JS in SnS vs. Static Files served below the Rails/Radiant stack (straight from Apache). I was running all of my tests in production mode and I saw similar performance across all the tests. It's interesting that you mention the cache mechanism. I figured something like that was happening, especially since SnS creates a text_asset_cachedirectory on installation. The conclusion reached regarding the relative slowdown was that since the Rails stack had to resolve the route for each JS/CSS file before serving the static cached file it would take a bit longer.
It's my understanding that cramming all the files into one file means that I'm only hitting the stack once and thus mitigating this issue. Seems like an interesting approach to solve the problem. I haven't seen any feedback from Chris on this, but I'd be interested to learn more about the inner workings of this extension to refine my benchmarks.
Charlie
Jim Gay
Chris Parrish
working through the 400+ posts that happened while I was away -- serves
me right, I guess).
I don't know how far you got Charlie and if you still need any help
here, but I thought I'd document your options from fastest to slowest
for everyone to see:
1. Merge all your JS/CSS files into a single js and css files and
upload those to your server. That way
apache/litespeed/insert-your-server-here can grab those files
without invoking radiant, rails, or ruby.
Upside - Minimizes latency of multiple file downloads, server-only
response times (no rails involvement -- very fast), makes use of
the user's browser caching so that future downloads aren't necessary.
Downside - Management (you need a process to merge changes from
your sub files), ftp uploading (kind of goes against the point of
using Radiant), your server must be configured properly
(mime-types, response to Last-Modified -- in most cases this will
be correct by default, though).
2. No merged master file. Just upload your individual files to your
server.
Upside - Fast (no ruby/rails/radiant intervention), takes
advantage of browser caching, no merging (easier management).
Downside - Multiple file latency penalties, you still have to
manually upload files, server configuration.
3. Use SnS to build a master.js and master.css (use your own
appropriate names). Fill these files with references to your
individual js and css files. For example, based on your initial
post, your master.js file's content would look like:
<r:javascript name="AC_RunActiveContent.js">
<r:javascript name="preload.js">
<r:javascript name="extras.js">
<r:javascript name="mootools.js">
<r:javascript name="moodalbox.js">
<r:javascript name="portfolioBox.js">
<r:javascript name="dom-drag.js">
<r:javascript name="scroller.js">
<r:javascript name="flexcroll.js">
Using these tags would merge the content from each js file into
master.js (of course you need to go and create each of these
referenced js files using SnS too). So, like approach #1,you'd
just reference "master.js" in your layout instead of all the
sub-files.
Upside - easy maintenance (no process to continually merges
changes to sub-files), fast performance (no db hits once cached),
takes advantage of browser caching, editable via Radiant with
designer-level permissions), no latency penalty for multiple requests.
Downside - invokes rails and radiant to read the cached file so
not as fast as a plain ol' server fetch, and the first request
after a change will be responded to at uncached speed.
4. Use SnS to just create all of your individual js and css files
(without any master file). This is essentially what you were using
in your initial post.
Upside - Same as above (perhaps also a more familiar route for
developers?).
Downside - You add the latency of multiple server requests -- one
for each file -- to the above approach so it will be slower.
5. Use the traditional way of building stylesheets and scripts using
standard Radiant pages. Each file gets its own page.
Upside - No extensions to install, no server config requirements,
easy management (as opposed to #1 & #2)
Downside - Slowest (your scripts and stylesheets expire every 5
minutes and once they do, a new request will invoke db hits --
that's where the real time penalty comes in), does not take
advantage of browser caching -- forcing frequent re-downloading
(to me this is the biggest deal of all -- its bad enough for your
scripts to load slower, but to force your users to re-download
them every 5 minutes is harsh).
Additional Thoughts:
* None of these options account for minification or compression.
You could add either or both to any approach to further improve
speed (for best results combine minification with server side gzip
compression). Of course the gzip will depend on your server foo,
but there are plenty of minification tools (including my
sns_minify extension -- with method #3, for example, you could
just minify the output of master.js).
* Charlie, I can't say that I follow which images are which in your
initial analysis but I'm fairly certain that none of your analysis
accounts for the client side caching (nor should it since you were
comparing SnS with straight server responses). But for other
readers who might be looking at all this for the first time, all
of your data really applies to that initial request from a new
user. Once the files are cached, however, subsequent request
response times should improve dramatically (that's where I see
SnS's biggest strength). Bear in mind that this would *not* be
true for approach #5 as Radiant will force the user's cache to
expire within 5 minutes.
* Both SnS and Radiant use the same caching mechanism (SnS just
rightly knows the true Last-Modified date). So if the file is not
yet cached (or has changed or expired), the first request will
take much longer while radiant hits the db and generates the
cached file anew. After that, all other requests will serve up
the cached page which is a much faster process (until it changes,
expires again, etc).
* Depending on your server performance, rails setup, and how many
javascript or css files are involved, it's technically possible
that approach #3 could be faster than #2 (but in most cases it
probably won't even come close). Where you'd most likely see this
occur would be in requests after the user's browser has cached
everything (using the initial example, approach #2 would request 9
js files and 5 css files and then wait for each response stating
"nothing has changed", while in approach #3 the server would only
have to wait on 2 requests). We're *really* splitting hairs here,
though.
And trying to beat Mohit to the punch... Yes all this belongs in the
documentation somewhere. ;-)
-Chris
>>> <http://quotedprintable.com/pages/scribbish>to a Radiant theme,
>>> d...@endpoint.com <mailto:d...@endpoint.com>
>>> (office) 781-477-0885
>>> **********---------********-------******-----****---**-
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
> >
Jim Gay
> documentation somewhere. ;-)
With minimal changes for Markdown you could place that in a
HELP.markdown file in SnS and anyone with Help installed can read it
as they work on their sites.
-Jim