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 over150k
, but with compression, this can be reduced to around35k
. 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
modulemod_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 anApache
directive (egAddEncoding gzip .js
).If you have some sort of release script it would make sense to add this to it to automate the process.
-
You can use this
-
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 roughly70k
.There is a Unix C program,
JSmin
, which minifiesJavaScript
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-offExpires
headers on them, or similarCache-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 thejQuery
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 theload
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 theJavaScript
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 theDOMContentLoaded
event if it's available. This event runs when the page has finished loading theHTML
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, thejQuery
ready
event, asynchronousJavaScript
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 theDOMContentLoaded
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 thejQuery
$.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 multipleJavaScript
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 combiningJavaScript
libraries (andCSS
files too for that matter) has become an anti-pattern inHTTP2
. What this means is that if you're usingHTTP2
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.