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 (including at least 4 vcpu), 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" for many purposes. Images of public works will always be loaded via the CDN service, if a prepayment for the CDN service has been made.

Lazy loading method is used for images and videos, i.e. only the parts of a webpage already on the screen and those within 1000 pixels of it have their images etc. loaded. The resolution of the images to be loaded has also been optimised to avoid unnecessarily loading images with too high resolution, both when the page is first loaded and when the browser window is resized. On large pages, resizing the browser window could easily result in up to thousands of image download attempts if the browser window were resized continuously for, say, a minute, so to take into account such a possibility only the image layout is adjusted according to the browser window size and the need to load different images having different resolution is programmatically considered coly momentarily.

One quick way for the customer to reduce the load on the publishing application is to increase the cache time per work. 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.

For an admin user (and optionally others), there is a sophisticated and extensible subsystem that allows them to monitor outbound data transfer amounts for the current month and receive a recommended usage limit for the remaining days, so that they can stay within the limits (like they could actually choose to do so). Configurable settings include, e.g. the limit within it would be "nice" if the outbound data transfer amount would remain, and the multiplier used to calculate another limit, which defines how much risk can be handled (in terms of costs). Data transfer throttling (slowing down the transfer speed) has levels ranging from minor to critical, after which there is an optional total suspension of service, in which case only a public notice stating that the data transfer limit has been exceeded is visible.

The throttling can be applied on a per-classification basis; by default, certain resource-intensive functions are throttled separately (import/export, upload and imageview), as are public pages and logged-in functions. Logged-in functions will never become inaccessible due to these restrictions. Every change made to this configuration is logged, in case it is necessary later to discuss which adjustments have had what effect. These details can be agreed upon more precisely in the service agreement. It is in consideration whether to give the admin user any controls for configuring settings at all, or whether to do this on admin's behalf.

It is assumed that possibly a large number of connections do not stem from normal use of the web application and may be probing activity caused by bots. They might cause relatively low amount of outbound data transfer, but they might also cause more costs than the customer is willing to accept. That might happen if the server becames a target for harrasment by using bots that cause lots of outbound data traffic that seemingly looks like normal data traffic. Total amount of less meaninful outbound data traffic is mentioned as text near the visualized information. In addition to these HTTP-based connections, there are also attempts to log in to the servers, which are not included in these calculations.