Details

    • Similar issues:
      XWIKI-4183Improve page load speeds via parallel JavaScript download
      XWIKI-9242Fetching RSS feed content asynchronously or after specified time interval
      XWIKI-1990Pages take ~30 seconds to load when enabling pipelining in fasterfox
      XWIKI-4630WYSIWYG doesn't load
      XWIKI-6454Activity Stream needs certain indexes set on the database in order to improve performace
      XWIKI-1750Edit locking and unlocking might halt page loading
      XWIKI-1794Improve panel printing in page.
      XWIKI-6480Concatinate always used scripts together and serve in single file.
      XWIKI-9046Improve document save performance by not loading the full history
      XWIKI-7001WYSIWYG does not load in IE9

      Description

      Over time the xwiki skins in general have added JS, CSS, images. This is making xwiki pages slow to load as shown by YSlow (see attached image).

      What we should do:

      • 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
      • GZip all HTTP response contents
      • Modify the build to automatically merge all CSS and JS files together in a single file (see http://aciddrop.com/2008/01/03/automatically-join-your-javascript-and-css-into-a-single-file/)
      • Add expire headers. We need to be careful with this and probably do what yahoo recommends: modify the file names when they change so that clients get the newer versions. Otherwise they'll need to remember to refresh their caches. This can be automated in the build and should be pretty easy especially if we merge all files into a single one.
      • Minify CSS and JS files

        Issue Links

          Activity

          Hide
          Vincent Massol added a comment -

          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.

          Show
          Vincent Massol added a comment - 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.
          Hide
          Vincent Massol added a comment -

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

          Show
          Vincent Massol added a comment - Note: The YSlow stats were from the home page of xwiki.org
          Hide
          Vincent Massol added a comment -

          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.

          Show
          Vincent Massol added a comment - 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.
          Hide
          Sergiu Dumitriu added a comment -
          Show
          Sergiu Dumitriu added a comment - XWIKI-1642
          Show
          Vincent Massol added a comment - See also http://www.nabble.com/-proposal--JS-and-CSS-improvements-tp12806140p12806140.html
          Hide
          Vincent Massol added a comment -
          Show
          Vincent Massol added a comment - Some resource links: http://vandelaydesign.com/blog/css/clean-css-code/
          Hide
          Vincent Massol added a comment -

          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

          Show
          Vincent Massol added a comment - 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
          Hide
          Sergiu Dumitriu added a comment -
          Show
          Sergiu Dumitriu added a comment - Again, see the comment on http://jira.xwiki.org/jira/browse/XWIKI-1642
          Hide
          Vincent Massol added a comment -

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

          Show
          Vincent Massol added a comment - An interesting framework to research: Jawr, see http://www.theserverside.com/news/thread.tss?thread_id=48318
          Hide
          Vincent Massol added a comment -

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

          Show
          Vincent Massol added a comment - Interesting loading stats at http://ejohn.org/blog/library-loading-speed/
          Hide
          Vincent Massol added a comment -
          Show
          Vincent Massol added a comment - A nice blog on performances: http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/
          Hide
          Jean-Vincent Drean added a comment -

          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 ?

          Show
          Jean-Vincent Drean added a comment - 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 ?
          Hide
          Sergiu Dumitriu added a comment -

          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").

          Show
          Sergiu Dumitriu added a comment - 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").
          Hide
          Sergiu Dumitriu added a comment -

          This can be applied now, as the parse error has been fixed. See XSALBATROSS-18

          Show
          Sergiu Dumitriu added a comment - This can be applied now, as the parse error has been fixed. See XSALBATROSS-18
          Hide
          Vincent Massol added a comment -

          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
          Show
          Vincent Massol added a comment - 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
          Show
          Vincent Massol added a comment - Another link: http://ajaxian.com/archives/yahoo-releases-new-performance-best-practices
          Hide
          Vincent Massol added a comment -

          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
          Show
          Vincent Massol added a comment - 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
          Show
          Vincent Massol added a comment - Really great slides on http://feeds.feedburner.com/~r/oreilly/radar/atom/~3/281377463/more-on-high-performance-websi.html
          Hide
          Jordi Hernandez Sellés added a comment -

          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

          Show
          Jordi Hernandez Sellés added a comment - 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
          Hide
          Vincent Massol added a comment -

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

          Show
          Vincent Massol added a comment - Thanks Jordi for your comment. We haven't progressed much on this yet.
          Hide
          Vincent Massol added a comment -

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

          Show
          Vincent Massol added a comment - Another link for evaluating page load times: http://code.google.com/speed/page-speed/index.html
          Hide
          CalebJamesDeLisle added a comment -

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

          Show
          CalebJamesDeLisle added a comment - JS blocking seems to be the greatest single obstacle to fast loading.
          Hide
          CalebJamesDeLisle added a comment -

          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?

          Show
          CalebJamesDeLisle added a comment - 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?
          Hide
          Vincent Massol added a comment - - edited

          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:

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

          Show
          Vincent Massol added a comment - - edited 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...
          Hide
          CalebJamesDeLisle added a comment -

          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?

          Show
          CalebJamesDeLisle added a comment - 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?
          Hide
          Sergiu Dumitriu added a comment -
          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
          Show
          Sergiu Dumitriu added a comment - - 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. GZip all HTTP response contents TODO, right now it's done in the httpd frontend, not very important 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 Add expire headers TODO, important - Minify CSS and JS files - Done, at build time for static resources and at runtime for wiki extensions
          Hide
          Ecaterina Moraru (Valica) added a comment -

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

          Show
          Ecaterina Moraru (Valica) added a comment - how about http://www.cdnjs.com/ cdn for xwiki.js?
          Hide
          intertesto added a comment - - edited

          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

          Show
          intertesto added a comment - - edited 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
          Hide
          Robert Collier added a comment - - edited

          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

          Show
          Robert Collier added a comment - - edited 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
          Hide
          Sergiu Dumitriu added a comment -

          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.

          Show
          Sergiu Dumitriu added a comment - 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.
          Hide
          Vincent Massol added a comment -

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

          Show
          Vincent Massol added a comment - Hmm this would mean we would need to have 2 web.xml: a generic one and a specific one for the Jetty distribution...
          Hide
          CalebJamesDeLisle added a comment -

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

          Show
          CalebJamesDeLisle added a comment - IMO this would not have significant impact. Unfortunately the things that will are more painful to improve.
          Hide
          Vincent Massol added a comment -

          Note that reducing # of JS/CSS files can have negative effects too, see http://raibledesigns.com/rd/entry/you_shouldn_t_have_to

          To summarize:

          • Use of HTTP 2.0 solve some issues
          • Concatenating may cost in having to reload the whole big file when a small change is made
          • Concatenating prevent the browser from executing js before the full big file is loaded

          Something to take into account when we tackle this topic of page loading times.

          Show
          Vincent Massol added a comment - Note that reducing # of JS/CSS files can have negative effects too, see http://raibledesigns.com/rd/entry/you_shouldn_t_have_to To summarize: Use of HTTP 2.0 solve some issues Concatenating may cost in having to reload the whole big file when a small change is made Concatenating prevent the browser from executing js before the full big file is loaded Something to take into account when we tackle this topic of page loading times.

            People

            • Assignee:
              Unassigned
              Reporter:
              Vincent Massol
            • Votes:
              8 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Date of First Response: