StaticDelivr CDN

This is my last devlog for StaticDelivr, so I’m not shipping a feature today, just reflecting.

After 31 devlogs and 290+ hours, I learned more from this than any class or tutorial. I went from just proxying files to running a real multi-CDN with 570+ PoPs, building failover logic that keeps us at ~20ms even when Fastly and Gcore go red, fixing the SVG optimizer that was breaking on sharp, adding proper immutable caching, launching status.staticdelivr.com for full transparency, and shipping the WordPress plugin with the Failure Memory System and window.staticDelivr.status() diagnostics.

The biggest change isn’t code, it’s scale and trust. In the last 30 days we served 800,000,000 requests with 100% uptime.

That only happened because we now have seven infrastructure sponsors backing a free open-source project: Cloudflare, Hetzner, Netlify, ClouDNS, Tuta, BrowserStack, and AppSignal.

Going from a solo idea to having major providers sponsor the network is what makes this production-grade, not just a side project. It means StaticDelivr can stay fast, global, and completely free for the open source community long term.

Thanks to everyone who tested, reported bugs, and used it in production. Learned a ton building this.

Spent the last 8hrs fixing the one edge case that kept breaking the image optimizer: SVGs.

The attachment is the proof. https://cdn.staticdelivr.com/img/images?url=https://staticdelivr.com/assets/sponsors/cloudflare.svg now returns as a real image instead of a text response.

Before this, the /img/images pipeline was built for raster. When you passed an SVG it would hit sharp, fail the decode, then fall back to a raw proxy with content-type: text/xml. Browsers would either download it, block it in an <img> tag, or miss the cache entirely because we were not setting immutable headers. It was especially visible on the sponsors page where Cloudflare, Hetzner, and Tuta logos would flash or 404 during a provider failover.

I added a dedicated SVG branch:

• Detect image/svg+xml early and skip raster transforms
• Run SVGO with a safe preset: strip scripts, comments, and editor metadata, preserve viewBox, title, and aria-label for accessibility
• Set correct headers: content-type: image/svg+xml; charset=utf-8, cache-control: public, max-age=31536000, immutable, and timing-allow-origin: *
• Pipe the result into the same multi-CDN cache we use for WebP/AVIF so it hits all 577 nodes, not just Origin

That last part matters. With Fastly and Gcore both red yesterday on status.staticdelivr.com, the SVG still served at 26ms from Cloudflare because it is now treated like any other optimized image. No more special-casing in the WordPress plugin either.

This directly unblocks two things I have been wanting to ship: 1) SVG logos in the Google Fonts integration without layout shift, and 2) allowing users to pass ?w=256&format=webp on an SVG source and get a rasterized fallback for old email clients. The optimizer will now do the conversion server-side instead of failing.

Next I will add ?sanitize=0 for trusted origins and surface SVG bytes-saved in the same telemetry that powers the 142GB saved counter.

Spent the last 32h 37m shipping the public version of the health checks I have been running privately since v2.5.0. status.staticdelivr.com is now live and it is the clearest proof yet that transparency as a feature actually works.

The attachment is from this morning and it shows exactly why I built this. Fastly and Gcore are both red with Availability error, yet the top level StaticDelivr CDN stays green at 100% availability with a 26ms latency baseline over the last day. That is not a glitch. That is the multi-CDN routing I have been tuning with Cloudflare taking over silently.

After the Gcore SSL conflict at 2 AM last month I realized internal logs were not enough. Most of this block went into rewriting the synthetic probes to run from eight regions every thirty seconds instead of just my own test node, then piping those results into the same time series store that powers the 1 day, 1 week and 1 month graphs you see at the bottom. I also moved the frontend to Origin and locked it with cache-control: immutable so the status page cannot go down with the providers it monitors.

This ties directly into the WordPress plugin work. The Failure Memory System from v1.7.0 now reads the same GET /health snapshot that drives the status page, and window.staticDelivr.status() in v2.5.0 returns the same active provider you see in the UI. With the new Hetzner and Cloudflare capacity behind our 577 nodes, the failover that used to spike latency above 600ms now holds that flat line near 20ms even when two vendors drop.

Next I will surface these failover events as a quiet notice inside the WP dashboard so you do not have to check the page manually.

Analyzing the latest download telemetry for the WordPress plugin provides a fascinating look at our growth trajectory over the past several months. While the baseline remained steady throughout late 2025, the significant spikes observed in late December and early February represent major stress tests for our delivery infrastructure. These bursts, peaking at over 50 downloads per day, coincide with our successful rollout of the updated Google Fonts integration and the initial previews of our multi-CDN failover system.

The data shows that despite these aggressive surges in user acquisition, the underlying origin services maintained 100% availability. It is particularly rewarding to see the “All Time” download count cross the 1,100 mark, backed by a consistent 5-star rating. This level of community trust validates the “transparency as a feature” approach I’ve taken with our diagnostic tools.

My current focus is on smoothing out the “tail” of this graph by improving organic discoverability within the WordPress ecosystem. The goal is to turn these periodic spikes into a higher, more consistent daily floor. By further refining our tags, specifically around “image optimization” and “speed”, we are positioning StaticDelivr not just as a developer tool, but as a primary performance upgrade for standard production sites. I will continue to monitor these conversion metrics as we push toward the next major version release.

Lowering the barrier to entry is just as important as the raw performance of the network itself. I’ve just rolled out a new suite of Batch Migration Patterns designed to help developers transition their entire codebases to StaticDelivr in seconds. By providing pre-configured find-and-replace strings for major providers like jsDelivr and unpkg, we’re making it a one-step process to swap legacy CDN links for our globally-distributed edge nodes.

The jsDelivr pattern features auto-detection for both NPM packages and GitHub files, ensuring paths are preserved perfectly. For unpkg users, the logic automatically handles the necessary /npm/ subdirectory injection to maintain total compatibility without breaking existing asset structures. This update is a direct response to the growth we’ve seen following our latest infrastructure sponsorships, providing a seamless “on-ramp” for production environments looking to leverage our improved latency and multi-CDN resilience.

I’ve been heavily focused on optimizing the core image delivery pipeline and significantly increasing network reliability. By refining our edge-caching strategies and optimizing backend handshake protocols, I have successfully reduced latency and stabilized request volatility. The analytics data from our recent traffic tests is incredibly encouraging, showing that the system maintains a robust, low-latency baseline even during sharp, multi-gigabit spikes in request volume. This ensures we are maximizing the performance of our global footprint and providing the level of rock-solid reliability necessary for production-grade environments. I will be continuing to monitor these metrics over the coming days.

Spent the last twenty-four hours deep in the logs to analyze how the network handles sudden volatility. Looking at the latest traffic telemetry, there are a few sharp spikes that represent massive bursts in request volume, but the most encouraging part is how quickly the baseline returns to a flat, stable line. I have been working closely with Cloudflare to better integrate our edge logic and ensure we are fully optimizing their global network. This collaboration is focused on fine-tuning our routing rules so that we can squeeze every millisecond of performance out of their infrastructure.

The goal is to move beyond simple proxying and into a more native integration where our assets are intelligently cached and served based on real-time regional demand. By refining these handshake protocols, we have managed to keep the overall latency steady even when the load triples during peak windows. It is a constant process of monitoring these “red-line” events and adjusting our load balancing to make sure no single node becomes a bottleneck. The data shows that the current configuration is holding up well, providing the kind of rock-solid reliability that a production-grade CDN needs.

Weeks of small backend fixes finally show up in the graphs, with latency dropping into a smoother, flatter line that reflects cleaner routing, fewer slow paths, and a more efficient cache layer without affecting availability.

More sponsors joining feels like a real turning point. Hetzner and Cloudflare coming onboard shows that the project has grown from a small idea into something serious enough for major infrastructure players to back. It took a lot of outreach, polishing, and persistence to get here, and seeing it pay off is energising.

Each new sponsor strengthens the foundation of the service and signals to users that this is a project with long term stability and real industry trust. It also opens doors for future partnerships and gives you more room to keep improving the product without compromising on the free and open spirit that makes it special.

Successfully optimized server response times across both StaticDelivr Origin and GitHub nodes. By addressing the previous volatility visible in the early logs (where latency peaked above 600ms), I’ve achieved a consistent baseline. Post-optimization, latency has dropped significantly and remained steady below 200ms, ensuring much faster and more reliable content delivery for all global requests.

Encountered a significant service disruption on the Gcore CDN layer. The analytics show a sharp climb in latency followed by a complete loss of availability starting at 2:00 AM. Preliminary investigation points toward an SSL-related conflict, possibly a protocol mismatch or a certificate propagation error at the edge level. Coordination with Gcore is ongoing to resolve this and implement a more robust failover mechanism to prevent similar dropouts in the future.

Following the extensive downtime previously logged, further testing and infrastructure optimization have led to a full recovery of the Delivr CDN (Images) node. Availability has returned to a stable 96.2% and is trending upward as edge caches repopulate. Latency has stabilized at approximately 94ms, providing a responsive experience for image delivery. This recovery confirms that the SSL/optimization changes implemented were successful in restoring the service.

Finally cleared the “flatline” on the StaticDelivr (CDN Images) analytics. Previous logs showed a total lack of response across all time zones due to a backend handshake failure. By reconfiguring the image processing headers and aligning the backend protocols, I’ve successfully restored the service. Early post-fix data indicates the backend is not only stable but performing with much lower overhead than before the outage.

Conducted deep-tier testing on the backend to aggressively target TTFB (Time to First Byte) reductions. By implementing more efficient compression algorithms, likely moving toward Brotli or high-level Gzip, I’ve managed to shrink the initial response window. This ensures that even for large libraries like jQuery 3.7.1, the browser begins receiving data almost instantly. These changes significantly reduce the perceived load time for the end user, especially on high-latency mobile connections.

Implemented a series of accessibility (a11y) enhancements to ensure the platform remains inclusive and navigable for all users. The latest code changes focus on transforming static code blocks into interactive, accessible components. By adding role="button" and tabIndex={0}, these elements are now discoverable via keyboard navigation. Additionally, I’ve implemented an onKeyDown listener to support ‘Enter’ and ‘Space’ triggers, alongside descriptive aria-label attributes to provide necessary context for screen reader users during copy actions.

Focused on optimizing HTTP response headers to maximize edge caching efficiency. By implementing a strict Cache-Control policy (public, max-age=31536000, immutable), I’m ensuring that static assets are stored by the browser for a full year. The immutable directive is particularly important here, as it tells the browser the file will never change, preventing unnecessary revalidation requests and further reducing server load and latency.

Expanded the platform’s core capabilities by implementing native support for GitLab assets. This allows developers to serve production-ready files directly from GitLab repositories, mirroring the seamless experience already available for GitHub. The integration includes a new CLI flag --gitlab allowing for easy conversion and deployment of assets. This is a significant step toward making the CDN a universal tool for developers regardless of their preferred version control platform.

Initiating the roadmap for native GitLab support. The goal is to move beyond simple file fetching and implement an intelligent orchestration layer that covers the entire software lifecycle. By integrating with GitLab’s DevSecOps ecosystem, we can automate asset delivery directly from CI/CD pipelines. This phase focuses on mapping GitLab’s API structures to our existing edge network, ensuring that AI-driven optimizations, like automated minification and security scanning, are applied seamlessly to every GitLab-hosted asset.

Successfully secured a new round of infrastructure sponsorships, marking a major turning point for the project’s stability. By partnering with industry leaders like BrowserStack and Tuta, we have gained access to high-tier testing environments and secure infrastructure resources. This expansion directly translates to a more reliable experience for our users, as it allows for more rigorous cross-platform validation and enhanced security protocols across our global edge nodes.

Released WordPress plugin v2.5.0, introducing a new suite of diagnostic tools designed to give developers total visibility into their asset delivery. The headline feature is the new Diagnostic Console API. By simply typing window.staticDelivr.status() into the browser console, users can now verify active settings and debug status in real time. This move toward “transparency as a feature” ensures that any configuration issues, like the SSL or latency spikes seen in previous logs, can be identified and resolved by the end user without deep backend access.

Released version 1.7.0 of the WordPress plugin with a major focus on uptime resilience. The new Failure Memory System acts as an intelligent circuit breaker for asset delivery. If the CDN experiences a disruption, the plugin now detects the failure via a non-blocking beacon API and automatically switches to serving resources from the local origin. By “remembering” these failures for 24 hours, the system prevents repeated timeout delays, ensuring the site remains fast and functional even when external infrastructure is struggling.

Expand google fonts to wp plugin.

1.4.0
Fixed WordPress core files to use proper version instead of “trunk”
Core files CDN URLs now include WordPress version (e.g., /wp/core/tags/6.9/ instead of /wp/core/trunk/)
Added WordPress version detection with support for development/RC/beta versions
Cached WordPress version to avoid repeated calls
Updated settings page to display detected WordPress version
Prevents cache mismatches when WordPress is updated

We are systematically expanding our global footprint by activating new Points of Presence (PoPs) one at a time. This strategic growth focuses on placing infrastructure as close to the edge as possible, significantly reducing the physical distance data must travel. A bigger, more distributed network directly translates to lower latency for edge users, ensuring that assets are served with high-performance speeds regardless of where the request originates geographically.

Enhanced our caching architecture to better manage traffic spikes and asset propagation. The core of this update is the “Purge Cache” functionality, which allows for granular invalidation of assets via their specific CDN URL. During the current system maintenance phase, we are further upgrading the Purge API to improve propagation speed across all global PoPs. This ensures that invalidation requests are processed in near real time, maintaining a perfect balance between edge-speed delivery and data freshnes.

Performance meets design with our new Optimized Font Delivery system. We’ve curated a library of the web’s most popular typefaces, including Inter, Roboto, and Montserrat, and re-engineered how they are served from our edge network. Each font is delivered via a specialized CDN URL designed to minimize layout shifts and reduce the time to first meaningful paint. By moving font hosting to our distributed nodes, we ensure that your site’s typography loads with the same lightning-fast precision as your core scripts.

Our commitment to a borderless web takes a massive leap forward with this latest infrastructure rollout. We have successfully deployed dozens of new Points of Presence (PoPs) across key strategic hubs, bringing our total node count to 577 operational units. This expansion isn’t just about numbers; it’s about density. By saturating regions like Western Europe and the Mediterranean with high-performance nodes, we are effectively slashing the physical distance data must travel. For an edge user, this means sub-millisecond handshake times and a browsing experience that feels local, regardless of where the origin server actually sits.

The physical reach of the network has scaled to an impressive 577 operational nodes. This expansion focuses on strategic density, placing infrastructure as close to the edge as possible to minimize the physical distance data must travel. By activating new Points of Presence (PoPs) across North America, Europe, and Asia, the network now achieves near-instantaneous content delivery.

A core part of this growth is our sophisticated multi-CDN architecture. By leveraging the unique strengths of Bunny, Cloudflare, Fastly, and Gcore, we ensure that the network is not dependent on a single provider. If one vendor experiences a localized issue, our intelligent routing layer automatically directs traffic to the healthiest, lowest-latency node available, maintaining a perfect uptime record.

A major priority has been empowering developers with better diagnostic and integration tools. Version 2.5.0 of the WordPress plugin introduced a new Diagnostic Console API, allowing users to verify active settings and debug status in real time via the browser console with commands like window.staticDelivr.status(). Additionally, version 1.7.0 implemented a critical Failure Memory System. This acts as an intelligent circuit breaker; if a CDN node experiences disruption, the plugin automatically switches to serving resources from the local origin for 24 hours. This prevents cumulative timeout delays and ensures that a third-party outage never breaks the end-user’s website.

The platform’s technical foundation has also earned the confidence of industry leaders, securing infrastructure sponsorships from companies like BrowserStack and Tuta. These partnerships provide the high-tier testing environments and secure resources necessary to transition from a development project into a production-grade CDN.

142GB
Data we didn’t send. By compressing images and code, we saved terabytes of unnecessary transmission this month alone.

Carbon Avoided
10 kg

Energy Equivalent
2,136
Lightbulb-hours powered

The current phase of development focuses on verifying the interoperability of the StaticDelivr CDN architecture with WordPress environments. This testing is critical to ensuring that our globally distributed edge nodes can efficiently handle the high frequency of small-file requests, specifically scripts and stylesheets, typical of the WordPress core and plugin ecosystems. Initial telemetry confirms a 100% success rate with 200 OK status codes across all tested assets, demonstrating that our mapping of internal indices to the CDN’s delivery pipeline is stable. By offloading these static dependencies to StaticDelivr, we are effectively reducing the processing load on the origin server and significantly lowering the Time to First Byte (TTFB) for end-users. Moving forward, I will be analyzing cache hit ratios and exploring further optimizations for handling dynamic asset versions to ensure seamless performance during theme updates.

After shipping v1.3.1, I wanted to ensure the fallback mechanism was bulletproof. If the CDN goes down, the site must revert to local assets immediately.

Simulated CDN outages by blocking cdn.staticdelivr.com in my local hosts file to verify that the plugin correctly reverts to local URLs without breaking the site layout.

Further Unit Tests conducted to ensure reliability.

🔥 On the Grill (Plugin Updates)

Shipped v1.3.1 with critical fixes for directory pathing and asset rewriting.

Patched security gaps in external link handling (rel=“noopener”).

Prep work: Standardized readme.txt documentation for the repo.

🥗 Presentation (Frontend)

Served a new Next.js Landing Page update.

Refined the “Sustainable Infrastructure” copy.

🧹 Kitchen Porter (Ops)

Performance: Reduced filesystem I/O overhead via new caching logic.

Maintenance: Completed server-side security checks and general cleanup.