# ProbeLab's Notable IPFS Performance Results - Week 18, 2026 **URL:** \ **Category:** Protocol\ **Created:** [April 28, 2026, 12:12pm UTC](https://discuss.ipfs.tech/t/probelabs-notable-ipfs-performance-results-week-18-2026/20107 "2026-04-28T12:12:51Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![yiannis](https://avatars.discourse-cdn.com/v4/letter/y/e47774/32.png) [@yiannis](https://discuss.ipfs.tech/u/yiannis)\ **Post date:** [April 28, 2026, 12:12pm UTC](https://discuss.ipfs.tech/t/probelabs-notable-ipfs-performance-results-week-18-2026/20107/1 "2026-04-28T12:12:51Z")
After a longer than usual gap, and following up from our previous report in Week 10, 2026 on the notable results on IPFS’s performance ( [ProbeLab's Notable IPFS Performance Results - Week 10, 2026](https://discuss.ipfs.tech/t/probelabs-notable-ipfs-performance-results-week-10-2026/20064) ), here is ProbeLab’s update on the state of the IPFS network over the past few weeks. The intention of these reports is to celebrate improvements, but also direct efforts to parts of the protocol that need attention. Here are the most noteworthy highlights for Week 18 (April 27th) and the several weeks preceding this: - Stable number of DHT server nodes, but **substantial increase of DHT client nodes:** [https://probelab.io/ipfs/#chart-ipfs-servers-vs-clients-ts](https://probelab.io/ipfs/#chart-ipfs-servers-vs-clients-ts) - Traditionally, **IPFS bootstrappers are reliable** and do not present any performance fluctuations: [https://probelab.io/ipfs/bootstrappers/](https://probelab.io/ipfs/bootstrappers/). - Probably the biggest highlight is Kubo’s Publish performance, which, since last November (after v0.39), has **decreased by an order of magnitude** from more than 14s to less than 1s: [https://probelab.io/ipfs/kubo/#chart-kubo-publish-performance-ts](https://probelab.io/ipfs/kubo/#chart-kubo-publish-performance-ts). - The **DHT Lookup performance has gradually decreased** after the mid of March and remained relatively stable since, hovering just above 0.3s: [https://probelab.io/ipfs/dht/#chart-ipfs-dht-lookup-performance-ts](https://probelab.io/ipfs/dht/#chart-ipfs-dht-lookup-performance-ts) - There’s a slight **increase in the number of Daily Unique CIDs** seen in the network during the past week (since 22nd April) to more than 120M from less than 100M two weeks ago: [https://probelab.io/ipfs/bitswap/#chart-ipfs-bitswap-unique-cids-ts](https://probelab.io/ipfs/bitswap/#chart-ipfs-bitswap-unique-cids-ts) - The most active peer has made more than 4M requests, while the most popular CID has been requested 626 times, on April 26th - see last two tables at: [https://probelab.io/ipfs/bitswap/](https://probelab.io/ipfs/bitswap/) - **IPNI has been very stable the last 1.5 months, with more than 99% uptime.** It is also worth highlighting that delayed ingests (i.e., content that has not been indexed for more than 5 mins after advertisement) which happened for 5%-10% of requests earlier in the year, is now constantly close to 0%: [https://probelab.io/ipfs/ipni/cid.contact/#chart-ipni-uptime-bar](https://probelab.io/ipfs/ipni/cid.contact/#chart-ipni-uptime-bar) - **The IPNI Lookup Latency for uncached content at the p90 has almost tripled** since the beginning of the year, but the rest of the percentiles for both cached and uncached content have remained at previous levels: [https://probelab.io/ipfs/ipni/cid.contact/#chart-ipni-latencies-ts](https://probelab.io/ipfs/ipni/cid.contact/#chart-ipni-latencies-ts) - There’s a **clear downward trend in the number of requests per day to the traditional IPFS Gateways**. For a brief period of three days (13th to 16th of April) the number of badbits requests has also declined significantly from 25%-30% normally to less than 5%. The decline might be due to a shift towards the Service Worker Gateways: [https://probelab.io/ipfs/gateways/#chart-ipfs-gateway-requests-ts](https://probelab.io/ipfs/gateways/#chart-ipfs-gateway-requests-ts) - In terms of the TTFB performance of Service Worker Gateways: [https://probelab.io/ipfs/gateways/#chart-ipfs-service-worker-gateway-ttfb-ts](https://probelab.io/ipfs/gateways/#chart-ipfs-service-worker-gateway-ttfb-ts) - As usual, the density of PeerIDs across **the DHT keyspace is below the risk threshold** : [https://probelab.io/ipfs/security/#chart-keyspace-regions-population](https://probelab.io/ipfs/security/#chart-keyspace-regions-population) As always, feedback is welcome on this forum or the [contact details](https://probelab.io/contact/) of the ProbeLab team. ---
**Author:** ![Rashkae](https://avatars.discourse-cdn.com/v4/letter/r/96bed5/32.png) [@Rashkae](https://discuss.ipfs.tech/u/Rashkae)\ **Post date:** [April 28, 2026, 8:10pm UTC](https://discuss.ipfs.tech/t/probelabs-notable-ipfs-performance-results-week-18-2026/20107/2 "2026-04-28T20:10:56Z")
Here’s something I don’t understand. If the number of DHT servers is holding at over 20K, why do my peers swept top out at 2600? ---
**Author:** ![yiannis](https://avatars.discourse-cdn.com/v4/letter/y/e47774/32.png) [@yiannis](https://discuss.ipfs.tech/u/yiannis)\ **Post date:** [April 29, 2026, 10:50am UTC](https://discuss.ipfs.tech/t/probelabs-notable-ipfs-performance-results-week-18-2026/20107/3 "2026-04-29T10:50:41Z")
20k is the total number of DHT servers seen in the network throughout the measurement period, which is 1 week for this graph: [https://probelab.io/ipfs/#chart-ipfs-servers-vs-clients-ts](https://probelab.io/ipfs/#chart-ipfs-servers-vs-clients-ts). It is not the number of nodes simultaneously in the network. What you’re looking for is rather “availability over time”, which is shown in this graph: [Topology | ProbeLab Analytics](https://probelab.io/ipfs/topology/#chart-availability-classified-ts). A closer view to the weekly one is the daily number of peers seen in the network, for example in this graph: [Topology | ProbeLab Analytics](https://probelab.io/ipfs/topology/#chart-agent-types-ts) - again note though that, similar to my first comment, this is the total number of DHT server nodes seen in the network throughout a day.