Choosing a CDN by the sheer number of servers on a map is roughly as reliable as selecting a car by the count of buttons on its dashboard. One provider may operate a vast global network that offers little benefit to a site whose audience sits primarily in Novosibirsk and Yekaterinburg. Another may cover fewer countries yet maintain stronger peering with the Russian operators that actually serve those users. A third may prioritize DDoS and web-attack protection over minimal latency.
Consequently the question “which CDN is best” is framed incorrectly. An online store, a video-streaming service, a bank, a gaming platform and a site delivering several terabytes of images each month will each require different configurations. Any overall score such as 8.7 out of 10 merely conceals arbitrary weighting decisions. There is no objective basis for assigning two points to HTTP/3, five points to regional connectivity and three points to API convenience.
Why a universal CDN ranking does not exist
A content delivery network places copies of data on distributed nodes closer to end users. These nodes are commonly called PoPs (Points of Presence). Shorter paths can reduce latency, yet physical distance is only one factor. Route selection also depends on inter-operator peering, link congestion, DNS resolution, cache occupancy and the instantaneous state of the network in each region. A network with 80 PoPs is not automatically twice as fast as one with 40.
Use-case priorities diverge sharply. Media companies focus on throughput and the economics of hundreds of terabytes. Retailers value rapid cache purge, origin redundancy and web-application protection. Banks often treat the price per gigabyte as secondary to SLA guarantees, DDoS mitigation, logging and support quality.
How the comparison is structured
Characteristics are grouped into three categories: functions that can be verified from documentation or the customer portal; tariffs, contractual terms and SLAs; and measured latency, throughput and availability. The last group requires real-world testing, preferably from networks that host the project’s actual audience.
Seven evaluation criteria are applied:
- Network geography, peering and PoP locations
- RTT, TTFB, transfer speed and availability
- Caching behaviour, cache-key construction, TTL, purge and prefetch
- Protocol support including HTTP/2, HTTP/3, TLS, IPv6, WebSocket and video protocols
- DDoS protection, WAF, origin shielding and access control
- API, logs, statistics, roles and automation
- Traffic pricing, request fees and support costs
Independent measurement with CDNMON
CDNMON provides continuous synthetic monitoring of CDNVideo, EdgeCenter and Curator from more than 150 vantage points. Results cover RTT, TTFB (including TLS handshake), transfer speed, availability and cache-hit ratio. The service does not replace real-user telemetry but supplies repeatable, comparable data.
The 95th percentile (p95) is especially informative. While median TTFB may appear attractive, p95 reveals the long tail of slow requests that users actually notice.
Five providers, five distinct approaches
CDNVideo publishes transparent package tariffs (2 TB for 5 000 RUB, 5 TB for 8 000 RUB). HTTP/3, origin shielding and raw logs are included; API rate limits are documented (10 requests per minute for cache operations).
EdgeCenter advertises 70+ PoPs across three continents and detailed Russian coverage. HTTP/3 is in beta; origin shielding and raw-log export are paid add-ons.
Curator positions its 30 PoPs as part of an integrated security platform. DDoS protection is built into the CDN service; pricing starts at 10 000 RUB per month as an add-on.
NGENIX offers more than 50 nodes and 7+ Tbit/s capacity. Raw Access Logs and streaming export are available; the product is positioned as an edge platform combining delivery, WAF and observability.
Yandex Cloud CDN lists 78 PoPs and 8+ Tbit/s capacity. It integrates natively with object storage, Terraform and IAM roles; origin shielding and log export are billed separately.
Conducting a meaningful pilot
Tests should use identical origin servers and object sets. Measure cold and warm cache, small and large objects, evening peaks and controlled origin failure. Track cache-hit ratio, error rates, purge propagation time and full log completeness over several days.
Key questions for any provider include which PoPs will serve the primary audience, how the network fails over, what API and purge limits apply, and which security features are included versus charged separately.
