Real web performance, for real
In every detail.

No. We aim for the best sustainable result for your site, keeping its content and features. The lab score also depends on test conditions and third-party resources: chasing 100 at all costs can lead to compromises that do little for the people using the site.

We start from the bottlenecks, set the priorities and verify the effect of our changes on the most important pages and journeys. We assess loading, stability and responsiveness together with field data, to deliver concrete benefits even when the device is less powerful or the connection slows down.

Yes. We work on WordPress, WooCommerce, PrestaShop, Magento, Joomla, Drupal and custom applications. We adapt the work to the project’s architecture, taking into account themes, plugins, modules, integrations and how the pages are generated.

The analysis covers the journeys that matter for your business: browsing the catalog, search, filters, cart, checkout and form submissions. In custom systems we also examine the relationship between application code, database and infrastructure. This way we identify the most useful changes and verify their effect on the features involved, instead of stopping at the homepage result alone.

We decide that after the analysis. We start from your current infrastructure to understand what is holding the site back and what can be improved with a more effective configuration. Caches and CDNs can be part of the solution when they really speed up content delivery and suit the application’s needs.

We examine response times, available resources, cache behavior and dynamic pages. If we find limits that prevent the goals from being reached, we explain which changes we recommend and why. Any decision to change hosting is therefore based on technical evidence, with attention to service continuity.

The first effects can be verified in controlled tests as soon as the changes are applied. We compare the pages before and after, in comparable conditions, and also check that menus, forms and checkout flows keep working correctly.

The CrUX data in PageSpeed Insights, on the other hand, reflects a rolling 28-day window: earlier results are gradually replaced by new user experiences. This is why the improvement in the field does not necessarily appear all at once. Timing and priorities depend on the complexity of the project, the integrations in place and whether there is enough data to assess the trend.

CrUX data describes the experience of real Chrome users, on different devices and connections. In PageSpeed Insights it covers the last 28 days and is available when there is a large enough sample. LABS data, by contrast, comes from a Lighthouse test in controlled conditions: it helps identify the causes of slowdowns and verify changes immediately.

We analyze them together: CrUX shows what happens in the field, while lab tests help you understand where to act. A good result in one does not make the other unnecessary. How Google distinguishes field and lab data ↗

A web cache is an excellent starting point: it can reduce the server’s work and the time needed to return a page that has already been generated. The browser, however, still has to download the assets, run JavaScript and build the interface. Heavy images, third-party scripts and layout instability can slow down the experience even with a very fast server response.

In addition, the cart, checkout, private areas and personalized content may need processing that the page cache does not cover. So we check both the responses served from the cache and those generated by the application, and we also work on what is left for the browser to do.

A score over 90 is a good sign, but it doesn’t describe the whole browsing experience. WP Rocket, FlyingPress, LiteSpeed Cache and WP-Optimize offer options to delay JavaScript until the user interacts. The initial test may then measure a lighter page, while part of the work is done at the first tap or scroll. Delaying can be useful, but it also has to be checked after the click.

The LiteSpeed Guest Optimization documentation also describes selective optimizations for certain requests, including those from PageSpeed Insights, bots and first visits, and warns that they can mask real problems. Excluding resources only for a tester can produce unrepresentative results: it is different from simply delaying scripts and has to be checked on the actual configuration.

So we compare resources, features and timings before and after the interaction, together with CrUX data. The goal is to reduce the work the site actually does, without hiding slowdowns behind a green number.

Work starts at around €600 + VAT, depending on the CMS, the complexity of the site and the activities required. A brochure website, an e-commerce store and a news portal may need very different analysis and changes: templates, integrations, custom code and the state of the infrastructure all matter.

The work is always defined on the basis of a quote, with an agreed scope and clear priorities. We assess the project before confirming the cost, setting out the planned work and the checks included. The starting price is therefore an indicative reference, not a flat rate that applies to any site.

We don’t stop at the homepage. We select pages that represent the different page types on the site: articles, categories, product pages, search and checkout flows. Many slowdowns depend on shared templates, components or assets: fixing them at the source can extend the benefit to every page that uses them.

The scope is agreed during the analysis, separating shared changes from issues in individual sections. On a very large archive there is no need to handle every URL by hand: we check the shared templates, the exceptions and the dynamic features. The result is assessed on a meaningful sample, without treating the homepage alone as representative of the whole project.

The goal is to keep the site running and to plan the changes around its activity. When one is available and suitable for testing, we use a staging environment to try out changes before publishing them. The most delicate changes are agreed taking traffic, orders and editorial updates into account.

Before release we define the checks and the rollback procedures needed. If an activity requires a maintenance window, we flag it and plan it together with you. After publishing we check the behavior in the live environment, including cache, integrations and the main journeys: business continuity matters as much as better performance.

Yes. Working with the people who already know the site helps us understand the application choices, customizations and constraints of the project. We share the issues we find and agree on priorities, responsibilities and how to proceed, linking the work on the code to the needs of the infrastructure.

We agree on who applies the changes and how to verify them, respecting the development and release workflow already in place. We can support the team in diagnosing and validating the changes, documenting the technical decisions. The goal is a more efficient site, with useful guidance left for whoever will keep developing and maintaining it.

We design the changes to be maintainable, favoring approaches that fit the CMS architecture and minimizing changes that updates could overwrite. This doesn’t mean performance stays the same forever: new versions of themes, plugins or modules can introduce different assets, dependencies and behavior.

That is why we document the changes and what to re-check after major updates. The method includes a new scheduled analysis every four months, to catch regressions and new opportunities for improvement. Periodic checks make it possible to assess how the site evolves, without mistaking an initial piece of work for a guarantee of performance that never changes.

A powerful computer with a stable connection can hide problems that become obvious on a less capable smartphone. The device has to download the assets, process HTML and CSS and run JavaScript: a slower network or a slower CPU can lengthen the wait and make interactions less responsive.

The cache already in your browser can also make your usual browsing faster than a first visit. That is why we compare different devices and conditions, looking at loading and interactions. We combine controlled tests with the field data available, to understand what users experience beyond a single test on the site manager’s computer.

We compare the same page types before and after the work, using comparable test conditions and repeated measurements when needed. The work summary links the changes applied to the problems found, so you can see where we intervened and what effects we observed.

The checks cover loading, visual stability and response to interactions, together with how menus, forms and checkout flows work. When available, we also follow CrUX data, taking its collection window into account. We make both the improvements and any remaining limits explicit: a single screenshot with a green score does not, on its own, describe the result of the work.

Yes. Missing CrUX data may simply mean the sample is too small, and it does not prevent us from analyzing the site. We use lab tests, browser diagnostic tools and checks on the main journeys to find heavy assets, execution delays and layout instability.

When data is missing for a single URL, we check whether origin-level data is available, keeping it separate from the page’s results. If that is missing too, we document what the tests can verify and their limits. We can consider collecting real measurements specifically for the project, without presenting lab results as experiences actually recorded from users.