When a site takes six or seven seconds to appear on a phone running on 4G, the sentence spoken in the meeting is almost always the same: we need to rebuild the site. That is rarely the right conclusion, and it is almost always the most expensive one.
Slowness is a symptom, not a diagnosis. It can come from a 4 MB photo uploaded straight from the back office, a chat widget installed two years ago and never removed, a shared hosting plan that chokes at the end of the day, or a theme that loads eleven font files before showing the first headline. Those causes do not cost the same to fix, and they do not take the same time.
You can sort between them yourself, for free, in about twenty minutes, before calling a single provider. Three tests and five numbers are enough to tell which side the problem sits on.
The “rebuild it” reflex and what it misses
A redesign changes the design, the site structure, sometimes the CMS. Speed only improves if the specification demands it explicitly, with numeric thresholds and an acceptance measurement. Without that condition, sites regularly come back slower than before, because the new theme ships a full-screen carousel, scroll animations and two font families pulled from three different domains. Prettier and slower is the worst of both worlds when most of your Moroccan traffic arrives on a phone.
The second reflex, moving to a more expensive hosting plan, has the same weakness. Doubling the RAM does not compress your images and does not stop an ad tag from blocking rendering. A bigger server sometimes hides the problem for a few months, then the monthly invoice stays and the slowness returns. The other traps in that kind of decision are covered in our piece on website redesign mistakes in Morocco.
So the useful question is not how much a redesign costs. It is which line of the loading waterfall takes the longest, and why.
What actually slows down a Moroccan website
On the SME sites we open up, four families of causes keep coming back, and they are not equivalent in price or in effort.
Images. This is the number one cause by a wide margin. The marketing team uploads 3 to 5 MB visuals straight out of the camera, the CMS displays them inside a 600 pixel wide block, and the browser still downloads the whole file. On an e-commerce catalogue, that effect is multiplied by the number of thumbnails on the page.
Third-party scripts. Google Tag Manager, the Meta pixel, a chat tool, a consent banner, an interactive map, a reviews widget. Each one looks harmless. Together they add dozens of requests to domains you do not control, and some of them block rendering until they answer. Consent scripts deserve particular attention, for speed as much as for your site’s CNDP compliance.
The server. An overloaded shared plan, an old PHP version, no page cache, a database nobody has cleaned in five years. The giveaway: the site is slow even on a page that contains almost nothing.
Code and theme. A generic theme stuffed with unused features, twenty active plugins of which six do the same job, unminified CSS and JavaScript. This is the most expensive cause to fix, and the only one that sometimes justifies a technical rebuild.
Three tests to run yourself before calling a provider
No paid tool is needed. Always test at least two pages: the homepage, usually the most polished one, and a page people actually land on (a product page, a service page, a blog post). They rarely score the same.
- PageSpeed Insights. Start with the mobile tab, not desktop. The tool shows two blocks: real-user data, measured on your actual Chrome visitors over the last 28 days, and lab data, simulated. If the first block is missing, your traffic is too low to be aggregated and you have to work from the second. Write down the mobile LCP.
- GTmetrix, for the waterfall. The waterfall report shows every file loaded, in order, with its duration. Record three numbers: total page weight, number of requests, and TTFB (how long the server takes to send the first byte). Useful markers: above 3 MB on a brochure page the problem is visual; above 80 requests, look at third-party scripts; a TTFB above 600 ms that repeats points at the server.
- The repeat test. Run the same measurement three times, twenty minutes apart, including once in the late afternoon. The first run often hits a cold cache and gives an unfairly bad result. If the three runs differ by a factor of two, your hosting is unstable, which is information in itself.
Add a fourth test that produces no score but tells you a lot: open your site on your own phone, on mobile data, with the office wifi switched off, somewhere the signal is imperfect. The mobile site speed your customers live with looks more like that than like a score out of 100.
Reading Core Web Vitals without the jargon
Three indicators are enough to point the diagnosis, and each answers a concrete question.
- LCP: how long it takes to paint the largest visible element on screen, usually the hero image or the main heading. Target is under 2.5 seconds. A bad LCP almost always points at that image or at server response time.
- CLS: visual stability, meaning how much content jumps around while the page loads. Target is under 0.1. The usual culprits are images without declared dimensions and banners (cookies, promotions) injected afterwards, pushing the text down exactly when the visitor was about to tap.
- INP: the delay between a visitor’s tap and the page visibly reacting. Target is under 200 milliseconds. A poor INP nearly always means too much JavaScript running at once.
Two honest caveats. Core Web Vitals count in Google ranking, but as one signal among many: moving from poor to good does not compensate for thin content. The commercial effect, on the other hand, is direct and measurable in your own numbers, in mobile bounce rate and in checkout abandonment.
What depends on the server and what depends on the code
There is a simple separation test. Measure a nearly empty page on your site, typically the legal notices, then the homepage. If the empty page answers in 300 ms and the homepage takes 2 seconds, the server is fine and the problem lies in what the page loads. If the empty page also takes more than a second to respond, the problem sits underneath: hosting, missing cache, PHP version, database queries.
In the first case nobody needs to change host. In the second, check the server cache and the configuration before concluding that you lack power. If the machine really is undersized, our guide to choosing a VPS in Morocco and the one on cloud hosting budgets give the orders of magnitude to expect.
CDNs deserve a clarification, because they get sold as a universal fix. A CDN serves your static files (images, CSS, JavaScript) from points of presence close to the visitor. For a Moroccan audience served from a European datacentre, that saves tens of milliseconds, not seconds. Worth having, especially if you also target the diaspora or West Africa, but no CDN Morocco setup will rescue a homepage that waits 1.8 seconds for an application response.
Pricing the fix: what a slow website Morocco audit costs in 2026
A serious web performance audit is not a PageSpeed screenshot emailed over. It covers the main templates (home, category, detail page, form), field data and lab data, the loading waterfall, server configuration and caching. Then it delivers a prioritised list: each fix with the expected gain, the effort required and the risk of breaking something.
The ranges seen in Morocco in 2026: budget 3,000 to 8,000 MAD for a brochure site with a handful of templates, and 10,000 to 25,000 MAD for an e-commerce site or a business application, where database queries and behaviour under load also need examining. Implementing the fixes usually lands between 6,000 and 30,000 MAD depending on depth. A full technical rebuild runs into tens of thousands of dirhams and several weeks of work.
Two warning signs in a proposal. A provider who announces that everything must be rebuilt before measuring anything is selling a project, not a diagnosis. And one who plans no measurement after the work will never be able to prove the gain: ask for a before and after comparison protocol, on the same pages, at the same times of day, mobile included.
Targeted fix or technical rebuild: how to decide
Once the tests are done, the decision is far simpler than it looked.
A targeted fix is enough when page weight is dominated by a few images, when the plugin list has obvious duplicates, when TTFB is healthy and the theme is still maintained by its vendor. In that situation, image compression and modern formats, lazy loading, a clean-up of third-party scripts and a proper server cache do most of the work, often within days.
A technical rebuild becomes defensible when every optimisation fights the theme, when the site runs on a CMS or framework version that no longer receives security patches, when nobody knows what half the code does, or when a new functional need was on the roadmap anyway. Speed then becomes a benefit of the project rather than its justification. Either way, plan the recurring budget that keeps the gain alive, something we covered in detail on the real cost of website maintenance.
Where to start this week
Run the three tests on two pages, note the mobile LCP, total weight, request count and TTFB, then reread the price ranges above with those numbers in hand. You will know whether you have a 5,000 MAD problem or an 80,000 MAD problem, and you will be able to talk to any provider as an equal. Arrowlancer works on exactly this as part of its websites and web applications practice: a priced audit, then fixing the causes it identifies, from image optimisation to a hosting migration. If your own measurements show a real bottleneck, tell us about it through the contact form.
Frequently asked questions
Does hosting in Morocco make my site faster?
For Moroccan visitors, yes, by a few tens of milliseconds of network response time. That is real but marginal next to a 5 MB page. Local hosting is justified more by support proximity, billing in dirhams and certain data-location requirements than by raw speed.
Does Google really downrank a slow site?
Core Web Vitals are part of the ranking signals, but they weigh less than content relevance and inbound links. With equivalent content, the faster site wins. The real cost of slowness shows up first in your own analytics: mobile visitors leaving before anything paints, carts abandoned at the payment step.
How long before an optimisation shows in the numbers?
Lab measurements change immediately after deployment. Google’s field data is computed over a rolling 28-day window, so expect roughly a month before the report settles on the new values. Do not judge a performance project on three days of data.
Do I need a CDN if my audience is only in Morocco?
It is not the first thing to spend on. Start with images, caching and third-party scripts. A CDN becomes interesting if you serve heavy files, if your audience spills beyond the country, or if you also want protection against traffic spikes.