Improving the performance of your charts

• Compressing the RGraph libraries
• Minifying the RGraph libraries
• Using caching on your webserver
• Pre-emptive caching
• Script tag placement
• Document structure
• Creating your charts asynchronously
• The DOMContentLoaded event
• Using AJAX requests
• Combining libraries (HTTP 1.1 only)
• Avoiding or minimizing shadow blur with animations or large charts
• Clearing the canvas before drawing


• A reasonable performance strategy
• General website performance tools
• Note about performance and HTTP/2

Although performance is great, (certainly compared to server-based libraries), you may still want to tune RGraph more.

The biggest thing you can do is use HTTP compression, which reduces the initial download time of the libraries, but there are quite a few things that you can do:

• Compressing the RGraph libraries

  HTTP compression can reduce your bandwidth bills and increase the speed of your website.

  The RGraph.common.core.js file for example is over 150k, but with compression, this can be reduced to around 35k. Nearly a fifth of the starting size! If you only do one thing to increase speed, then it should be this.

  To get this with Apache you have a few options:

  • You can use this Apache2 directive that compresses output:

    AddOutputFilterByType DEFLATE text/html text/plain application/x-javascript application/javascript text/css

  • You can use the Apache1.3 module mod_gzip which compresses the libraries on the fly.
  • You can compress the libraries manually using the Unix gzip command, rename them to remove the .gz suffix and add the header using an Apache directive (eg AddEncoding gzip .js).

    If you have some sort of release script it would make sense to add this to it to automate the process.

• Minifying the RGraph libraries

  Minification reduces the size of the library before compression takes effect, removing unnecessary spaces and comments etc. Using both minification and compression will give superb results.

  For example, before being split up into separate files, minification combined with compression reduced the common library from over 160k to roughly 70k.

  There is a Unix C program, JSmin, which minifies JavaScript libraries in the download archive or you can get pre-minified copies of the latest stable libraries here .

• Using caching on your webserver

  Since the RGraph files you're using won't change that often, you can set far-off Expires headers on them, or similar Cache-Control headers and the client will not even have to make a request for it.

  When you want to make sure the library is downloaded again (eg when you update it), then simply change the filename.

• Pre-emptive caching

  Slightly different to caching itself is pre-emptive caching. This involves downloading the files before the page that needs them is shown.

  This way they're already in the user's browser cache and the chart will then appear to be much quicker.

  An example of this would be having the library included at the bottom of your website's index page (maybe with the defer="defer" option).

  The script can be downloaded at will because the page doesn't use it, but for other pages, it will already be in the user's browser cache.

• Script tag placement

  According to Yahoo! guidelines placing the script tag at the bottom of the page can increase the perceived load time.

  If you do this, then your charts should be created in the window.onload or the jQuery ready events, otherwise, the browser may try to create them without the library having been loaded first and will therefore fail.

  You should consider the effect that the window.onload event has when your page is rather large. If the page is large there will be a small delay before the load event fires, and then creates the chart(s).

  This might not be so bad if the chart is not above the fold. However, if it is then you should carefully think about using the load event.

  You may wish to load the RGraph library in the page header, define the canvas tag and then immediately define the JavaScript that creates the charts.

  This way the charts will be created and shown and then the rest of the page loads. The endresult is that your charts appear to be faster.

  The jQuery ready event uses the DOMContentLoaded event if it's available. This event runs when the page has finished loading the HTML and scripts but doesn't wait for the images or styles.

  It therefore can be faster (sometimes very noticeably) than the window.onload event. An example of using it is:

  <script>
      $(document).ready(function ()
      {
          // Create your chart here
      });
  </script>
  

  Between the load event, the jQuery ready event, asynchronous JavaScript and careful tag placement, you will need to experiment to get the best result for you.

• Document structure

  The structure of your document can have a significant impact on how fast your charts are shown. For example, if you use tables for layout, this can delay the display of elements that are affected by the size of the table.

  Wherever you can, you should consider trying to convert your layout to use div tags.

  An example of this is the front page of this website. The example chart was right aligned using a table as a container. This caused a visible delay when showing them.

  In this case, it was a simple matter to convert the page to use div tags, and the page subsequently displays much faster.

• Creating your charts asynchronously

  Where possible, you may wish to create your charts asynchronously. This allows the browser to continue rendering the page immediately after getting to the code that creates the chart.

  This might not be visible if you don't have a lot of charts or if your page is small. You can read a little more about asynchronous charts and see some example code here.

  Note that some versions of different web browsers have had issues with creating charts asynchronously which presents itself by text not appearing sometimes (it's not consistent).

  Simply not using asynchronous chart production, in this case, resolves the issue.

• The DOMContentLoaded event

  Using this event can speed up the rendering of your charts a lot compared to the better-known window.onload event.

  It's supported by Chrome, Firefox, Safari, Opera and Internet Explorer 9+.

  This event fires when the structure of the page is loaded, but not necessarily the images or CSS.

  This means that if your page is laden with images this event will fire before the load event and create your charts quicker.

  The effect can be very noticeable.

  document.addEventListener('DOMContentLoaded', function ()
  {
      // Create chart here
  }, false);
  

  You can read more about the DOMContentLoaded event on the Mozilla website. There's an example of the DOMContentLoaded event here.

• Using AJAX requests

  If you can take advantage of AJAX you can use this method to get data from your server.

  If, for example, you have a chart that shows ongoing information, then instead of refreshing the whole page you could use an AJAX request to just get the data that you want and then update the chart.

  This reduces the amount of data that's needed to be transferred, so it reduces the amount of bandwidth used and will be quicker than a full page refresh, particularly if your page is weighty.

  There's a simple AJAX function that you can use here or you can use the jQuery $.get or $.ajax functions.

• Combining libraries (HTTP 1.1 only)

  You may want to consider combining the RGraph libraries into a single file.

  This won't save on the size of the individual libraries but will save on the number of headers that are sent as part of the response.

  If a typical response sends 500 bytes worth of headers and you send four chart libraries, then combining the libraries would save 1500 bytes.

  Many things need to be considered though, including things like caching, which can reduce the repeated downloading of the libraries.

  To make your life easy you may want to make this a part of your release script/process. This way you can make changes to the scripts in your development environment as you would normally.

  Another effect of combining libraries is reducing the amount of HTTP connections needed to fetch them.

  Most browsers have a limit on how many connections that they can create at the same time so if they're not being used to fetch the chart libraries they can be used for something else.

  There's a PHP script that you can use to combine multiple JavaScript files into one file here: combine.php and you'd use it like this:

  <script src="/javascript/combine.php/RGraph.common.core.js/RGraph.bar.js/... "><script>

  Note about HTTP2
  
  This kind of combining JavaScript libraries (and CSS files too for that matter) has become an anti-pattern in HTTP2. What this means is that if you're using HTTP2 then there's no need to combine libraries in this way.

  Combining libraries saves on using multiple connections and HTTP2 only uses a single connection. So there's no saving in doing this.

  If two pages use a slightly different set of libraries then those that have already been cached may not be able to be reused - so this would create extra downloads.

• Avoiding or minimizing shadow blur with animations or large charts

  If you're using animations then you may want to avoid or reduce the shadow blur that you're using.

  With HTML5 canvas shadow blur is a drain on performance.

  So if you're looking to get the most out of your charts or you're using animations that require redrawing the chart, turning off the shadow blur can reduce the time it takes to draw the charts. This leads to smoother charts.

• Clearing the canvas before drawing

  By clearing the canvas to a solid color your computer can make optimisations that it can't do if you leave it at the default transparent color.

  This effect of this improvement can be quite small - so you won't always see a difference. You can do this like so:

  .on('beforedraw', function (obj)
  {
      RGraph.clear(obj.canvas, 'white');
  })
  

A reasonable performance strategy

Though there's a lot you can do to increase performance, a few of the points here will be enough for most websites:

• Compression
• Minification
• Pre-emptive caching
• Caching

The number one thing you should do is compress your libraries. This has many benefits and easily provides the most gain, effectively for free.

Secondly, use the minified libraries. Because you can download the minified libraries here, you might as well use them.

Then we have pre-emptive caching. Because most websites won't show charts on the front page or will have a login page before any charts are shown, this effectively eliminates the library files download.

And lastly, caching should be done as a matter of course. There's no reason to keep downloading the same library so even caching for only 30 minutes (or the duration of an average visit to your website) will produce results.

General website performance tools

If you aim to improve your website's performance as a whole then you may be interested in these tools:

• https://www.webpagetest.org/
  This site can provide a lot of information about how to improve the performance of your website. Information that's specific to your site.
  
  
• Page Speed Insights
  The Page Speed plugins and the online tool also provide a great deal of information about how to speed up your website.
  
  
• The Yahoo Exceptional Performance documentation has lots of tips for making your website faster.

Note about performance and HTTP/2

From 2016 HTTP/2 will become more widespread - with many people planning to make the switch to it and this includes many hosting providers.

Patterns such as "domain sharding" (using multiple hostnames) and combining your JavaScript libraries become anti-patterns and are less useful (and in some cases actually hurt performance).

If you're planning to switch to HTTP/2, or already have, then you should compare the advantages of some of these techniques versus not using them and decide what, if any, the benefit is.

Again, in some cases, the use of some of these techniques may not help at all and may even hurt performance.