Improve page loading times

I'm scheduling for 1.3M1 for now even though I'm not sure who'll have the time to work on this. It's quite an important issue though hence the move to 1.3M1.

Note: The YSlow stats were from the home page of xwiki.org

It also seems that for some reason the style.css file is loaded twice for each page invocation. Need to find out why and remove the second loading.

XWIKI-1642

See also http://www.nabble.com/-proposal--JS-and-CSS-improvements-tp12806140p12806140.html

Some resource links: http://vandelaydesign.com/blog/css/clean-css-code/

The reason style.css is loaded twice is because we have this definition in stylesheet.vm:

<link href="$defaultStyleURL" rel="stylesheet" type="text/css" />
<link href="$defaultStyleURL" rel="stylesheet" type="text/css" title="default" />

This seems to be required (to be validated) because some browsers may not support alternate stylesheets properly... To be investigated.

Reference:
http://www.w3.org/TR/html401/present/styles.html

Again, see the comment on http://jira.xwiki.org/jira/browse/XWIKI-1642

An interesting framework to research: Jawr, see http://www.theserverside.com/news/thread.tss?thread_id=48318

Interesting loading stats at http://ejohn.org/blog/library-loading-speed/

A nice blog on performances: http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/

javascripts.vm and stylesheets.vm doesn't use XWiki.getSkinFile with the forceSkinAction flag everytime (with this action the response expiration is always set to 1 month). Patch attached.
WDYT ?

I tried to do that once, and I got some velocity exceptions. I think that SkinAction should not parse all the js/css files it sends, but use a request parameter (something like "?parse=true").

See also: http://feeds.feedburner.com/~r/blogspot/Dcni/~3/251619119/how-we-improved-performance-on-google.html
of interest:

• concatenate images into one
• lazy loading of js

Another link: http://ajaxian.com/archives/yahoo-releases-new-performance-best-practices

http://feeds.feedburner.com/~r/oreilly/radar/atom/~3/281377463/more-on-high-performance-websi.html

• Split the initial payload
• Load scripts without blocking
• Don't scatter scripts
• Split dominant content domains
• Make static content cookie-free
• Reduce cookie weight
• Minify CSS
• Optimize images
• Use iframes sparingly
• To www or not to www

Really great slides on http://feeds.feedburner.com/~r/oreilly/radar/atom/~3/281377463/more-on-high-performance-websi.html

Hi, I'm the lead developer of Jawr (https://jawr.dev.java.net), which vincent pointed to in a previous comment. If you need any further information to decide wether you should use it, or want me to help out in integrating it let me know. I'll be happy to help

Thanks Jordi for your comment. We haven't progressed much on this yet.

Another link for evaluating page load times: http://code.google.com/speed/page-speed/index.html

JS blocking seems to be the greatest single obstacle to fast loading.

As you can see from the image (Main.Sandbox-PageSpeed.png) javascript is by far the biggest time waster, I also consider it to be "low hanging fruit" as far as performance improvements go.
Note: this test was run with the browser cache turned off.
Perhaps we could concatenate all of the scripts together at runtime?

New suggestion: use wro4j: http://code.google.com/p/wro4j/
(see also http://raibledesigns.com/rd/entry/javascript_and_css_concatenation)

See the discussion thread at:

• http://markmail.org/thread/hpu6dm7y3b3uelt2
• http://markmail.org/thread/mderz4fopcsahp3n

Note that there are 2 threads because there was an unfortunate cross-post...

I think since Sergiu's change to defer javascript loading, the main cost is in the request/response cycle itself and there are a great number of inefficiencies to be dealt with in the request/response cycle so should this be closed as wontfix because it is too broad?

1. -Reduce the number of JS to load by moving out JS that are not needed for all pages so that they are loaded on demand- Done: *sx pulls.
2. GZip all HTTP response contents TODO, right now it's done in the httpd frontend, not very important
3. Modify the build to automatically merge all CSS and JS files together in a single file Conflicts with #1; partially done since Colibri and Toucan have mostly one skin file instead of several, as Albatross does
4. Add expire headers TODO, important
5. -Minify CSS and JS files- Done, at build time for static resources and at runtime for wiki extensions

how about http://www.cdnjs.com/ cdn for xwiki.js?

Just a note to signal my like in this feature. Another improvement is to use CSS sprite in order to reduce the number of images download, http://www.alistapart.com/articles/sprites and http://developer.yahoo.com/performance/rules.html

The Performance page (http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances) recommends adding Apache web server for gzip http response compression. But I don't understand what about doing this in Jetty itself? http://blog.max.berger.name/2010/01/jetty-7-gzip-filter.html

http://stackoverflow.com/questions/11383645/how-to-configure-jetty-as-css-js-file-server-with-expires-header

Thanks for the link, this could indeed be done by default in the standalone distribution. Note that Jetty evolved along XWiki, so those settings were not available for most of the time that we've been using it.

Hmm this would mean we would need to have 2 web.xml: a generic one and a specific one for the Jetty distribution...

IMO this would not have significant impact. Unfortunately the things that will are more painful to improve.