The customer may well be interested in testing the number of users the publishing application can handle, and such load testing is acceptable as long as it does not go on for hours. Even a minute of automated loading of some writing of a work, e.g. with a load testing application available online, is sufficient to get a good feel for it. In a single-server system, it should be possible to load one article with basic resources, e.g. 8000 times per minute with a response time of 70 ms. Considering that e.g. most blog posts on the internet get only a few hundred reads per month, the basic resources should be "just fine". Images of public works will always be loaded via the CDN service, if a prepayment for the CDN service has been made.

One quick way for the customer to reduce the load on the publishing application is to increase the cache time per work, which is 5 seconds by default. This caching means that e.g. one writing of a work is not generated separately for each page load, but the last one is stored on the server in a file which is used for e.g. the next 5 seconds or as long as it is configured to be. It can be up to two hours. The generating of a writing and other parts of a work causes always a moderate load on the server's processor, and there is always the possibility that there will be a lot of page load requests at once. Reading the generated part of the work from a file causes, by comparison, a very low load on server resources.

Normally, many data centre service providers would charge for outbound data from servers of the publishing application after data transfer volumes exceed e.g. 20 TB, as in the case of Hetzner. This amount, i.e. 20 000 GB, is a large amount for a low traffic publishing application. To be on the safe side, an additional limitation is applied to the servers of the publishing application on a per-customer basis to prevent the monthly data transfer volumes from exceeding that 20 TB by limiting the transfer rate of the virtual network card of the server to 60 mbps or 7.5 MB/s (see calculation: The portion of the cost that exceeds the specified data transfer limit is referred to as 'overage costs' and the data that goes out of the server is referred to as either 'egress data' or 'outbound data'. If the data centre services are provided by a provider other than Hetzner or if 20 TB is otherwise not the limit for the overage costs, this will be explicitly mentioned before the conclusion of the service agreement.