Array

I've opened the following ticket to track reducing the
bandwidth and number
of HTTP transactions required to start the Cosmo PIM. 
Owner, timing TBD.

-------- Original Message --------
Subject: [Bug 7433]  New: Compact/compile Cosmo Javascript
Date: Thu, 16 Nov 2006 13:49:19 -0800 (PST)
From: bug-commentosafoundation.org
To: jaredwordzoo.com

http://bugzilla.osafoundation.org/show_bug.cgi?id=7433

           Summary: Compact/compile Cosmo Javascript
           Product: Cosmo
           Version: 0.5
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Build
        AssignedTo: bearcode-bear.com
        ReportedBy: jaredwordzoo.com


Cosmo's UI loads quite slowly, compared to common web apps. 
There are
dozens of files used, each with lots of whitespace and
comments.  The user
experience is a blank page while Cosmo loads; generally
something like 8
seconds worth.  Not noticeable for developers accessing
localhost, very
noticeable against osaf.us, and lord help anyone who is on
dialup.

Ideal for bandwidth consumption would be to strip leading
whitespace and
comments from Javascript files during builds.  Dojo
apparently also has a
nice compilation system to create a single file with only
the components
actually used by the application; doing this would greatly
reduce the number
of HTTP transactions used and improve latency.

This ticket is to dramatically reduce the bandwidth consumed
by starting up
a new Cosmo web calendar session.

-- Jared


-- 
Configure bugmail: http://bugzilla.osafoundation.org/userprefs.cgi?tab=ema
il
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

We might want to break this in to two items. One for
reducing  
bandwidth in general, and another for reducing round trips.

The UI loading slowly I imagine is mostly do to the amount
of round  
trips not to the excess whitespace and comments. But for the
sake of  
reducing our osaf.us bandwidth bill we obviously need to be
cutting  
down on overall bandwidth usage.

-Mikeal

On Nov 16, 2006, at 1:51 PM, Jared Rhine wrote:

> I've opened the following ticket to track reducing the
bandwidth  
> and number
> of HTTP transactions required to start the Cosmo PIM. 
Owner,  
> timing TBD.
>
> -------- Original Message --------
> Subject: [Bug 7433]  New: Compact/compile Cosmo
Javascript
> Date: Thu, 16 Nov 2006 13:49:19 -0800 (PST)
> From: bug-commentosafoundation.org
> To: jaredwordzoo.com
>
> http://bugzilla.osafoundation.org/show_bug.cgi?id=7433
>
>            Summary: Compact/compile Cosmo Javascript
>            Product: Cosmo
>            Version: 0.5
>           Platform: All
>         OS/Version: Linux
>             Status: NEW
>           Severity: enhancement
>           Priority: P2
>          Component: Build
>         AssignedTo: bearcode-bear.com
>         ReportedBy: jaredwordzoo.com
>
>
> Cosmo's UI loads quite slowly, compared to common web
apps.  There are
> dozens of files used, each with lots of whitespace and
comments.   
> The user
> experience is a blank page while Cosmo loads; generally
something  
> like 8
> seconds worth.  Not noticeable for developers accessing
localhost,  
> very
> noticeable against osaf.us, and lord help anyone who is
on dialup.
>
> Ideal for bandwidth consumption would be to strip
leading  
> whitespace and
> comments from Javascript files during builds.  Dojo
apparently also  
> has a
> nice compilation system to create a single file with
only the  
> components
> actually used by the application; doing this would
greatly reduce  
> the number
> of HTTP transactions used and improve latency.
>
> This ticket is to dramatically reduce the bandwidth
consumed by  
> starting up
> a new Cosmo web calendar session.
>
> -- Jared
>
>
> -- 
> Configure bugmail: http
://bugzilla.osafoundation.org/userprefs.cgi? 
> tab=email
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

I sent this link to Travis, but it seems like other folks
might be 
interested as well. It's an article written by Cal Henderson
from Flickr 
about serving JavaScript fast -- building, caching,
compression, the 
usual suspects:

http://www.thinkvitamin.com/features/webapps
/serving-javascript-fast

And while I'm at it, here's another similar, but shorter one
on the 
Zimbra blog:

http://www.zimbra.com/blog/archives/2006/01
/zimbra_ajax_css_digg.html


Matthew


Jared Rhine wrote:
> I've opened the following ticket to track reducing the
bandwidth and number
> of HTTP transactions required to start the Cosmo PIM. 
Owner, timing TBD.
> 
> -------- Original Message --------
> Subject: [Bug 7433]  New: Compact/compile Cosmo
Javascript
> Date: Thu, 16 Nov 2006 13:49:19 -0800 (PST)
> From: bug-commentosafoundation.org
> To: jaredwordzoo.com
> 
> http://bugzilla.osafoundation.org/show_bug.cgi?id=7433
> 
>            Summary: Compact/compile Cosmo Javascript
>            Product: Cosmo
>            Version: 0.5
>           Platform: All
>         OS/Version: Linux
>             Status: NEW
>           Severity: enhancement
>           Priority: P2
>          Component: Build
>         AssignedTo: bearcode-bear.com
>         ReportedBy: jaredwordzoo.com
> 
> 
> Cosmo's UI loads quite slowly, compared to common web
apps.  There are
> dozens of files used, each with lots of whitespace and
comments.  The user
> experience is a blank page while Cosmo loads; generally
something like 8
> seconds worth.  Not noticeable for developers accessing
localhost, very
> noticeable against osaf.us, and lord help anyone who is
on dialup.
> 
> Ideal for bandwidth consumption would be to strip
leading whitespace and
> comments from Javascript files during builds.  Dojo
apparently also has a
> nice compilation system to create a single file with
only the components
> actually used by the application; doing this would
greatly reduce the number
> of HTTP transactions used and improve latency.
> 
> This ticket is to dramatically reduce the bandwidth
consumed by starting up
> a new Cosmo web calendar session.
> 
> -- Jared
> 
> 

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Mikeal Rogers wrote:
> We might want to break this in to two items. One for
reducing bandwidth
> in general, and another for reducing round trips.

"Reduce bandwidth in general" seems too general
for an actionable bug.  I
filed it as one bug with the assumption that the
implementation is just
using Dojo's magic compiler, which will both unify files and
do
whitespace/comment stripping.

Since it just got targetted for 0.6, could someone provide a
direct pointer
to this compiler?  (To understand better what it does and
how to use it)

I'd be interested to continue looking at bandwidth-specific
investigations
of all sorts.  This "compile JS" approach, if it
pans out, seems like
low-hanging fruit that will have such a dramatic impact as
to suggest it be
done first.

-- Jared
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

We've been focusing a lot of our attention on the
performance of  
Cosmo in syncing scenarios with Chandler.   This is an
important use  
case for Cosmo, but it is not the only one.  Earlier this
week, I  
logged into osaf.us to look at my calendar, and I was
surprised by  
how long it took for the UI to load.      I think that we
need to  
keep an eye on the performance of the web UI before we find
ourselves  
in a deep hole.

Good performance for the web UI is important.   Last week at
the Web  
2.0 conference, Google's VP of Consumer Products talked
about the  
impact of page load times: <http://blogs.z
dnet.com/BTL/?p=3925> and  
emphasized the importance of a highly responsive user
interface.    
There are good lessons for us in their experience.     I
have a  
friend who used to manage the AJAX group at Amazon, and he
described  
some of the crazy techniques that they are using to make
sure that  
Amazon.com is responsive.

So what to do?

Jared has a set of tests for the syncing scenarios, and is
going to  
be expanding them, and (I hope) finding away to run them in
an  
automated fashion.    I think that we need to start thinking
about  
something similar for the UI.    Another thing that we can
do is to  
understand what constitutes good performance for an
interactive  
application (web based or not).    Jakob Nielsen has written
a good  
article about response times and usability <http://www.useit.com/ 
papers/responsetime.html>.    I think that these are the
kinds of  
times that we should be striving to acheive in the  Cosmo
UI.    
Chandler's goals for UI responsiveness are taken from these
numbers  
as well.

I am not advocating premature optimization here, but I am
saying that  
performance does matter, and that we need to keep an eye on
it.    
Chandler is going to take the last release before Preview to
deal  
with performance issues.   We are not going to have that
kind of  
time, so we need to do a good job of keeping performance
reasonable  
as we go.

Thoughts?

Ted

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Here are some more details on optimizing Cosmo JS/CSS for
speedy delivery:

1. Compiling

The 'compiling' process is basically just to concat the JS
script files 
together.  Dojo
however is apparently working on a much more 
sophisticated JavaScript Linker which slices, dices, shines
your shoes, 
etc.:

http://blog.dojotoolkit.org/2006/08/30/js-linker-in-dojo


2. Compression

These are the two most commmon compression utilities you see
used to 
reduce JS file size:

ShrinkSafe

http://alex.d
ojotoolkit.org/shrinksafe/

JSMin

http:/
/www.crockford.com/javascript/jsmin.html

3. HTML template files

We also have Dojo widget HTML template files that need to be
sucked up, 
transformed into JS string variables, and shoved into the
accompanying 
widget JS file -- otherwise you're making another connection
just to 
pull in some scraps of HTML.

4. CSS files

Right now we are using a client-side 'dynamic CSS' approach
which has 
everything in a single file, but requires processing on the
browser and 
does some basic variable substitution. If we identify that
dynamic CSS 
process as being a page-load bottleneck, we can pre-process
that file 
too as part of a build into a static file for the production
environment.


Matthew


Jared Rhine wrote:
> Mikeal Rogers wrote:
>> We might want to break this in to two items. One
for reducing bandwidth
>> in general, and another for reducing round trips.
> 
> "Reduce bandwidth in general" seems too
general for an actionable bug.  I
> filed it as one bug with the assumption that the
implementation is just
> using Dojo's magic compiler, which will both unify
files and do
> whitespace/comment stripping.
> 
> Since it just got targetted for 0.6, could someone
provide a direct pointer
> to this compiler?  (To understand better what it does
and how to use it)
> 
> I'd be interested to continue looking at
bandwidth-specific investigations
> of all sorts.  This "compile JS" approach, if
it pans out, seems like
> low-hanging fruit that will have such a dramatic impact
as to suggest it be
> done first.
> 
> -- Jared
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
> 

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev