Zenowebzenweb

Dubai · Website Care

Website speed optimization in Dubai — measured before, and measured after.

Field data from real visits sets the baseline, then the audit says where the milliseconds actually go before anything is touched. You keep the before and the after in the same tools, and a written performance budget each template is expected to hold.

  • Measured before anything changes
  • Every change staged first
  • Before and after, same tools

What's included

Six places the milliseconds actually go.

A site is rarely slow for one reason. It is slow in six places at once, in proportions no score can tell you, which is why the measurement comes before the work rather than after it.

  • A baseline taken from real visits

    Field data first — what your visitors actually experienced, on the templates that matter rather than the homepage everybody tests — with a lab trace beside it to explain why. The baseline is written down before anything is touched, because an improvement nobody measured beforehand is an opinion.

  • The payload, cut

    Images sized for the box they land in and served in a modern format, video posters instead of files that autoplay, and two years of uploads an editor has been dropping in at camera resolution. On most sites this is the largest single line in the loading budget and the least risky to change.

  • Third-party scripts, counted

    Every tag, pixel, chat widget and analytics script listed with what it does and who asked for it. Some are deferred, some are loaded on interaction, and the ones nobody can account for are removed with your sign-off. Third parties run on your main thread but never on your schedule.

  • Fonts, and the layout that jumps

    Webfonts subset and preloaded with fallback metrics matched, so text is readable immediately and does not reflow when the real face arrives. Space is reserved for images, embeds and banners. An Arabic face is a second full set of glyphs, which makes subsetting a larger decision here than elsewhere.

  • Responsiveness, not just loading

    Long tasks profiled on a mid-range phone rather than a laptop: hydration, event handlers and whatever the theme drags behind it. Loading metrics describe the first few seconds. Interaction delay is what someone feels when they tap a filter and the page thinks about it.

  • Server response, cache and edge

    Time to first byte measured from here rather than from wherever the server is, page and object caching configured, compression and cache headers set, static assets moved to the edge. It is also the point at which we say the host is the floor — no front-end work gets underneath a slow origin.

Who it's for

Three sites this fits — and one it doesn't.

The one it does not fit is the site whose slowness is structural. Where the platform, the theme or the data model is the cause, optimising around it buys a few hundred milliseconds and an invoice, and the audit will say so before you commit to anything.

  • A site failing Core Web Vitals in Search Console

    The report has been amber for months, it comes up on every SEO call, and the fix sits in the gap between a developer who left and a marketing team who cannot deploy. This engagement closes that gap: a diagnosis per template, and the changes actually shipped rather than listed.

    Your Core Web Vitals report has URLs nobody has claimed.

  • A store that is slowest where it earns

    The homepage tests well, because the homepage is the page everyone checks. The collection page carries sixty product images, the product page carries a review app and a wallet script, and the gap between how the site behaves on desktop and on a phone is already visible in your own analytics.

    Nobody has measured a product page — only the homepage.

  • A site that got heavy one campaign at a time

    Nothing broke it. A tag here, a pop-up there, a chat widget added for one quarter and never removed, and photographs uploaded straight from a camera. Weight accumulates in a way no single change is responsible for, which is exactly why it never gets fixed as part of anything else.

    Nobody can say what the fifth script in your tag manager does.

How we deliver it

Five stages, and the first one changes nothing.

Each stage ends in a number rather than an opinion, and every change is small enough that the number it moved can be attributed to it.

  1. 01

    Measure

    Field data for each key template read first, then lab traces on a throttled mobile profile to explain what it says. Ends with a baseline document and with agreement on which pages this engagement will be judged on.

  2. 02

    Profile and rank

    Where the milliseconds go on each template, with every fix costed against what it returns and marked for risk. This is also where the unwelcome findings go: where the cause is the host, the theme or the platform, and optimising around it is not worth your money.

  3. 03

    Fix on staging

    Changes made on a staging copy and grouped into batches small enough to attribute. Each batch is re-measured before the next begins, so a regression traces back to a change rather than to a fortnight of undifferentiated work.

  4. 04

    Ship, then measure again

    Released with the pages that take money checked first, then the same measurement repeated in the same tools on the same templates. Lab numbers move that day. The field verdict follows as real visits accumulate, and the report says both.

  5. 05

    Set the budget

    The numbers each template is now expected to hold, written down, with monitoring that says when they drift. Whoever holds it afterwards — your team or a care plan — is holding a documented figure rather than the memory of a good week.

Stack

Boring technology, chosen so the next developer recognises it.

Nothing here is exotic. That is the point: an unusual stack is a lock-in mechanism dressed up as innovation.

Front-end
Next.jsReactTypeScriptTailwind CSSAstro
CMS & commerce
WordPressShopifySanityPayloadWooCommerce
Infrastructure
VercelAWSCloudflareGitHub ActionsSentry

Deliverables

What you keep when the work is finished.

Two of these are documents another developer could take and reproduce the result from — which is the only real test of whether an improvement happened or was described.

  • A baseline document: field data and a lab trace for each key template, taken before anything was changed
  • A ranked diagnosis — where the milliseconds go on each template, with the fix, its risk and its cost beside it
  • The changes themselves, staged, checked and shipped, rather than a report recommending them
  • An inventory of every third-party script on the site: what it does, who asked for it, and which ones were removed
  • The same measurement repeated after launch, in the same tools and on the same templates
  • A written performance budget — the numbers each template is now expected to hold
  • Monitoring configured against that budget, pointed at a person rather than a dashboard nobody opens
  • A list of what we did not do and what it would take, including the cases where the answer is a different piece of work

The lab score moves on the day the changes ship. Google's verdict does not: its report is built from real visits at the seventy-fifth percentile over a rolling twenty-eight days, so Search Console confirms an improvement weeks after your visitors have already felt it. That is why the handover is a measurement you can repeat yourself rather than a screenshot we took on a good afternoon.

Pricing

What a speed engagement costs.

Quoted per site

fixed scope

Speed work is quoted after the measurement rather than from a price list, because the same symptom costs very different amounts on a hand-built site and on a theme carrying forty plugins. The findings are yours in writing whether or not the work follows, including the ones that say the money is better spent elsewhere. Holding the result afterwards is a care plan, from AED 1,500 a month. Prices exclude 5% VAT.

What changes the price

What that covers

  • Field and lab measurement before anything changes
  • A ranked diagnosis per template, not per site
  • Images, fonts, scripts and server response addressed
  • Every change staged and checked before release
  • The same measurement repeated after launch
  • A written performance budget, and monitoring on it
  • E-commerce and retail

    Weight arrives with the catalogue and with every app installed for one campaign — reviews, upsells, a wishlist, a currency switcher, two pixels. The pages that decide revenue are the collection and product pages rather than the homepage everybody tests, and at checkout a wallet script and a payment gateway both want the main thread at the same moment.

  • Real estate

    A listing page is thirty photographs, a map embed and a gallery script, and the photographs arrive from agents at whatever resolution the camera produced. Search results are the entry point for most visitors, so they carry many of those images at once — and a portal feed keeps adding listings faster than anyone reviews what they weigh.

Speed is one of three services in our website care practice and it is the one you commission once rather than keep paying for. If the site is slow because of where it lives rather than what it loads, the answer is a move rather than a tuning exercise — and it is the cheaper of the two.

Questions

Asked before anyone touches the site.

No, and a promise like that is a promise about the wrong number. PageSpeed and Lighthouse are lab tests on a simulated device — useful for diagnosis, but not the data Google reports on your site. That verdict comes from real visits, at the seventy-fifth percentile, over a rolling twenty-eight days. A site can score in the nineties in the lab and still fail on the phones your customers actually hold.

It is quoted per site, after the measurement, because the same complaint costs very different amounts depending on what is underneath it. A hand-built site usually needs a handful of targeted fixes; a theme carrying forty plugins needs untangling before anything can be measured cleanly. Keeping the result afterwards is a care plan from AED 1,500 a month. All prices exclude 5% VAT.

The site is faster on the day a batch of changes ships, and batches usually start landing within a week or two of the measurement. What takes longer is Google agreeing. Its Core Web Vitals report is built from real visits collected over a rolling twenty-eight-day window, so Search Console confirms the improvement weeks after your visitors have already experienced it.

Because caching answers one question — how quickly a page is assembled — and most slowness lives elsewhere. A cached page still ships the same oversized images, the same webfonts, the same six third-party scripts and the same main-thread work once it arrives. Stacked caching and optimisation plugins also tend to fight each other, and the setting that finally moves a score is often the one that breaks the cart.

Sometimes, and the measurement says which. If time to first byte is already slow before a single image is requested, the origin sets a floor that no front-end work gets underneath — oversold shared hosting and a server on another continent both do that. Where that is the finding we say it plainly rather than billing a tuning exercise against it. Where it is not, the hosting stays exactly as it is.

It can, which is why nothing is changed on the live site first. Every batch goes onto a staging copy, is checked on the pages that take money, and ships with a way back. The genuinely risky changes are predictable — caching over logged-in pages, deferring a script something else depends on, removing a tag marketing still relies on — so removals are signed off by you rather than assumed.

Yes, but less than the pitch usually implies: speed separates pages that are otherwise comparable, and it will not make a weaker page the better answer. The stronger argument is the visitor. Most UAE traffic arrives on a phone, often on a mobile network that behaves nothing like your office wifi, and a page that hesitates loses people before it is ranked against anything.

Yes, within the limits the platform sets. On Shopify the theme, the apps, the images and the scripts are all yours to change, and between them they account for most of what a storefront loses; the server layer belongs to Shopify. On a hosted website builder the ceiling is lower and reached sooner — we will tell you where it sits before quoting rather than after.

Ready to build something that lasts?

Tell us what you need. You will get a scoped response with an indicative price — from an engineer, not a salesperson.

No obligation. We reply within one working day, Monday to Friday.