Ruby on Rails for a Dubai startup: where it still makes sense, and where it does not
Where Ruby on Rails still makes sense for a Dubai startup, UAE hiring realities, and when a founder should choose something else.
Read the articleCore Web Vitals in Dubai tend to arrive as a red score in a report somebody forwarded, with no explanation of what the three measurements are or which of them is actually costing you anything. The report is usually right that something is wrong and usually unhelpful about what.
This explains what each number measures in ordinary terms, why the figure on your laptop disagrees with the figure Google holds, and which fixes return the most for the least work.
The three Core Web Vitals, in plain terms
Each of the Core Web Vitals in Dubai describes a different kind of irritation, and the published definitions are the reference if you want the precise thresholds.
Loading. How long until the largest thing on the screen appears. Usually the hero image or the headline. This is the one people feel as the site being slow, and it is the measurement most often failed by a decorative banner nobody asked for.
Responsiveness. How long the page takes to react when somebody taps or clicks. A page can look finished while the browser is still busy, and a tap that does nothing for half a second is the single most common reason somebody taps again, then leaves.
Layout stability. Whether things move after they appear. An advertisement or image that loads late and pushes the content down, causing somebody to press the wrong thing, is measured here. It is the most irritating of the three and often the easiest to fix.
Note what is not measured. None of these say anything about whether the page is useful, which is why treating them as a ranking strategy misreads what they are for. They describe the experience of waiting, not the value of what you waited for.
Why your Core Web Vitals in Dubai look different to everyone else’s
There are two kinds of Core Web Vitals number and people constantly confuse them.
Lab data. A simulated load on one machine, which is what a tool on your laptop produces. Useful for diagnosis because it tells you what took the time. Not a grade, because it reflects one simulated visit rather than your visitors. The tooling is explicit about this distinction.
Field data. Measurements collected from real visits over a rolling period. This is what Google uses, and it is the one to manage.
Three local consequences. Testing from your own office tells you about your office connection, not your customers, and on a strong corporate line everything looks fine. Your field data is dominated by phones rather than the desktop you built the site on. And if a meaningful share of your visitors are outside the region, physical distance to the server becomes part of the result in a way a local test will never reveal.
This is also why one slow test is not an emergency and a steady pattern in the field data is.
Which Core Web Vitals problems to fix first
In rough order of return for effort on a typical business site, these are the Core Web Vitals repairs in Dubai worth doing first.
Images. Almost always the largest single cause. Photographs exported at the dimensions a camera produced, served to a phone that needs a fraction of that. Correct sizing, modern formats and lazy loading for anything below the fold usually move the loading measurement more than everything else combined.
Third party scripts. Chat widgets, heat mapping, several analytics tools, advertising tags, a review embed. Each was added by somebody with a reason and nobody ever removes one. Audit what is loading and delete what nobody reads.
Fonts. Custom fonts loading late cause both a delay and visible text movement. Limiting the number of weights and loading them correctly is a small change with a visible effect.
Reserved space. Giving images, advertisements and embeds a defined size before they load fixes layout movement almost entirely, and it is the least demanding item on this list.
Server response. If the first byte is genuinely slow, nothing after it can be fast. This is where hosting and caching matter, and where our note on where a site is hosted becomes relevant.
The traps specific to this market
A few things recur on sites built for audiences here, and each one damages Core Web Vitals in Dubai more than it appears to.
Heavy hero video. An autoplaying film of a skyline is the most expensive element on many sites here, it delays the measurement that matters most, and it is usually the first thing a visitor scrolls past.
Two languages, loaded twice. A bilingual site that ships both the Arabic and English fonts and assets to every visitor doubles a cost nobody needs to pay.
Marketing tags added during campaigns. Tags arrive for a campaign and stay forever. Review the container quarterly and remove what is finished.
Sliders on the home page. Several large images, a script to rotate them, and measurable damage to loading, in exchange for a feature that analytics usually shows nobody interacting with beyond the first slide.
One connected point. Many of the fixes that improve these numbers also help people using the site with assistive technology, and the accessibility guidelines overlap here more than most proposals mention. Reserved space, readable text and predictable layout serve both.
Managing Core Web Vitals in Dubai without rebuilding the site
A full rebuild is rarely the right answer to a performance problem, and it is frequently what gets proposed.
Good Core Web Vitals in Dubai are usually recovered rather than rebuilt. Start by finding out which pages matter. A site has a handful of pages carrying most of the traffic and most of the enquiries. Measuring the home page and ignoring the service page that actually converts is a common waste of a morning.
Then fix the template rather than the page, since most sites have perhaps five templates behind hundreds of addresses. One correction to a template applies everywhere.
Then measure again in the field after a few weeks rather than immediately, because the data is collected over a rolling window and will not update the day you deploy. This delay catches people out and leads to perfectly good fixes being reversed because nothing appeared to change.
If after all that the site is still slow because of how it was built, that is a genuine case for rebuilding, and it is a different conversation with a different budget.
Keep a note of what was changed and on which date. When the field data moves a month later, that note is the only way to attribute the improvement to anything, and without it the next person to look will repeat work that was already done.
What good enough Core Web Vitals look like in Dubai
Perfection is the wrong target for Core Web Vitals in Dubai. Three questions are more useful than a score.
Does the main content appear quickly on a mid range phone? Not your phone. Borrow a modest one from somebody in the office and try your own site on it.
Does anything move while you are reading? If yes, somebody did not reserve space.
Does the first tap do something immediately? If there is a pause, the page is still busy with work that could have waited.
A site that answers those three well will usually be in reasonable shape on the formal measurements, and the remaining distance to a perfect score is rarely worth what it costs to close.
The sensible stopping point is where further gains stop being visible to a person. Shaving a fraction of a second off a page that already feels immediate changes nothing a visitor can perceive, and the same budget spent on what the page actually says will do more for the enquiries you receive from it.
Where to read next
For the work, speed work covers what we change and in what order, and maintenance is what stops a fast site slowly becoming a slow one.
If you are planning a rebuild anyway, how a build runs and what drives the figure are the places to start, and performance is far less expensive to design in than to retrofit.
Where the slow part is an application rather than a page, a portal, a search, a dashboard doing real work, the problem is usually in the system behind it rather than in the front end. Codeeo handles that engineering in Dubai.
If somebody has sent you a red score and you want to know which parts of it matter, send us the report and we will tell you what we would fix and what we would ignore.
