OS.js – YSlow (V2) Experiment

 

Runing version: OS.js 0.6-alpha9

OS.js registry was reset, browser caches purged, then page was tested, reloaded and benchmarked.
I did this test to check out how the caching had impoved over previous minor-version. Let’s just say it has improved a “lot”.

Sloppy was used to simulate a 128k connection.

Changes I made:

  • Added DEFLATE (Compression) to all resources
  • Added 1 week expiration dates for vendor libraries
  • Added 1 week expiration dates for image files, icons, etc.
  • All other content not matching those rules gets 30 second expiration date
  • Added FileETag Mime Size to resources
  • Increased some timeouts in the client/server code to make sure slow connections get all data
  • Added new parameters to <script /> tags (see below in the result section)

Initial loaded content:

This was results from my local development computer, so there is no compression/minimized resources served. When serving minimized files the sizes usually go down 50% (excluding images because I’ve yet to optimize them).

 doc      (1)   10.8K
 js       (28)  705.9K
 css      (14)  88.8K
 cssimage (7)   89.0K
 image    (9)   7.6K
 favicon  (1)   1.4K

Firefox 10.0.2:

NOTE: After applying the ‘async’ and ‘defer’ parameters to the <script /> HEAD elements the local speed went down to  1.852s

Local    02.581s [Grade C] Overall performance score 79
Server   03.153s [Grade B] Overall performance score 81
128k     20.674s [Grade C] Overall performance score 79 
Local    The page has a total of 60 components and a total weight of 348.7K bytes
Local    The page has a total of 61 HTTP requests and a total weight of 349.4K bytes with empty cache
Server   The page has a total of 61 components and a total weight of 301.5K bytes
Server   The page has a total of 61 HTTP requests and a total weight of 301.5K bytes with empty cache
128k     The page has a total of 63 components and a total weight of 350.1K bytes
128k     The page has a total of 63 HTTP requests and a total weight of 350.1K bytes with empty cache

Chromium 17.0.948.0:

NOTE: After applying the ‘async’ and ‘defer’ parameters to the <script /> HEAD elements the local speed went down to 2.430s

Local    03.210s [Grade C] Overall performance score 78
Server   02.200s [Grade B] Overall performance score 80
128k     31.690s [Grade C] Overall performance score 78
Local    The page has a total of 60 components and a total weight of 493.8K bytes
Local    The page has a total of 60 HTTP requests and a total weight of 496.3K bytes with empty cache
Server   The page has a total of 61 components and a total weight of 357.4K bytes
Server   The page has a total of 61 HTTP requests and a total weight of 357.4K bytes with empty cache
128k     The page has a total of 60 components and a total weight of 494.0K bytes
128k     The page has a total of 60 HTTP requests and a total weight of 494.0K bytes with empty cache

Why I got an so-called average grade:

  • Package resources never gets cached (for now)
  • Core resources (themes, fonts, main scripts) never gets caches (for now)
  • Cookie-free domains is still under development (For static content or commonly used items, excluding the core stuff)
  • CDN is not currently planned

Conclusion:

It does not seem that any of the suggestion have any huge impacts on my applications. There are a few seconds to spare, that may have some positive effects in the future. The size transferred was smaller, but had a little impact on the loading time.

To really get an improvment here I’ll need to create a sub-domain for static served files (like images, vendor libraries) so the browser will ignore the cookie header and permform resource loading in parallel (This can also be implemented within CDN with a number-prefixed sub-domain that is chosen on random upon setting image sources).

I’ll also need to figure out how to do proper caching of application sources. The best solution here would be ETags.


About this entry