CentralApp automatically optimises page rendering, caching, images, fonts, code loading and layout stability.
These optimisations are built into the platform and require no manual configuration.
Pages start displaying quickly
CentralApp uses server-side rendering (SSR) to prepare the page’s essential content and styling on its servers before sending them to the browser.
This allows the browser to start displaying useful content without waiting for the entire JavaScript application to be downloaded and executed.
Lower-priority elements can then be loaded progressively.
CentralApp also uses caching to avoid generating the same pages repeatedly when this is unnecessary.
When a page is published:
A generated version can be cached
This version can be reused for subsequent visitors
When a page is changed, a new version can be prepared in the background
The previous version can remain available during this preparation
This reduces the work required on the server and helps maintain consistent response times, including when the website receives a lot of traffic.
Images are adapted to the visitor
Images often account for a significant proportion of a web page’s total size.
CentralApp automatically optimises images supported by the platform to limit the amount of data downloaded by the browser.
In particular, images are:
Delivered in WebP format where possible
Prepared in several widths
Served at a size suited to the visitor’s screen
Loaded as a priority when they are important to the initial display
Lazy-loaded when they appear further down the page
This approach notably avoids systematically sending a very high-resolution image to a visitor using a smaller screen or mobile connection.
Images further down the page can use lazy loading. They are then downloaded only when the visitor approaches them.
When an external video service is used, CentralApp can also delay loading the video player where possible, so that it does not compete with the elements needed for the page’s initial display.
Fonts load without blocking the display of text
Custom fonts contribute to a website’s visual identity, but downloading them can also delay the display of text.
CentralApp prepares the necessary font information on the server and preloads the essential WOFF2 files for the displayed language.
Other character sets are loaded only when needed.
If a custom font is not immediately available, the browser can temporarily display a fallback font and then apply the custom font when it is ready.
This technique allows visitors to start reading the content without waiting for all fonts to finish loading.
Only the necessary code is loaded
A CentralApp website can contain many pages, features and interface elements. However, a visitor does not need to download all of this code to view a single page.
CentralApp therefore divides the application into several code bundles.
This allows the browser to:
Prioritise downloading the code required for the current page
Load the code for other pages separately
Load certain features only when they become necessary
Reduce the amount of JavaScript to download and execute during the initial load
This approach, known as code splitting or lazy loading of JavaScript, limits the work required from the browser when opening a page.
CentralApp also prepares certain connections to services needed for loading assets, fonts or media.
Techniques such as preconnect reduce the time required to establish a connection when a resource subsequently needs to be downloaded.
However, these connections are used selectively so that they do not compete with the resources needed to display the page.
The layout remains stable while loading
A page can load quickly while still providing a poor experience if its content shifts during loading.
For example, when an image appears without space having been reserved for it, the content below it can suddenly be pushed down.
CentralApp automatically reserves space for certain media and sections before their final content is displayed.
This helps limit unexpected shifts and maintain a stable layout during loading.
Google notably measures this stability with Cumulative Layout Shift (CLS), one of the Core Web Vitals metrics.
A good CLS means visitors are less likely to see content shift unexpectedly while viewing or using the page.
What CentralApp manages automatically
CentralApp directly handles the main technical optimisations:
Server-side rendering (SSR)
Caching
Image optimisation and delivery
Lazy loading of media
Font preloading
Adaptive loading of character sets
JavaScript code splitting
Lazy loading of certain features
Preconnection to certain resources
Layout stability
These settings do not need to be configured by the customer.
What can still affect performance
CentralApp optimises the technical elements it controls, but content added to the website and external services can still affect performance.
For example:
Many images can increase the amount of data to download
Videos can require significant resources
Interactive maps can add code and external requests
Booking tools can load additional scripts
Analytics and tracking solutions can add resources
External widgets can have their own loading behaviour
A few best practices can therefore help limit this impact:
Use only images that are useful to the page or the user experience.
Avoid unnecessarily large media. CentralApp optimises the images it supports, but it is still preferable to start with reasonably sized source files.
Keep pages focused. A page with a clear purpose is generally easier to browse.
Limit external services to the tools that are genuinely necessary.
CentralApp cannot fully control the loading behaviour of an external service.
How to measure performance
To measure the performance of a CentralApp website, always use the website’s published public URL.
The preview displayed in the CentralApp application uses an iframe intended for reviewing content and design. It is not the website’s public URL and should therefore not be used as a performance benchmark.
Google PageSpeed Insights can test a published page under simulated mobile and desktop conditions.
The tool notably uses Lighthouse to run laboratory tests and provides several performance metrics in addition to the overall score.
Results can vary from one test to another depending in particular on:
Network conditions
The location from which the test is run
Server load
The simulated browser and device
External services present on the page
It is therefore preferable to compare several tests rather than focus on a single score.
When enough data is available, Core Web Vitals field data is also particularly useful because it reflects the experience of real visitors.
Lighthouse laboratory data remains useful for analysing a page under controlled conditions and identifying potential technical issues.
A good website is more than a score
CentralApp’s built-in optimisations are designed to help websites:
Load quickly
Display useful content quickly
Remain visually stable
Respond quickly to interactions
Limit the work performed by the browser
However, no system can guarantee an identical Lighthouse or PageSpeed score for every page and under all conditions.
Final performance also depends on the page’s content, external services, the visitor’s device and connection, and the conditions in which the test is run.
A performance score is therefore a diagnostic tool, not an absolute measure of a website’s quality.
The main objective remains to enable visitors to see useful content quickly, understand the page and interact with it without unnecessary waiting or shifting.
CentralApp handles much of the technical work needed to make this experience possible.