StaticDelivr CDN Wordpress Plugin

Project Hydra: full origin rewrite, and this is where the hours went. After the file descriptor outage last week, it became clear the PHP worker model was never going to scale with the new sponsors and the gstatic font proxy traffic. I spent the last month rewriting the entire origin layer in Go, moving from per-request temp files to a persistent in-memory cache with disk spillover, adding native HTTP/3 and QUIC support, and building a proper circuit breaker so we never hit system limits again.

The dashboard screenshot is the first internal build. You can see the global map lighting up, the request graphs stabilizing, and the key metrics finally reporting correctly. Average latency dropped from 163ms to 112ms in testing, bandwidth savings are up 40% because we are not recompressing the same WebP files, and the service now recovers in seconds instead of minutes.

It is still the same StaticDelivr CDN on the outside, but under the hood it is a completely different system. This was slow, painful, foundational work, and it is why the plugin has felt so much steadier on 2.5.

Here is a clean devlog for that 100% chart (fits your 6h 49m log):

Finally hit 100% active on the 2.5 branch, and that is one of those quiet milestones that means more than a feature release.

The statistics page is just a solid blue bar now. No more 1.7.0 installs, no 1.3.1 installs with the old version detection, no early builds hanging around. Everyone is on 2.5.

That matters because 2.5.1 and 2.5.2 were the big cleanup wave. That is where I fixed the image rewrite leak, forced the Block Editor and Media Library to stay local, added full WPCS compliance, proper PHPDoc everywhere, and hardened the CI pipeline. Getting 100% adoption means the failure memory system, the smart wordpress.org detection, the multi layer caching, and the environment detection are now actually running on every site, not just most of them.

It took a lot of boring work to earn that trust. Better diagnostics, clearer admin indicators, automatic cache invalidation when themes or plugins change, and the stability fixes after last week’s outage. People updated because the updates stopped feeling risky.

Now I do not have to think about three different code paths in the wild. The plugin finally behaves like a single product, and that makes the next set of improvements much simpler to ship.

Seeing StaticDelivr in the real world for a while, and it was not on a test WordPress install. I was reading a Uruguay news site covering the national alert for school violence in Salto and Solymar, and noticed the page was pulling its Oxygen font from cdn.staticdelivr.com/gstatic-fonts instead of fonts.gstatic.com.

That is the gstatic proxy I have been building quietly over the last couple weeks. The headers tell the real story: 200 OK, Content-Type: font/woff2, Cache-Control: public, max-age=31536000, Access-Control-Allow-Origin: *, and an Age: 382957 which means that exact woff2 has been sitting hot in cache for over four days. Cf-Ray shows SIN, so Singapore edge served a Uruguay reader with no CORS errors, gzip encoding, and a 16KB transfer.

This is why the recent infrastructure work mattered. It is not just about rewriting plugin and theme assets anymore, it is about taking slow, privacy-leaking third party requests and making them fast and cacheable. Google Fonts normally gives you a short TTL and no real edge control. Through StaticDelivr they get a year of browser cache, proper CORS, and Cloudflare distribution.

Seeing it serve real urgent news traffic, on a site with “LATEST NEWS URGENT” banners, without a single miss, feels like the validation I needed after the outage last week. The system is finally doing what I designed it for: disappearing completely while making the site faster.

Debugging a full outage and getting the servers back online, and this one was not a slow drift, it was a hard drop. Around 11:15 PM both StaticDelivr Origin and Github went straight to 0% availability and stayed there until about 2:45 AM, which is why the 24 hour average is sitting at 92.15% in the graphs. My first thought was a bad plugin deploy, but the failure memory system from 1.7.0 actually did what it was supposed to do and flipped sites to local delivery after two misses, so most WordPress installs never noticed.

Digging into the origin logs, the pattern was clear. After the infrastructure expansion and the more aggressive cache warming from last month, the origin nodes were opening far more files concurrently, and a small leak I introduced during the 2.5.1 and 2.5.2 cleanup meant the image workers never closed temp handles for WebP and AVIF conversions. We hit the file descriptor limit, Nginx could not accept new connections, health checks failed, and the Github mirror marked itself unhealthy because it depends on origin health.

Fixing it meant patching the worker to close handles properly, adding explicit cleanup in the conversion pipeline, raising the systemd LimitNOFILE, and adding a circuit breaker that pauses new fetches at 80% capacity instead of letting it crash. I also tightened the fallback reporter so the plugin clears its 24 hour failure block faster once the CDN is healthy again.

Brought everything back up at 2:45 AM. Availability is back to 100%, latency settled to 137 ms on Origin and 163 ms on Github, and the graphs look normal again. It was a long night of tracing, but the outage forced a fix that needed to happen, and the system is now behaving more predictably and recovering faster when something does go wrong.

After rolling out significant improvements to the WordPress plugin, we have observed a clear surge in adoption across a wide range of websites, reflecting both the technical enhancements and the growing trust in its reliability. The plugin’s streamlined performance, improved compatibility, and optimized workflows have resonated strongly with developers and site owners, leading to a steady increase in daily downloads and more consistent engagement. This momentum highlights not only the value of the new features but also the broader impact of our focus on user-centric design, as the plugin is now being integrated into diverse projects and platforms at a pace that demonstrates its relevance and utility in the WordPress ecosystem.

Addressing significant spikes in latency and dips in availability, and this round of work has been about digging into the patterns behind those swings rather than just smoothing them over. The spikes were not random; they lined up with specific routing paths, cache misses, and a few edge cases where the CDN briefly fell back to slower origins. Fixing those meant tightening how requests are distributed, improving how aggressively the cache warms under load, and cleaning up a couple of slow paths that only showed themselves during peak traffic. Availability dips were tied to the same root causes, so stabilizing the routing logic and reducing cold starts immediately made the graphs look healthier. It is still an ongoing effort, but the system is already behaving more predictably and recovering faster when something does go wrong.

New Sponsors! + Significant updates and expanded infrastructure reliability, and this stretch of work really shows how much the project has grown. The backend now runs on a stronger, more distributed foundation, and the systems that used to feel fragile under load are finally behaving with the kind of consistency you expect from a mature platform. The new sponsors coming onboard add even more stability, giving the project a wider safety net and the resources to keep scaling without cutting corners. Each sponsor strengthens a different part of the stack, so the whole ecosystem feels more resilient, more redundant, and more future proof. It is one of those moments where the technical progress and the community support line up at the same time, and you can feel the project stepping into a new phase.

Improve image types and different visual files, and this work ended up touching more of the pipeline than expected. A lot of the recent testing showed how differently browsers handle formats like WebP, AVIF, PNG, and even older JPEGs, so tightening the detection and delivery logic made a noticeable difference. The system now reads file metadata more accurately, respects the original intent of each format, and picks the right optimized version without forcing everything into a single output type. That means lighter files, cleaner headers, and fewer surprises when themes or plugins load unusual assets. It also helps with caching because each format now has clearer rules for how it is stored, validated, and refreshed. The end result is a smoother experience where images look the same but load faster and behave more predictably across different setups.

Release 2.5.1 and 2.5.2 and these two versions feel like a cleanup wave that makes the whole plugin sturdier, clearer, and easier to maintain. Version 2.5.1 focused on stability inside the WordPress admin by fixing the image rewrite leak, improving how the Block Editor handles requests, and making sure the Media Library and editor always use local files so nothing breaks while people are working. Then 2.5.2 built on that with a full code quality overhaul: complete WPCS compliance, proper PHPDoc everywhere, cleaner formatting, and a stronger CI pipeline that now catches issues automatically. Together they make the plugin feel more professional under the hood and more predictable for users on the surface.

Release major versions with many bug fixes and new features, and this round feels like the kind where everything gets a little sharper and a little more grown up. A lot of long‑standing rough edges finally got cleaned up, and the new features slot in naturally instead of feeling bolted on. The diagnostics work, the smarter dimension handling, the refined syncing, the hardened logic, and all the small fixes across the board make the plugin feel steadier and more predictable. It is the kind of update where you can tell the foundation is stronger because everything behaves more consistently, even under weird setups or messy theme/plugin combinations. It is not flashy, but it is the kind of release that makes the whole project feel healthier.

Release 1.7.0 and this one feels like a stability milestone because it finally gives the plugin a memory of what goes wrong instead of treating every failure as brand new. The new failure memory system tracks when the CDN cannot serve a resource and automatically switches that file to local delivery after two misses, keeping the site fast instead of repeatedly retrying something that is clearly unavailable. It pairs client side detection with server side thresholds, stores failures for 24 hours, and then retries automatically once the cache expires. The admin panel now shows failure counts, blocked resources, and includes a one click clear button so users can reset everything instantly. Images are tracked by URL hash, assets by theme or plugin slug, and the fallback script now reports failures more reliably. Daily cleanup keeps the system tidy, and the whole update makes the CDN layer feel smarter, calmer, and more predictable.

Release new versions and this update lands with a lot more depth because it bundles all the recent work into something that feels cohesive and genuinely more capable. The new smart detection system automatically checks whether themes and plugins exist on wordpress.org, which means only verified public assets get routed through the CDN while custom or premium ones stay local. That alone removes a huge amount of guesswork. The update also brings multi layer caching with in memory, database, and transient storage, daily cleanup, activation hooks, and automatic invalidation when themes or plugins change. Environment detection is now smarter too, so anything coming from private IPs or development domains stays local instead of sending unreachable URLs to the CDN. The admin UI grew with clearer indicators and a full asset breakdown so users can see exactly what is served from where. All of this makes the system faster, cleaner, and more predictable.

Significant debugging shows core file versioning issues, and the more I traced them, the clearer it became that mismatched version strings were quietly breaking caching, fragmenting asset delivery, and causing WordPress to load slightly different variants of the same script depending on how themes and plugins enqueued them. This led to inconsistent cache keys, unnecessary cold starts, and unpredictable dependency resolution in the browser, so tightening the version detection logic and normalizing those parameters made the whole asset pipeline far more stable and predictable.

Performed significant tests and development alongside themes and the results were immediately visible. The deeper I went into theme‑level integration, the more edge cases surfaced, and fixing those ended up tightening the entire pipeline. The bandwidth savings were not just theoretical; they showed up clearly in real traffic patterns with far fewer bytes pushed from origin and a much cleaner distribution curve across the CDN. TTFB also improved in a way that feels structural rather than lucky, which tells me the routing and caching layers are finally behaving the way they were designed to.

A lot of this came from running the plugin through multiple real themes instead of controlled demos. Each theme exposed different loading orders, different enqueue patterns, and different assumptions about asset paths. Solving those forced the system to become more resilient and more predictable. The improvements stack: cleaner rewrites, more consistent cache keys, fewer cold starts, and better compression behavior across formats.

Improving step by step. Each day adds a little more clarity to the whole project and the pieces that felt scattered a week ago are finally starting to line up. The small fixes matter just as much as the big features because they shape how everything feels when someone actually uses it. I keep circling back through the workflow, tightening the rough spots, rewriting parts that no longer match the direction, and polishing the areas that deserve more attention. It is slow, steady progress, but it is the kind that builds real confidence because every change makes the foundation stronger. The update is growing into something that feels more thoughtful, more stable, and more ready for real users to rely on.

Working away for a big update and it feels good to see everything finally coming together. I have been polishing features, tightening the workflow, and making sure the experience feels smooth from the moment someone installs it. There is still a bit to go, but the progress is real and the momentum is strong. It is one of those phases where every small improvement makes the whole project feel more alive.

Version 1.3.1
Fixed plugin/theme version detection to ensure CDN rewriting works correctly for all plugins
Introduced cached helper methods for theme/plugin versions to avoid repeated filesystem work per request
Corrected plugin version detection for various plugin structures and removed incorrect path assumptions
Updated CDN rewriting to use the new version detection
Added rel=”noopener noreferrer” to external links