Performance and Methodology

"Sub-10ms" is the processing time our redirect service spends on a request for a link that is already in the edge cache. It does not include DNS, the TLS handshake, or network transit between the visitor and the edge. This page states what we measure, shows the latest test with its sample size and date, and gives the commands so you can repeat every measurement.

What "sub-10ms" measures

Counted	Not counted
CPU time the redirect service spends on the request: reading the link from the edge cache, screening the user agent, choosing the destination, building the 302	DNS lookup, TCP and TLS handshakes, and the distance between the visitor and the edge location
A link that is already in the edge cache, which is every link after its first save	A cache miss, which adds one database read (see Architecture and failure modes)
The request path only	Work done after the visitor already has the redirect, such as queueing the click and storing the deferred-link payload

We report two server-side numbers. CPU time is the processor time the request used. Wall time is the elapsed time of the whole invocation, including the work done after the response was sent. Wall time is therefore an upper bound on what the visitor waits, not the wait itself.

Server-side result

Measured on 2026-10-10, 05:50 to 06:05 UTC, from the invocation logs of the production redirect service. Sample: 76 requests to one cached link (our demo link), sent in two bursts from one machine, so the instance was warm. Each request was a redirect to a desktop browser user agent.

Metric	p50	p95	p99
CPU time	3 ms	10 ms	13 ms
Wall time	70 ms	192 ms	not reported

For a cached link on a warm instance, the median redirect uses 3 ms of CPU, and 95 percent use 10 ms or less. Wall time is higher because it also counts the work done after the visitor has the redirect. This is one test on one day. We repeat it and update this page with the new date.

Client-observed latency

Measured on 2026-10-10 from one North American broadband connection, against our demo link, with a desktop browser user agent, without following the redirect. This is a single location and a single day. It shows what one visitor sees, not a global figure.

Connection	Measure	n	p50	p95
Fresh connection per request	Total time, including DNS, TCP, and TLS	50	169 ms	208 ms
Reused connection	Time to first byte	49	37 ms	131 ms

On this connection the TCP connect time had a median of 25 ms, which approximates one network round trip. Most of the time to first byte on a reused connection is that round trip, not the redirect service.

Edge network

"300+ edge nodes" is the size of the global edge network our redirect service runs on. We do not operate those locations ourselves. A visitor's request is answered by the location nearest to them, which is why transit time stays short. The figure describes the network, not the number of WarpLink servers.

SDK size

Measured on 2026-10-10. "Under 200KB" is gzipped size. KB here means 1,000 bytes.

SDK	What we measured	Raw size	Gzipped
iOS	Release build for arm64, debug info stripped	453,840 B	158,621 B
iOS	Size added to a linked test app, dead code removed and stripped	262,088 B	111,807 B
Android	Published 1.1.0 AAR from Maven Central	123,801 B	already compressed
React Native	JavaScript in the published 1.1.0 package (lib/module)	54,716 B	17,645 B
React Native	Entire published 1.1.0 tarball, including native sources and type definitions	not measured	83,546 B
Flutter	Dart code in the published 1.1.0 package (lib)	not measured	28,697 B
Flutter	Dart, Android, and iOS runtime sources in the published 1.1.0 package	not measured	74,318 B
Flutter	Entire published 1.1.0 archive, including tests, example app, and docs	not measured	185,192 B

React Native and Flutter wrap the native iOS and Android SDKs, so the native SDK is added on top of their own package. The totals below add the gzipped package code to the gzipped native SDK. They leave out the small native bridge code in each package, which we did not measure separately.

App	Calculation	Total
React Native on Android	17,645 B JavaScript + 123,801 B Android SDK	141,446 B
React Native on iOS	17,645 B JavaScript + 111,807 B iOS SDK	129,452 B
Flutter on Android	28,697 B Dart + 123,801 B Android SDK	152,498 B
Flutter on iOS	28,697 B Dart + 111,807 B iOS SDK	140,504 B

Every total above is under 200,000 bytes. The full published React Native tarball (83,546 B) and Flutter archive (185,192 B) are larger because they include source files, tests, an example app, and docs that do not ship inside an app. The iOS figures come from building the 1.1.0 source with the Swift 6.3 toolchain for iOS 15 and later. The other figures are the published packages.

Repeat it

Client latency, fresh connection per request:

curl -s -o /dev/null -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/130.0.0.0 Safari/537.36" \
  -w "%{http_code} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n" \
  https://YOUR-DOMAIN/YOUR-SLUG

Run it 50 times, 0.3 seconds apart, and take the 50th and 95th percentiles. Pass several URLs to one curl command to reuse the connection and read the time to first byte.

SDK sizes:

# Android
curl -sL -o sdk.aar https://repo1.maven.org/maven2/app/warplink/sdk/1.1.0/sdk-1.1.0.aar && wc -c sdk.aar

# React Native
curl -sL -O https://registry.npmjs.org/@warplink/react-native/-/react-native-1.1.0.tgz && wc -c react-native-1.1.0.tgz

# Flutter
curl -sL -o flutter.tar.gz https://pub.dev/api/archives/warplink_flutter-1.1.0.tar.gz && wc -c flutter.tar.gz

# iOS (from the SDK source)
xcodebuild -scheme warplink-ios-sdk -configuration Release -destination 'generic/platform=iOS' build
strip -S -x WarpLink.o && gzip -9 -c WarpLink.o | wc -c

What we have not measured yet

• Client latency from more than one location. We will add regions as we measure them.
• The cache-miss path. A request for a link that is not in the cache waits for one database read. That read has a 2-second limit per attempt and two attempts, so the worst case before the visitor sees an error is about 4 seconds.
• Client-side p99.

These measurements are repeated and republished here with their dates. For what the service does when a dependency is down, see Architecture and failure modes.