Why is the app fast for us and slow for customers?

Because it was tested on a recent phone over wifi and is used on older phones over 3G or a shared wifi. A screen making twenty calls and loading five megabytes goes unnoticed on fibre and takes ten seconds on 3G. We build and measure for your customers’ phone and network, at the 75th percentile, not for the developer’s.

Do we need a more powerful server?

Almost never first. Five of the six slownesses are fixed in the code: screen weight, images, pagination, request per row, indexes, cache. A screen making one call instead of twenty is fast even on an average server. The server comes sixth, after measurement, and the hosting guide then says where to place it.

What is a performance budget?

Six figures per screen, written before the code and checked at every delivery: first-screen weight, visible images, scripts before display, number of requests, API response time at the 75th percentile, and main content displayed in 2.5 seconds on a 2019 Android over simulated 3G. A version exceeding one of these values is not delivered until fixed.

Why the 75th percentile and not the average?

Because the average hides the worst-served quarter of users. The 75th percentile is the time below which three customers out of four fall; it is the point Google’s public thresholds ask to measure, separately on mobile, and the one we write into the contract.

How long to make an application fast?

Six weeks: one to measure on real users and write the budgets, one for screens, one for the API, one for the database, one to measure on an old phone over simulated 3G and load the API, one to put the budget into the delivery pipeline. The first week has no code, and it decides the order of the other five.

Is your application slow at your customers’ in Algeria? What gets built in 2027 to make it fast on a weak network: screen weight, cache, pagination, indexes, and measurement on your real users

Short answer. An application is slow for five reasons fixed in the code and one fixed in hosting. The five: screens that load the whole code and 4 MB original images; lists with no pagination; one request per row instead of an aggregated call; searches with no index; and everything reloaded at every opening for lack of a cache. What gets built: a budget per screen written before the code, five hundred kilobytes, three requests, main content displayed in 2.5 seconds on a 2019 Android over simulated 3G; images resized and converted on upload; one API call per screen, paginated, compressed, cached; indexes on what is searched and sorted; and measurement at the 75th percentile on real users, per screen and per network, checked by the delivery pipeline. Six weeks, the first without a line of code.

This guide is for the manager whose sales staff wait in front of the screen, the founder settled in France who only sees the app from a fibre connection, and the person who must compare one “optimisation” quote with another. It does not repeat where to place servers, described in the hosting guide, nor how an app works without network, described in the synchronisation guide; it describes what is built so that it is fast when there is network, even bad, and extends our page on software engineering.

What the figures say

Speed thresholds have a public definition, and it is demanding. The indicators Google uses to judge a page, the Core Web Vitals, set three “good” thresholds: main content displayed “within 2.5 seconds” of the start of loading, a reaction to gestures of “200 milliseconds or less”, and a visual shift of “0.1 or less”; and they ask to measure “the 75th percentile of page loads, segmented across mobile and desktop devices”. What this imposes: you do not measure an average, which hides the worst-served quarter of users, but the point below which three customers out of four fall; and you measure it on mobile, separately.

Images are the first item, and the gain is documented. Google states that a lossy WebP image is “25-34% smaller than comparable JPEG images” at equivalent quality, and that lossless it is “26% smaller” than PNG; but the gain that really counts comes before the format: a photo taken on a phone weighs several megabytes and is displayed in a 300-pixel square, and resizing it to that size divides its weight by ten or more before any conversion. What this imposes: images are resized and converted on upload, server-side, in several sizes, and the screen asks for the size it displays.

Your customers’ network is not the developer’s, and public figures will not tell you which one it is. Published mobile speed medians for Algeria vary widely by source and period, roughly forty to seventy megabits per second in 2025 and 2026 reports drawing on Speedtest measurements; we keep none of these figures, because a national median says nothing about the salesperson in the back room on 3G or the customer in a basement. What this imposes: real timings are collected from your users, by network type and by wilaya, and you build for the 75th percentile of what was measured, not for the national average. What we did not find: a public study of the phones actually used in Algeria by year of manufacture; what we see in our projects’ logs is still 2019 phones, and we say so as an observation.

The same screen, on a weak network, before and after

Speed is not understood on a principle but on a real screen, loaded twice on the same network.

Figure 1 · The same screen, the same network, two builds. Before, everything is loaded in the order the code asks for it: three scripts, twelve original images, six API calls one after another; after, this screen’s code only, four images at screen size, one aggregated call, and the cache on the second opening. The figures are an example built from real cases; the orders of magnitude are the ones we measure.

Before. The HTML page weighs 180 KB and takes over a second. Three scripts totalling 1.4 MB, the whole app’s code while the screen uses a fraction of it, take three and a half more. Twelve images arrive as the phone that took them sent them, 3.2 MB, and occupy the network for seven seconds. Then the API: a first call returns all the year’s orders, 640 KB, and five more calls follow one after another for customers, products and statuses, because the code makes one per kind of information. The screen is usable at 9.8 seconds, and the salesperson has already tapped twice more.

After. The same list, the same network. The HTML page weighs 40 KB. One script, this screen’s, 220 KB, and the rest of the app loads later, when needed. Four images, the visible ones, resized to displayed size and converted, 280 KB; the next ones come on scroll. One API call, aggregated, paginated to fifty rows, compressed, 38 KB, returning the page with its customers and products. The screen is usable at 1.9 seconds, and on the second opening the cache serves the page without network. The figures are an example built from real cases; the order of magnitude, five times faster without changing server, is the one we measure.

«Five times faster without changing server: that is the order of magnitude we measure when a screen goes from twenty calls to one.»

Six slownesses we almost always find

Six slownesses recur on almost every application we take over, and each has a build that fixes it.

Figure 2 · Five of the six slownesses are fixed in the code, not in hosting; the sixth comes only after. The order of the right column is also the order of gains: budget and images first, pagination and aggregation next, indexes and cache last.

The 5 MB screen: all the code loaded at once and original images; budget per screen, code split, images resized and converted on upload. The 2,000-row list: all the year’s orders in one call, then the screen freezing while drawing them; server-side pagination at fifty rows, sort and filter in the query, scroll loading the next page. One request per row: for each order a call for the customer and one for the product, two hundred calls for a page; one aggregated call, and on the database side a join rather than a loop; it is the most frequent slowness and the most invisible on the developer’s wifi.

Search with no index: finding a customer by phone scans the whole table, four seconds at a hundred thousand rows and worse every month; indexes on searched and sorted columns, execution plan read before production, 300 ms threshold at the 75th percentile; catalogue search has its own rules, described in the search guide. Everything reloaded on every opening: catalogue, images and settings start from scratch; HTTP cache with validation, local cache of stable data, network only for what changed. The far, slow server: it is the only slowness fixed in hosting, and only after the other five, because a screen making twenty calls is slow even on the best server.

An application’s speed, in five layers

Behind those six slownesses, five layers, and the one where you gain most is not the one people think.

Figure 3 · The accented layer is where you gain most: a screen that makes one call instead of twenty is fast even on an average server, and a screen that makes twenty is slow even on the best. The fifth layer is what turns the complaint into a figure.

The phone and the network: a 2019 Android, 3G or a shared wifi, a battery in saving mode; you do not change them, you build for them and test on them. The screen: this screen’s code only, images at displayed size, a render that shows something before receiving everything; every screen has its budget. The API: one aggregated call per screen, pagination, compression, cache headers, response time measured at the 75th percentile; it is the layer where you gain most, by removing calls rather than speeding them up.

The database: indexes on what is searched and sorted, joins instead of loops, execution plan read, slow queries logged; a table growing every month reveals what was not visible at launch, which is why measurement continues after production. Measurement: real timings collected from users, per screen, per network type, per wilaya, at the 75th percentile, and the budget checked at every delivery, on a screen built like the manager’s dashboard; without it, “it crawls” and “it works” are two opinions, and the discussion with the supplier never ends.

The performance budget, written before the code

The budget is the piece that changes everything: six figures per screen, written before the first line and checked at every delivery.

Figure 4 · The budget is the piece that changes everything: six figures written before the code, measured on an old phone and a simulated network, checked by the delivery pipeline. Here one bar exceeds, and delivery is refused until the images are resized. The values are an example; the 2.5 s main-content and 300 ms API thresholds at the 75th percentile are the ones we write by default.

Six measures for the “order list” screen, on a 2019 Android over simulated 3G: first-screen weight, HTML, scripts and visible images compressed, 500 KB; visible images, 200 KB; scripts before display, 250 KB; requests before display, three; API response time at the 75th percentile, 300 ms; and main content displayed, 2.5 seconds, the public threshold. On the drawing one bar exceeds: images weigh 280 KB because one product photo still arrives at its original size; delivery is refused, and the next demo shows the fix.

Three rules hold the budget. It is written per screen, not for the application, because the point of sale is a matter of hundreds of milliseconds per gesture and the map of seconds. It is measured on your customers’ phone and network, not the developer’s. And it lives in the code repository, checked by the delivery pipeline at every version, not in a document read once: that is what keeps speed from leaving with the next version, as the delivery guide describes for tests. The drawing’s values are an example; the 2.5-second and 300 ms thresholds are the ones we write by default.

«Without measurement on real users, “it crawls” and “it works” are two opinions, and the discussion never ends.»

Six screens, and the budget we write for each

One budget per screen, because six screens do not have the same speed to hold.

Figure 5 · A budget per screen, not one for the application: the point of sale is a matter of hundreds of milliseconds per gesture, the map of seconds, the list of kilobytes. Each row is written in the specification and measured at every demo.

The order list: fifty rows with customer, amount and status; 500 KB, three requests, 2.5 seconds, API at 300 ms. The product sheet with photos: 600 KB of which 300 KB visible images, the next on scroll; it is the B2B portal screen retailers open most. Catalogue search: results while typing over ten thousand references, 200 ms per keystroke at the 75th percentile, a search index and never a table scan. The manager’s dashboard: six figures per branch in one request over precomputed aggregates, 1.5 seconds, refreshed every sixty seconds and not on every gesture.

The in-store point of sale: 100 ms per gesture, catalogue in local cache, and it works without network, as the point-of-sale guide requires. The delivery map: two hundred clustered points, map tiles cached, two seconds, updated by events and not by reload, per the delivery platform guide. Each row is written in the specification and measured at every demo; a screen with no budget is a screen nobody will be able to call slow.

Seen elsewhere: the public thresholds, and what transposes

Two sources say the essentials. The Core Web Vitals say a page is good when main content shows in 2.5 seconds, it reacts in 200 ms and does not move, measured at the 75th percentile on mobile; what transposes is the percentile and the mobile split, not only the thresholds, because an average hides a quarter of your customers. Google’s WebP documentation says 25 to 34 % gain over JPEG; what transposes is that format comes after size, and both are done on upload, server-side, once and for all.

What these sources do not say: which phones and networks your customers have, and which screen is really slow; the project’s first week answers that, without a line of code, by collecting real timings from your users.

The rules of an application that is fast at your customers’

Six rules, written in week one. A budget per screen, written before the code. Measured on your customers’ phone and network, not the developer’s, at the 75th percentile. Images are resized and converted on upload, and the screen asks for the size it displays. One API call per screen, aggregated, paginated, compressed, cached. Indexes on what is searched and sorted, and slow queries logged. The budget lives in the delivery pipeline, and a version that exceeds it does not ship.

A seventh rule concerns the quote: “performance optimisation” is not a requirement, it is a sentence; the requirement reads “budget per screen with weight, requests, main content in 2.5 s and API at 300 ms at the 75th percentile; measurement on real users per screen, network and wilaya; images resized and converted on upload in several sizes; code split per screen; server-side pagination; one aggregated call per screen, no request per row; indexes and execution plan; HTTP and local cache; tests on a 2019 Android over simulated 3G; budget checked by the delivery pipeline”, and it is checked as the specification guide recommends. A quote proposing “a more powerful server” on its first line has proposed the sixth slowness before the other five.

Six applications, and the screen that slowed them down

Six applications we took over or built, and for each the screen that was slow and what fixed it.

The field sales app, described in the dedicated guide. The customer sheet loaded the full order history; pagination and aggregates, and the morning round no longer starts with a wait.
The B2B ordering portal, described in the dedicated guide. The catalogue sent suppliers’ original photos; resized on upload, the catalogue goes from 11 MB to 600 KB.
The point of sale, described in the dedicated guide. Every added item made a server call; catalogue in local cache, 100 ms per gesture, and the queue at the counter is gone.
The dashboard, described in the dedicated guide. Six figures recomputed over the whole table at every opening; precomputed aggregates, one request, 1.5 seconds.
The app taken over from a vanished supplier, described in the dedicated guide. Two hundred requests per page without anyone knowing; the first week of measurement showed it, the third fixed it.
The shop run from France, described in the dedicated guide. The founder saw a fast app from a fibre connection; the 75th-percentile board per wilaya showed them what their sales staff saw.

The 2027 calendar

The calendar is that of an application made fast in six weeks, the first without a line of code.

Figure 6 · Six weeks, the first without a line of code: you measure first, because the slow screen is almost never the one you think. Screens come before the API and the database because that is where gains are largest; and the budget enters the delivery pipeline so that speed does not leave again with the next version.

Week 0 to 1 measures on real users: real timings per screen, network and wilaya, phones actually present in the logs, and a budget written per screen; the slow screen is almost never the one people thought. Week 1 to 2 handles screens: code split, images resized and converted on upload, visible content loaded first; that is where gains are largest. Week 2 to 3 handles the API: one aggregated call per screen, pagination, compression, cache headers, superfluous calls removed. Week 3 to 4 handles the database: indexes, joins, slow queries logged and fixed.

Week 4 to 5 measures every screen on a 2019 Android over simulated 3G and loads the API like a peak day. Week 5 to 6 puts the budget into the delivery pipeline and installs the 75th-percentile board read every week. Every batch is demoed as the delivery guide describes; and when the app is mobile, the same discipline applies to every version, per the updates guide. If after all that the server remains the bottleneck, the hosting guide says where to put it; that is the sixth step, not the first.

What makes a fast application fail

The slow applications we take over are almost always slow for one of these reasons.

Tested on the developer’s phone. Recent, on wifi, in Algiers; customers have 2019 Androids, on 3G, in Sétif.
No budget. Nobody can say whether the screen is slow, so nobody fixes it.
Original photos. Four megabytes for a 300-pixel square, times twelve.
One request per row. Invisible on wifi, devastating on 3G.
The list without pagination. Fast at launch, slow in month six, frozen in month twelve.
A bigger server instead of code. The bill rises, the screen still makes twenty calls.
Measured once. The next version loses it all, and nobody sees it before the customers.

Frequently asked questions

The questions we receive from managers, founders and IT managers.

Why is the app fast for us and slow for customers?: Because it was tested on a recent phone over wifi and is used on older phones over 3G or a shared wifi. A screen making twenty calls and loading five megabytes goes unnoticed on fibre and takes ten seconds on 3G. We build and measure for your customers’ phone and network, at the 75th percentile, not for the developer’s.
Do we need a more powerful server?: Almost never first. Five of the six slownesses are fixed in the code: screen weight, images, pagination, request per row, indexes, cache. A screen making one call instead of twenty is fast even on an average server. The server comes sixth, after measurement, and the hosting guide then says where to place it.
What is a performance budget?: Six figures per screen, written before the code and checked at every delivery: first-screen weight, visible images, scripts before display, number of requests, API response time at the 75th percentile, and main content displayed in 2.5 seconds on a 2019 Android over simulated 3G. A version exceeding one of these values is not delivered until fixed.
Why the 75th percentile and not the average?: Because the average hides the worst-served quarter of users. The 75th percentile is the time below which three customers out of four fall; it is the point Google’s public thresholds ask to measure, separately on mobile, and the one we write into the contract.
How much do you gain on images?: The gain Google documents for WebP is 25 to 34 % over JPEG at equal quality; but the gain that counts comes before: a phone photo weighs several megabytes and is displayed in a 300-pixel square, and resizing it to that size divides its weight by ten or more. Both are done on upload, server-side, in several sizes, once and for all.
How long to make an application fast?: Six weeks: one to measure on real users and write the budgets, one for screens, one for the API, one for the database, one to measure on an old phone over simulated 3G and load the API, one to put the budget into the delivery pipeline. The first week has no code, and it decides the order of the other five.