Website speed optimisation and Core Web Vitals

What do you gain by optimising your website's speed?

A visitor never sees your code. They see a blank page, a button that does not respond, a paragraph that jumps just as they were about to tap. Each of those moments is a reason to go back to the search results. Website speed optimisation is the work of removing those reasons, one by one.

The cost of a slow site rarely shows up on a dashboard. It hides in the enquiries that never arrive, the abandoned baskets and the paid clicks that leave before the offer has even loaded. That is why a performance engagement starts with the pages that matter commercially, not just the homepage.

What do Core Web Vitals actually measure?

Google sums up page experience in three metrics, assessed at the 75th percentile of visits, separately for mobile and desktop (source: Google, web.dev documentation). In plain terms, at least three visits out of four must meet the threshold.

If an old report still mentions FID, it is out of date: INP replaced it within Core Web Vitals (source: Google Search Central).

Why is a good PageSpeed score not enough?

PageSpeed Insights shows two measurements that are often confused. At the top, field data: what real Chrome users experienced over a rolling window of roughly four weeks, taken from the CrUX report (source: Google, Chrome UX Report documentation). Below it, a Lighthouse lab test: a single load, simulated on a typical device and connection.

The score out of 100 comes from the lab. It helps you diagnose; it does not pass judgement. A page can post a flattering score and still fail INP for your real visitors, because the test never clicks anything. Our target is therefore passing all three field metrics on the pages that earn money, not a number to show in a meeting.

If your site has too little traffic to appear in CrUX, we add lightweight measurement on your own visitors: the same metrics, page by page.

Where does slowness usually come from?

The causes repeat from one site to the next, and many can be fixed without rebuilding everything:

• Oversized images: a banner photo exported at full resolution, without a modern format or declared dimensions.
• Accumulated third-party scripts: ad pixels, chat, maps, embedded video and analytics tools added campaign after campaign and never removed.
• A heavy theme or too many plugins: a page builder, modules loaded on every page when only one page uses them.
• Poorly loaded fonts: several families and weights downloaded in one go. Arabic fonts, with their larger glyph sets, often weigh more than their Latin counterparts.
• A distant server or no caching: every visit rebuilds the page, sometimes from hosting located far from your visitors.
• Too much application JavaScript: entire libraries shipped for a single animation or form.

On an online shop, the product page often concentrates these problems: photo gallery, reviews, recommendations, payment.

Your audience changes the order of priorities. If your visitors are mainly in Tunisia and browse on mobile networks, page weight and JavaScript come first. If you sell in France or elsewhere in Europe from a server hosted far from your customers, server response time and caching matter more. For a Gulf audience, an Arabic-first site needs lighter fonts, a stable RTL layout and files served from a delivery network with a presence in the region.

How does a performance engagement work?

1. Baseline measurement. Field data, the Search Console Core Web Vitals report and lab tests on a sample of pages, on mobile and desktop.
2. Template-level diagnosis. Each page template is analysed separately: hero image, scripts, fonts, server response.
3. Prioritised plan. Each cause gets an impact and effort estimate. You approve the order before we touch the code.
4. Fixes on staging. Each batch is compared against the baseline, then checked: forms, analytics, and display in French, English and Arabic.
5. Release and monitoring. Field data refreshes gradually. The final review waits until the measurement window fully covers the new version.

For the audit, have read access to Search Console and your analytics ready, along with a list of the pages that bring you enquiries or sales. Fixes are then made in your repository and on your hosting, with your access: you keep the code, the accounts and the change history.

Should you optimise the existing site or rebuild it?

In almost every case, start by optimising. Compressing images, sorting out third-party scripts, enabling caching and loading fonts properly are quick, reversible actions. They often resolve a good part of the problem without touching the design or the content.

Optimisation does have a ceiling, though. When a page builder produces heavy code everywhere, when the platform cannot be cached, or when every fix breaks something else, patching costs more than rebuilding. In that case we say so early and scope a redesign with migration to Next.js, with a redirect plan to protect your search visibility.

WordPress and PrestaShop are not mistakes in themselves: properly configured, they can be fast. Our comparison Next.js or WordPress explains when each one makes sense.

How do you keep a site fast over time?

A site rarely slows down all at once. It slows down through additions: a homepage video, a new pixel, one more plugin. Without rules, the gains from an engagement can fade within months.

So we leave a written performance budget: maximum weight per template, thresholds to respect, a list of approved scripts. An automated check verifies those thresholds at every release or on a regular schedule.

Why work with AD AZUR DIGITAL on this?

Because we do not stop at recommendations: we implement the fixes ourselves. Based in Sfax, our team builds websites and web applications with Next.js and TypeScript, and also takes over existing WordPress and PrestaShop sites. Performance is part of technical SEO: when the audit justifies it, we handle it alongside indexing and structured data.

We work in French, English and Arabic, for companies in Tunisia, Europe and the Middle East. Tunisia sits at UTC+1 all year round, so our meetings fall within the working day in Paris and in Dubai.

What we do not promise: a position on Google. Core Web Vitals are among the page experience signals, but content relevance remains decisive (source: Google Search Central). A fast, empty site does not rank. A fast, useful site is better at keeping the visitors your content has earned.

To get started, request a free audit: we measure your key pages, tell you what can be fixed, in what order and with what effort, then quote the work on that basis.