Why site speed decides whether visitors stay

By Youssef Mahmoud Soliman, founder of YMS Studio · Updated 28 July 2026

Here is the uncomfortable truth about websites: most visitors decide whether to stay before your page finishes loading. If it takes more than a couple of seconds on a phone, a big share of them are gone. They do not complain. They do not come back. They just tap away, usually to a competitor.

This is what frontend engineering is really about. Not fancy code for its own sake, but a site that opens fast on a cheap Android phone with weak signal, because that is how a lot of your real customers will see it.

What makes sites slow

Usually it is weight. Template builders stack plugins, trackers, and bloated themes until a simple page carries megabytes of things nobody asked for. Every add-on solves someone's problem and slows down yours. The fix is not another plugin. The fix is less: clean code that does exactly what your site needs and nothing else.

Images are the first offender nearly every time. A photographer sends four-megabyte files straight off the camera, someone uploads them untouched, and a phone downloads every one before anything useful appears. Sized properly and converted to a modern format, the same photos weigh a fraction of that and look identical.

Fonts are the quiet one. Every weight is another file the browser waits for, and a bilingual site loading four Arabic weights and four Latin ones has queued eight downloads before the first sentence. Then comes plugin stacking: a slider, a cookie banner, a chat widget, two analytics tools and an ad pixel, each with its own JavaScript, each loading on pages that never use it.

The last cause is invisible. A render-blocking script sits in the head of the page and stops the browser drawing anything until it has been fetched and run. On fibre that is a fraction of a second. On a phone on a congested 4G cell it is several seconds of white screen, and a white screen looks like a broken site.

The three numbers Google measures

Google bundles this into three metrics called Core Web Vitals and publishes the thresholds on web.dev. They are measured on real Chrome visits to your site rather than a machine in an office, which is why they are hard to game.

Largest Contentful Paint (LCP): under 2.5 seconds

How long the biggest thing on the first screen, usually your hero image or headline, takes to appear. It is measured at the 75th percentile, so three-quarters of visits have to beat it. Not your fastest visit, not your average. The slowest quarter of your audience decides, and in Egypt that quarter is slower than most agencies assume.

Interaction to Next Paint (INP): under 200 milliseconds

The lag between someone tapping and the screen visibly responding, and 200 milliseconds is the good threshold. It catches sites that look fast and feel dead: you tap add to cart, nothing happens, you tap again, and now there are two in the basket. Heavy JavaScript is nearly always the reason.

Cumulative Layout Shift (CLS): under 0.1

How much the page jumps while it loads. You know the feeling: you reach for a link, an image finishes loading above it, everything shoves down, and you tap the wrong thing. Images and embeds that never reserve their space cause it. Set the width and height, and the browser holds the room.

Why this hits harder in Egypt

Most performance advice assumes a desktop on a corporate connection. Your audience is a phone. Most Egyptian traffic is mobile, on 4G that swings with the hour and the district: the handset that loads instantly on home Wi-Fi crawls on the ring road at six in the evening. The HTTP Archive's Web Almanac tracks this every year, and mobile pass rates trail desktop every time.

It compounds where you collect money. Cash on delivery, Fawry, Paymob and InstaPay each add steps to the checkout: a redirect, a reference number, a one-time code. A slow page between those steps loses a customer you already paid for. The same holds before iftar in Ramadan and the week before Eid, when traffic peaks and networks are congested.

How to test your own site

Run your URL through PageSpeed Insights. The score out of 100 is a lab simulation. The field data above it comes from real Chrome visits over the previous 28 days, and that is what Google uses.

Then do what almost nobody does: open the site on a mid-range Android, on mobile data, and count how long you stare at nothing. Do the same to your two closest competitors. Search Console's Core Web Vitals report groups failing URLs by template, so you learn which page type is dragging the site down.

What fast looks like

Our target is simple: the first screen of your site should appear in under a second on an average connection. We get there by writing the code ourselves instead of assembling templates, keeping images lean, and cutting every script that does not earn its place.

Speed also feeds everything else. Google ranks faster sites higher. Ads cost less when landing pages load quickly. And a visitor who is not waiting is a visitor who is reading, scrolling, and buying.

In practice a fast build is a list of unglamorous decisions. Images sized and converted before they reach the page, with dimensions set. Fonts cut to the weights actually in use, Arabic and Latin subsets separated. Third-party scripts limited to what earns its place. Caching at the edge so a visitor in Riyadh is not waiting on a server in Frankfurt. And checking the numbers monthly, because sites launch fast and slow down quietly.

The honest limit

Speed alone will not rank you. Google is direct about it: page experience is a tiebreaker, not a trump card, and a fast page with nothing on it loses to a slow page that answers the question. We have seen sites scoring 100 sit on page four with nothing worth linking to. If you are invisible on Google, the problem is usually what search engines and AI assistants actually read, plus local SEO and authority.

Where speed decides things is at the margins, and the margins are where the money is. It lowers what you pay per enquiry on ads, because you keep more of the traffic you already bought. It will not win you an audience; it stops you losing the one you paid for. The five-language IGBS site has to open in Arabic as fast as it does in English, and every site we build in Egypt is held to that test.

Frequently asked questions

How fast should a website be?

Google's thresholds are a useful floor: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, at the 75th percentile of real visits. Our own target is stricter: the first screen visible in under a second on an average Egyptian mobile connection. The threshold is where the penalty stops, not where the advantage starts.

Do Core Web Vitals actually affect Google rankings?

Yes, but less than the people selling performance audits imply. They are one signal among many and work as a tiebreaker between pages of comparable relevance. A fast page with weak content will not outrank a strong slow one. What they reliably change is what a visitor does after arriving, which affects revenue either way.

Why is my WordPress site slow?

Usually plugins. Each one loads its own scripts and styles on every page, including pages that never use it, and a theme built to suit everybody carries code your site does not need. Add unoptimised images and cheap shared hosting and you have the standard picture. Trimming plugins and fixing images solves most of it.

Can a slow site be fixed, or does it need rebuilding?

Often it can be fixed, and if it can, fix it. Compressing images and cutting scripts and fonts take most sites from bad to acceptable for far less than a rebuild. Rebuild when the platform itself is the ceiling, when every fix is undone by the next update, or when the site needs to change for other reasons anyway. Paying for a rebuild to gain a second is rarely worth it.