Our Method: measure first, diagnose from evidence.
A repeatable, evidence-first framework for understanding how applications, APIs and infrastructure actually perform across African networks.
31 African countries, with availability reported honestly.
The free scanner and paid audit attempt measurements in Kenya, Nigeria, South Africa, Egypt, Morocco, Ghana, Rwanda, Mauritius, Tunisia, Botswana, Senegal, Côte d’Ivoire, Tanzania, Uganda, Ethiopia, Algeria, Namibia, Zambia, Mozambique, Angola, Cameroon, Gabon, Djibouti, Seychelles, Cabo Verde, Eswatini, Madagascar, Zimbabwe, Malawi, Benin and Togo. A country is not represented as measured unless a live probe returns usable results for that scan.
Six steps from observation to proof.
Every engagement follows the same core sequence, while the measurements and depth are adapted to the customer's architecture, target markets and performance question.
01 — Discover
Define the business question, target countries, user journeys, critical endpoints, architecture, cloud provider, dependencies and known performance objectives.
02 — Measure
Run controlled HTTP/API and network measurements from relevant African vantage points. Capture timing, reachability and route evidence under documented conditions.
03 — Compare
Compare markets, networks, endpoints, infrastructure locations and test windows. Look for meaningful differences rather than assuming geographic proximity equals better performance.
04 — Diagnose
Connect observed behavior to the architecture. Separate network delay from server processing, database work, third-party dependencies and edge behavior.
05 — Recommend
Turn findings into a prioritized remediation plan based on likely impact, implementation effort, dependencies, risk and confidence in the evidence.
06 — Validate
Repeat the relevant measurements after remediation using comparable conditions. Document what changed and whether the measured outcome improved.
Trace the path from the user to the dependency.
Network
Round-trip latency, packet loss, jitter where measurable, route behavior, hop-level RTT and inter-country path differences.
Edge
CDN behavior, edge coverage, cache behavior and whether requests are reaching an appropriate point of presence.
Infrastructure
Cloud region, compute placement, load balancing, capacity signals and infrastructure configuration relevant to response time.
Application
DNS, TCP/TLS timing, TTFB, total response time, API behavior and server-side processing.
Database
Query latency, connection behavior, data locality and database dependencies when sufficient application evidence is available.
Dependencies
Third-party APIs, authentication services, payment services and other synchronous dependencies that can add remote round trips.
Timing is only useful when we know what it represents.
- DNS: time required to resolve the target when the test exposes DNS timing.
- TCP / TLS: connection and secure-handshake timing where available.
- TTFB: time until the first response byte, helping separate network and server-side delay from the rest of the transfer.
- Total response time: end-to-end HTTP timing observed by the measurement probe.
- HTTP status and reachability: whether the endpoint responds successfully and consistently under the test conditions.
- Route evidence: traceroute or related path information used to investigate routing and path inflation.
- Architecture evidence: customer-provided configuration, logs, traces and diagrams used to connect measurements to root causes.
No single metric proves a root cause. A finding becomes stronger when independent measurements and architecture evidence point to the same explanation.
We distinguish a measurement from a benchmark.
Point-in-time observations
A single scan is a snapshot. It can show that Nairobi was faster than Lagos during the observation, but it is not a population-wide benchmark or a P50/P95 claim.
Repeated measurements
For audits that require distributional analysis, measurements are repeated across an agreed window. P50, P95 or P99 are used only when the sample size and test design support those statistics.
Conditions matter
We record target, probe location, protocol, timestamp, test type and relevant configuration so that results can be interpreted and reproduced.
Comparisons need context
Country, ISP, cloud region, CDN and time-of-day differences can all change the result. We avoid turning one measurement into a universal statement about a market.
Measure the layer before prescribing the fix.
Example diagnostic chain
Observation: an African market has materially higher TTFB than another tested market.
Next question: is the additional time coming from the network path, TLS/connection setup, the application, a database operation, or a synchronous third-party dependency?
Evidence: compare network timing, route behavior, response timing and available application traces or logs.
Recommendation: address the highest-confidence bottleneck first — for example, service placement, caching, connection reuse, asynchronous processing or dependency architecture.
Validation: repeat the same relevant test after remediation and compare like with like.
Africa is not one network.
A deployment that looks fast from one African market can behave very differently elsewhere because of routing, peering, submarine and terrestrial paths, mobile-network conditions, cloud-region placement and CDN reach.
Inter-country routing
Investigate whether traffic takes an unexpectedly long or indirect path between African markets and the service.
Edge & CDN performance
Assess whether users are reaching an appropriate edge location and whether caching or routing policy is helping or hurting response time.
Mobile-first reality
Where the available measurement environment supports it, consider mobile-network performance separately from fixed or datacenter-based observations.
These are investigation lenses, not assumptions. The audit tests them against observed evidence.
What we will not claim.
- We do not manufacture measurements when a location or test is unavailable.
- We do not label a single observation as a P50, P95 or P99 benchmark.
- We do not claim a particular architecture is faster before measuring the relevant workload and markets.
- We do not turn an illustrative estimate into a customer result.
- We do not perform load or stress testing without explicit authorization and an agreed test window.
- We do not expose customer credentials, private architecture or sensitive measurement data in public reports.
From raw measurements to a decision.
The final audit is designed to answer four practical questions:
- What is slow? The measured baseline and market differences.
- Why is it slow? Evidence-backed root-cause analysis, with uncertainty called out.
- What should we fix first? A prioritized remediation roadmap tied to impact, effort and risk.
- Did the fix work? A validation plan and, where commissioned, before/after measurements.
Start with evidence.
Use the free scanner for a quick snapshot. When you need deeper diagnosis across your architecture and target markets, request an Africa Latency Audit™.