Good Practices of Deployment

This section holds tips for successfully deploying yFiles for HTML-based JavaScript web applications.

Web Browser Caching

Problem

Although you are updating your web application’s JavaScript files, your users don’t see your bug fixes and improvements, because they are not getting your new JavaScript files.

Analysis and Background

Your users’s web browsers serve stale content from their caches instead of requesting your updated files from your web server.

To minimize web traffic and web page rendering latency, web browsers apply file caching on their end. When opening a web page, the files that make up the page are stored locally, so that, ideally, any subsequent request to display the same web page can be handled from this local cache.

Web servers, on the other hand, can specify per file if caching of a file is allowed or not, and also when a file’s validity expires, i.e., when a web browser should invalidate its cached content and load information anew. This is achieved by means of HTTP response header configurations.

The caching mechanism of a web browser uses an URL-based scheme to store files and to retrieve them later again. Basically, this means that when a file is requested and there is a valid entry in the web browser’s cache under this URL, then the file associated with this entry will be served from the cache and there will not be made any contact to the actual server.

Solution

If you want to make sure that users of your web application

1. always see the most up-to-date version of your application
2. benefit from their web browser’s cache the most and hence put only the minimum amount of stress on your web server

then you can add a "versioning" scheme to your web application’s JavaScript files similar to how it is exercised in the yFiles for HTML demo applications.

The JavaScript files that make up the demo applications are stored in two directories where each directory name includes a versioning hash suffix: l-a61bcf8f42b1 and rs-a61bcf8f42b1.

The files in these directories are referenced from within the main HTML file of a demo application:

<script>
require.config({
  paths: {
    yfiles: '../../l-a61bcf8f42b1/yfiles',
    demo: '../../rs-a61bcf8f42b1'
  }
});

require([
    'yfiles/view-editor',
    'demo/demo-util',
    'demo/demo-styles',
    'demo/demo-context-menu',
    'yfiles/view-folding',
    'yfiles/view-graphml',
    'demo/license'],
  (yfiles, app, DemoStyles, ContextMenu) => {
    ...
  }
);
</script>

The versioning suffix added to the URLs of the JavaScript files directly addresses the URL-based scheme of a web browser’s caching mechanism. Whenever the versioning suffix changes, the JavaScript file has a new URL, which is unknown to the web browser’s cache and thus the file is requested from the web server.

In conjunction with the versioning suffix, the JavaScript files’s cache expiration time can be safely set to a time in the far future. This means to benefit the most from the web browser’s cache and to reduce the load on the web server to a minimum.

In the following web server configuration the cache expiration time of JavaScript files is set like so:

ExpiresActive On
ExpiresDefault "access plus 1 day" # Applies to all files (i.e., also *.html).
ExpiresByType text/javascript "access plus 1 week" # Applies to *.js files.

Using this combined setup and configuration, whenever you update your web application and replace some of its JavaScript files, you only need to change the versioning suffix that is part of the JavaScript files’s URLs.

Your users will then only need a single forced reload of the HTML files of your web application to reliably also get the latest versions of the JavaScript files.

HTTP Compression

Problem

Although you are bundling and minifying your web application’s JavaScript files, your application takes a long time to load.

Analysis and Background

The complete yFiles library is about ~6.7 MB in size. Downloading that much data in a browser, especially on a slow connection, can take what feels like a very long time. This is not as bad as it sounds, though, as most landing pages these days include images and videos that are even larger.

Nonetheless, there is room for improvement here.

Solution

Fortunately, JavaScript file are mostly text, and text can be compressed very well without much effort. In fact, almost all web server software and browsers already support such compression.

Widely-available compression algorithms on the web are gzip and Brotli. Especially by now, Brotli, which compresses better than gzip, should be the preferred option, with over 94 % browser support (with Internet Explorer being the only exception). Compression has to be enabled on the web server that is serving your application. There are lots of guides on the internet that cover how to do that for most popular web server software. Just search the web for keywords like “enable [gzip|brotli] compression [name of your server software]”.

Once enabled, your application’s files will be compressed on the fly, reducing the amount of data the client’s browsers have to download.

In combination with a working configuration for caching, this will become a one-time download and your users will need to download the compressed javascript files only the very first time they access the application.

The following table shows some file sizes of common file formats with and without compression:

As you can see, the JavaScript bundle and CSS file compress really well, while the video file does not (as it is already compressed).

In comparison to the sizes of other applications (at the time of writing):

Thus, enabling compression on your web server provides great benefits for your applications size and load time.

However, since all JavaScript code still has to be parsed and compiled by the browser (even when cached), reducing the code to what is really needed (e.g. by not loading the whole yFiles for HTML bundle if only part of the functionality is required) still provides benefits in page loading times and how long it takes for your application to become responsive to user input.