Slowness creeps in gradually: How to manage performance in day-to-day publishing

Category: Website performance

A website rarely becomes slow in a single day. Performance usually degrades through many small changes: a large hero image, a new video embed, yet another tracking script or a content block that retrieves data from multiple sources. Each change seems harmless on its own, but users notice the combined effect.

That is why performance should be part of the ongoing publishing process, not just a technical project at launch. An editorial performance budget sets clear limits on what pages can be burdened with and describes what should be checked before and after publication.

What a performance budget should address

A performance budget is a set of practical guidelines for load times, file sizes, scripts and stability. The budget should apply to selected page types that represent the most important user journeys.

For a typical corporate website, this might include:

• The homepage
• An important service page
• An article with images and video content
• A campaign landing page
• The contact page or a form

For an online store, you should also monitor category pages, product pages, the shopping cart and checkout. The point is not to test everything all the time. The point is to detect whether routine changes are gradually making key page templates heavier.

Use Core Web Vitals as user-focused warning lights

Core Web Vitals make performance more tangible by measuring key aspects of the user experience. Three measurements are particularly relevant.

LCP: When the main content becomes visible

Largest Contentful Paint measures how quickly the largest visible content element loads. On many websites, this is the hero image, a large heading or a content section near the top of the page.

Poor LCP is often caused by heavy images, slow server response, render-blocking stylesheets or the browser discovering the most important element too late. The editorial team can influence this directly through its choice of image, format and content block.

INP: How quickly the page responds

Interaction to Next Paint measures responsiveness when users click, tap or type. Heavy JavaScript tasks can make the menu, form or product filter feel slow, even when the page already appears fully loaded.

New tracking tools, chat solutions, maps, filters and interactive modules should therefore be assessed on more than functionality. You must also check how they affect responsiveness on real devices.

CLS: Whether the content moves around

Cumulative Layout Shift measures unexpected movement on the page. A typical example is a button shifting when an image, consent field or advertisement loads.

Specified image dimensions, reserved space for dynamic content and controlled font loading contribute to a more stable layout. This is particularly important on mobile, where small shifts are more likely to cause accidental taps.

Create rules the editorial team can actually follow

A performance budget works poorly if it consists only of technical metrics. Therefore, translate the targets into concrete publishing rules.

Set limits for images

Images are often the largest source of data on a content page. Define recommended dimensions and maximum file sizes for hero images, card images, portraits and illustrations. The publishing solution should generate tailored variants so that a mobile phone does not download an image intended for a large screen.

Use modern image formats when the solution supports them. Compress images before publishing, and avoid using a large original photo simply because it will later be scaled visually with CSS.

Regular lazy loading is suitable for images further down the page. The main image at the top should normally be prioritised, however, because delaying its loading can worsen LCP.

Limit external content

Videos, maps, social media and other embeds can load many external resources. Use a preview image with click-to-activate functionality when possible. This prevents all visitors from loading the full video player or map solution before they actually need it.

Also create a rule that new third-party services must have a named owner. If no one uses the data or maintains the functionality, the script should be removed.

Reuse established content blocks

Custom-built campaign sections can add extra CSS, JavaScript and fonts that are used on only one page. Reusing proven components generally results in less code, fewer errors and more predictable performance.

This does not mean that all pages should look the same. It means that variation should be created within a controlled design system rather than building a new technical solution for every campaign.

Distinguish between content weight and the technical foundation

The editorial team can reduce large images and unnecessary embeds, but some problems must be solved in code, server configuration or the database. The performance budget should therefore have two levels.

Content level covers images, video, documents, embeds, the number of components and the use of third-party services.

Technical level covers server response, caching, JavaScript, CSS, fonts, database queries and integrations.

When server response slows down, investigate cache hits, external API calls and database activity before you start compressing more images. A full-page cache can deliver prebuilt pages quickly, while an object cache can reduce repeated database queries. Both require clear rules for when content should be cleared and rebuilt.

The database should be monitored over time. Unindexed searches, large tables, outdated temporary data and extensions that retrieve more information than necessary can result in slow responses. This is particularly noticeable on pages that cannot be fully cached, such as search, logged-in areas and checkout.

Do not assess JavaScript and CSS based on file size alone

A small JavaScript file can do a lot of work and block the browser for a long time. A larger file may be less problematic if it loads at the right time and contains only the necessary functionality.

So check whether the code:

• loads on pages where it is actually used
• blocks the display of content at the top of the page
• starts long-running tasks when the user tries to click
• duplicates functionality that already exists
• comes from a third party and changes outside your control

The same applies to CSS. Large global stylesheets often arise when old components are retained after they have been taken out of use. Regular cleanup is better than trying to compress an ever-growing stylesheet.

Measure both technical and perceived speed

Lab tests are useful because they can be repeated under consistent conditions. They show whether a specific change improves or worsens the page. Data from real visits provides a different picture, because users have different phones, networks and geographical distances from the server.

Supplement the measurements with a simple manual check. Open the page on a typical mobile phone, use a mobile network and complete the most important task. Note whether the main content appears quickly, whether buttons respond immediately, and whether elements shift.

Perceived speed is also about feedback. A button that shows that something is being processed feels more reassuring than one that appears to have stopped working. A form can respond quickly visually even if the underlying process takes a little time.

A simple check before publishing

The check should be short enough to be used. For larger landing pages, campaigns and new templates, you can follow this sequence:

1. Check image formats, dimensions and file sizes.
2. Count new videos, maps and other external embeds.
3. Clarify whether new tracking scripts or interactive features are necessary.
4. Test the page on mobile with a limited network connection.
5. Check LCP, INP and CLS against a previous measurement of the same page type.
6. Check server response and database activity if the entire page starts loading late.
7. Document any exceptions and who should follow them up.

Exceptions will occur. A campaign may need video, maps and advanced tracking. In that case, the decision should be deliberate, time-limited and reversible after the campaign.

Make performance a shared responsibility

The editorial team does not own the server, and developers do not choose all the images. Good website performance therefore requires a clear division of responsibility.

• Editorial team follows rules for images, embeds and content blocks.
• Marketing manager approves new tracking and advertising services.
• Developer or supplier manages code, caching, databases and technical measurements.
• Website owner decides which deviations can be accepted for business reasons.

Start with three representative pages and record the current level. Set a few clear, understandable limits and incorporate the check into the existing publishing workflow. This makes performance an ongoing quality task, rather than a cleanup job you have to pay for again every time the website has become noticeably slow.