One operating profile does not fit all: Choose hosting based on actual load

A corporate website, campaign site and online store can run on the same publishing platform, but they should not necessarily have the same operating setup. Their loads differ, the consequences of downtime vary, and some functions place very different demands on the server, database and caching.

Therefore, choosing professional web hosting should start with an operating profile: a specific description of what the website does, when it is used most, which data changes, and how serious an outage would be. The profile makes it easier to choose the right operating environment without paying for unnecessary capacity or discovering limitations when traffic increases.

Start with the workload, not the server package

Hosting is often sold as packages with storage, processing power and traffic allowances. These figures mean little on their own. What matters is how the solution is actually loaded.

A content site with many visitors can be easy to operate if its pages can be cached effectively. An online store with fewer visitors may be more demanding because the shopping cart, inventory status, customer data and checkout are processed dynamically. A website with integrations can also run into problems even with moderate traffic if external systems respond slowly.

Therefore, map the following before choosing the operating environment:

• Which page types and functions generate the most load?
• What proportion of the content can be delivered from cache?
• When do traffic peaks occur, and are they planned or unpredictable?
• Which functions need to write to the database in real time?
• Which integrations are required for purchases, logins or form submissions?
• How serious would the consequences of slowness, errors or downtime be?

The result does not need to be an extensive document. A brief overview of critical user journeys, load patterns and dependencies provides a far better basis for decisions than the number of gigabytes alone.

Place the website in a practical operating profile

Most businesses can start with one of three profiles. The profiles are not technical standards, but a tool for clarifying the required level of operational services.

Profile 1: Informational website with steady traffic

This is typically a corporate website with services, articles, contact forms and some landing pages. The content changes regularly, but most traffic consists of reading.

Here, effective page caching, optimized images and simple CDN distribution often have a significant impact. The operating environment must be stable, but the need for advanced automatic scaling is usually limited. Monitoring should verify that key pages and forms work, not just that the server responds.

Profile 2: Campaign- or media-driven website

This profile has significant variations in traffic. A newsletter, advertising campaign or media coverage can send many visitors to the same landing page within a short period.

Here, caching and CDN are essential because traffic can often be offloaded before it reaches the web server itself. At the same time, forms, registrations and other dynamic functions must withstand the peak. Capacity testing before a major campaign is more valuable than assuming that a more expensive server will automatically solve the problem.

Profile 3: Business-critical or transaction-based solution

Online stores, customer portals and solutions with login functionality have more dynamic requests and greater requirements for data consistency. An error can affect orders, payments or access to important services.

Such solutions normally require closer monitoring, more frequent backups, clearer maintenance procedures and better separation between production and test environments. It should also be possible to monitor the load on the application, database and external integrations separately.

Use caching without hiding errors

Caching reduces load by reusing pre-generated responses. This can happen in the browser, in a CDN, in front of the web server or within the publishing solution. Used correctly, it delivers faster pages and greater capacity.

The problem arises when everything is treated the same way. An article page can often be cached for a long time, while shopping carts, logged-in pages and personalized content must be handled differently. Incorrect rules can display outdated content, the wrong price or information belonging to another session.

Therefore, create a simple caching plan:

• Define which page types can be cached in full.
• Exclude shopping carts, checkout, account pages and other personalized views.
• Determine how quickly changes should become visible after publishing.
• Test cache purging when products, prices and content are changed.
• Check the functions both as an anonymous and a logged-in user.

Caching should be a controlled part of the architecture, not a layer added at the end to conceal slow code or heavy database queries.

Assess CDN based on geography and traffic type

A CDN stores and delivers static resources from multiple geographic locations. It can reduce the distance to the user, offload the origin server and handle large volumes of requests for images, stylesheets and scripts.

For a website with users in Norway and a well-positioned operating environment, the benefit may differ from that of an international service. A CDN is still useful during traffic peaks, for large media files and when an additional layer in front of the server is needed.

Clarify what the CDN is actually supposed to do. Should it only deliver static files, or also cache entire pages? How is content purged after publishing? What happens if the origin server is unavailable? And will visitors still be sent to dynamic functions that do not work?

A CDN can reduce load and improve delivery, but it does not replace a robust operating environment.

Tailor backups to how often data changes

Backup frequency should be determined by how much data the business can afford to lose. A website that is updated only a few times a month has different needs from an online store receiving orders throughout the day.

Also distinguish between files and the database. Product images and documents may change rarely, while orders, form submissions and customer data are updated continuously. One daily copy of the entire solution may therefore be sufficient for one profile and insufficient for another.

A workable backup plan should clarify:

• How often files and the database are copied.
• How long the copies are retained.
• Whether the copies are stored separately from the production environment.
• Who can initiate a recovery.
• How an individual file, database or the entire solution can be restored.
• How the business verifies that the copies can actually be used.

Backup is not just storage. It must match the website’s rate of change and the operations team’s ability to use it.

Monitor the user journey, not just the server

A server can report normal uptime while the contact form is failing, search returns no results or checkout is stalled. Technical availability is therefore only one level of monitoring.

Build monitoring in layers:

1. Availability: Does the website respond, and do key pages load?
2. Performance: Have response times, database usage or error rates changed?
3. Functionality: Do forms, login, search and checkout work?
4. Integrations: Do payment solutions, inventory systems, CRM and other essential services respond?

Alerts must go to someone who is responsible and has access to investigate the issue. Too many irrelevant alerts create noise. Define thresholds, severity levels and who should be contacted outside normal working hours.

Choose a maintenance window based on the business’s rhythm

Updates to the content management system, extensions and server components should be carried out as planned. The timing should be based on when the website is used least, but also on when qualified people are available if something goes wrong.

It is not always wise to update late at night if no one can follow up until the next morning. For some businesses, a controlled daytime window is safer, particularly when changes can be tested and relevant employees can confirm that critical functions are working.

A separate test environment is important when the website has an online store, login, integrations or many customisations. It reduces the risk of updates, but only if the test environment resembles production and is actively used.

Choose an environment based on impact, not prestige

Shared hosting, managed hosting, virtual servers and cloud-based environments can all be the right choice. There is no solution that is automatically best for everyone.

A good choice provides sufficient capacity, predictable operations and a clear division of responsibilities. More advanced infrastructure can provide greater flexibility, but also requires expertise in configuration, monitoring and error handling. A simple managed environment may be better if the provider handles the technical complexity and the business does not have to build its own operations function.

Pay particular attention to isolation from other customers, scalability, access to logs, support for a test environment, database capacity and who maintains the different layers.

Make the operations profile a living management tool

The operations profile should be reviewed when the website gains new features, larger campaigns, more integrations or higher revenue. A solution that was right at launch may become unsuitable as usage changes.

Summarise the profile on one page with critical user journeys, expected traffic peaks, caching requirements, backup frequency, monitoring points and responsible people. This makes hosting and operations a deliberate choice linked to the business’s actual needs, rather than a technical package that only receives attention when something fails.