7.3Using a web server for static content and further configurations
Most web pages do provide more possibilities than the singular purpose to deliver content like it is stored in cmsWorks. Typically web sites consist of content, shop systems, user generated content like forums etc. . Having a Webserver in front of cmsWorks greatly helps to divide and split these tasks according to the services running in your own server environment.
Furthermore, there are certain limitations belonging to the configuration of the cmsWorks server stack. As example, cmsWorks itself does not - out of the box - implement the possibilities of restricted access of parts of the page which may be (simply) done using a standard Webserver by deploying something like a simple .htaccess file or SSL like Let's Encrypt of which you may be familiar and your workflow operates with. Please remember, the main task of cmsWorks is to deliver content - not to restrict it.
Additionally, performance gains may be obtained by dividing the delivery of static content (like often used and statically placed images, CSS or JavaScript files) from dynamically generated files of cmsWorks (like articles, distribution pages and so forth).
cmsWorks and Webservers
cmsWorks itself relies on the application server topasWorks. This means that - by default - you do not have to setup and configure a Webserver to run cmsWorks. That, greatly, helps whilst developing in cmsWorks: cmsWorks is, at first, designed to be a full-stack-application on it's own, meaning that you do not have to install a Webserver on your development environment at all.
Anyway, for a productive environment it is a good idea to put a Webserver "in front of" cmsWorks as mentioned above and to configure it correctly, at least for production aka "heavy" use. This is pretty simple to do.
Deliver static files via a web server rather than cmsWorks
Every website has some standard files used by pretty all pages of it's domain: Be it something like logo (or similar) graphics, a "JavaScript used by (most of) the pages" or CSS files. In case you are using a Webserver it definitely makes sense to deliver these files from the Webserver rather than using the detour over cmsWorks just to reduce the load on your delivering server(s) in a very simple way.
Simple approach for the Apache Web Server in front of cmsWorks
One example using ProxyPass is found here. Another using the website "www.mywebsite.com" as an Apache server instance that accepts requests on IP 10.0.0.1 and your cmsWorks server resides on IP 10.0.0.2 follows. The cmsWorks live generator is serving http configured on port 8081, a minimum Apache config for this would be, by example
<VirtualHost *:80>
ServerAdmin info@mywebsite.com
ServerName mywebsite.com
ServerAlias mywebsite.com www.mywebsite.com
# your ongoing configurations here (or below)
RewriteEngine On
ProxyPass / http://10.0.0.2:8081/ retry=0 timeout=10
ProxyPassReverse / http://10.0.0.2:8081/
ProxyErrorOverride On
</VirtualHost>
You may ignore the first lines but this way the Apache server on IP 10.0.0.1 takes all requests and passes them to the cmsWorks server on IP 10.0.0.2 to port 8081. SSL or gzip-encoding etc. should be handled before the requests are passed to cmsWorks. And please bear in mind that this is only a very simple example configuration.