Response times
We review pages and paths where wait times affect use, including when filters are combined.
Services › Impact and evolution › Web performance and accessibility
Web performance and accessibility
We measure and improve the technical conditions that affect how the site is actually used: response times, load times, caching, dependencies, links, structure, and accessibility criteria.
Each intervention starts from an observable condition and is verified again afterward. The goal is to know what changed, not to pile up optimizations without a prior baseline.
What feels fast in the admin interface may not feel fast to visitors.
Measure first to know what's worth changing.
Caching and queries
We analyze what the site can reuse and what forces it to recalculate, and act on the cause we find.
Images and resources
We review file sizes, formats, lazy loading, and dependencies that affect the experience on different devices.
Links and security
We detect insecure references, legacy dependencies, and external links that need technical adjustments.
Accessibility
We work on accessible names, semantic structure, navigation, contrast, and other criteria that can be verified on the site.
AaContrastKeyboard
Verification
We test each change the way a visitor sees it, logged out and in different scenarios.
How it works
A technical improvement needs a before and an after.
Measurement
We record the starting condition with a repeatable test.
Diagnostic review
We look for the layer that explains the behavior: query, cache, resource, dependency, template, or configuration.
Intervention
We apply the narrowest change that solves the cause without creating unnecessary risk.
Verification
We repeat the test on the public-facing experience and document the result.
If the improvement doesn't show up, the work goes back to diagnosis.
Work · SAI
From 2.6 seconds to 0.18 seconds for one catalog filter combination.
In August 2026, we found that part of SAI's filtered catalog was running queries without using the cache correctly. The log showed 13,114 executions per day under that condition.
FAQ
Our site is slow: does it need to be rebuilt?
Not necessarily. Slowness usually comes from one specific layer, such as caching, catalog queries, or image size, and that can be fixed without changing the design. At SAI, a caching intervention brought the filtered catalog down to 0.18 s. If the cause is in the structure, the diagnosis shows it.
Does anything break when migrating to a new site?
Something usually does: internal links pointing to the old site, chained redirects, PDFs with no destination, and incorrectly tagged language versions. A full crawl after launch finds these issues. At SAI, 511 redirects were audited through to their final destination, and none were broken.
Does speed affect rankings?
It's one of the many signals Google takes into account. A more immediate issue is that a healthcare professional opening a product page on their phone won't wait. Improving speed doesn't guarantee a ranking, and we don't promise one.
Can performance be improved without changing servers?
It depends on where the time is being spent. First, we measure how much of the delay comes from the server, queries, images, or code. If the server is the limit, we say so based on the data.
What does accessibility have to do with performance?
Both are part of keeping the site technically sound: making it work for everyone who uses it, including people who navigate with a screen reader or a keyboard. If the company has accessibility obligations in a country, its legal team defines them, and we implement on the site whatever it decides.