< Web performance monitoring />
We keep an eye on your site 24/7
Are you looking to stabilize your site's performance and anticipate inevitable regressions over time?
Get a quote in 24 hoursPartner
Having a high-performing site at this very moment is good. Ensuring it stays that way over time is even better!
< Our web performance experts collect, analyze, and leverage your performance data />
Reduce operational risks
Multiple factors can degrade a site's performance level without anyone noticing, or at least not soon enough.
Server maintenance
A server, regardless of its technical environment, requires regular updates. When these affect the web application (Apache, Nginx, LiteSpeed, php, MySQL, etc.), regressions or bugs can be introduced and impact the cache mechanism or overwrite custom configurations without displaying any alerts. A skipped algorithm or a reduced cache can cause TTFB to plummet.
Site update
Whether on WordPress, PrestaShop, or any other framework, updates to the CMS, theme, or modules can introduce regressions: an explosion in the volume of loaded resources, introduction of Layout Shifts… The logic is similar for custom developments, whether implemented by developers or generated by an AI like Claude Code.
Human contribution
We tend to consider that a majority of technical issues are the result of human error. This is true on the web, where deploying unoptimized content (especially images and videos) and integrating third-party JavaScript tools (tracking, analytics, A/B testing, etc.) can sometimes penalize an initially high-performing site. It is essential to see this to correct the course and train the teams.
High-value monitoring
There are many tools to monitor web page performance: GTmetrix, WebPageTest, Pingdom, Calibre, DebugBear… Our approach, based on real-user data, or “ RUM ”, is the most effective: it allows us to concretely identify issues with server response time (TTFB), perceived speed (LCP), visual stability (CLS), and interactivity (INP and Long Tasks).
As a Contentsquare partner, we assist several major clients in using the CS Digital suite, and more specifically Find&Fix and its Speed Analysis module (formerly Dareboost). Similarly, as a professional Request Metrics user, we are able to help you make optimal use of it as part of our monitoring services.
They entrusted us with monitoring their site
What is RUM, Real User Monitoring ?
RUM, or Real User Monitoring, is the collection of performance metrics directly on your visitors' devices during their actual browsing. Each page view sends back its own LCP, CLS, INP, and TTFB values. The data describes your users, not a lab test, with their connections and devices.
This is what distinguishes it from synthetic monitoring, which replays a load from a fixed machine at regular intervals. Synthetic is reproducible and used for diagnostics; it only knows one visitor profile. RUM covers the entire distribution of visits, including older mobiles and degraded networks that make up the bad percentiles.
The distinction is crucial because Google evaluates Core Web Vitals on field data, at the 75th percentile. A site may show excellent synthetic scores and fail the field thresholds. Only RUM can identify this gap and then correct it where it actually occurs.
Our system combines both sources. The RUM tag installed on your site feeds continuous monitoring, while regular synthetic tests isolate the technical cause of each degradation observed. The first source alerts, the second explains: it is this combination that makes a regression correctable in a few days rather than at the end of the quarter.
Have a question?
We have the answer!
Consult the FAQ for details about the service.
What tools do you use to monitor pages?
Our monitoring relies complementarily on synthetic testing tools like Treo and Speed Analysis (based on Google Lighthouse) and Real User Monitoring tools like Contentsquare and Request Metrics.
However, we can rely on data from other tools such as DebugBear or Calibre (non-exhaustive list). They also collect performance metrics in the field and/or in the "lab".
What does operational performance monitoring include?
As part of our monitoring services, an initial alignment and discovery phase allows us to get to know our clients: technical stack in frontend and backend, server infrastructure, team organization, roadmap functioning, production deployment schedule, etc.
This allows us to offer relevant solutions that are perfectly adapted to your constraints. The goal is to quickly and lastingly correct the detected issues!
How much does web performance monitoring cost?
Monitoring is offered as an all-inclusive package, around €200 excl. VAT per month, regardless of your site's traffic. The scope covers the page types that matter: homepage, product listing, product page, checkout funnel, as well as your strategic SEO and SEA landing pages.
Beyond 150,000 page views per month, transparent sampling applies to collection. Percentiles remain statistically representative, and your bill remains the same regardless of traffic spikes. For a quote matching your scope, start the conversation via the contact form.
What is web performance monitoring?
Web performance monitoring is the continuous tracking of a site's loading times and Core Web Vitals to detect regressions as soon as they occur. It does not replace an audit, it extends it: the audit establishes a baseline, monitoring ensures it does not degrade.
An optimized site left unattended becomes slow again in a few months. An added extension, a trendy marketing script, a banner inserted on all templates : none of these actions are visible in isolation. It is their accumulation that causes metrics to drop, usually without anyone linking it to a specific change.
Monitoring addresses this drift by dating each variation. When a metric drops, the date of the break points to the responsible deployment, and the fix addresses the right cause. Without history, a slowdown is observed but not explained.
What is the difference between synthetic monitoring and RUM ?
Synthetic monitoring replays a load from a fixed machine and network at regular intervals. RUM collects measurements from the devices of your real visitors, on each page view. The former is reproducible, the latter is representative, and the two never give the same figures.
Each has its own use. Synthetic isolates a technical cause, compares two versions of a page, and serves as a non-regression test before going into production. RUM measures what your visitors experience, on connections and devices that you cannot simulate, and it is what Google uses to evaluate Core Web Vitals.
The best practice is therefore not to choose. We systematically cross-reference both sources: RUM signals a degradation for a segment of visitors, synthetic establishes the cause in a few minutes. Using synthetic alone is equivalent to measuring a fictional site, that of a single visitor under ideal conditions.
