TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

Cache Management

172 posts · Nov 2010 – Sep 2026

What this trail covers

Cloudflare's cache management has evolved to offer all purge methods (URL, hostname, tag, prefix, everything) to all customers, enabled by a rebuilt "Instant Purge" pipeline. This pipeline utilizes RocksDB-based "CacheDB" alongside cache proxies for active purging, reducing storage requirements by 10x and improving cache hit ratios. Rate limits have also been increased across plans, with Enterprise customers receiving significantly higher throughput. Future work includes optimizing single-file purge performance and enhancing filtering techniques.

All Cloudflare trails
  1. We just shipped support for the ugliest part of HTTP: VaryThis post introduces the implementation of `Vary` header support within Cloudflare's Cache Rules. It details how users can now control how Cloudflare handles request headers declared in the `Vary` response header by choosing between `normalize`, `passthrough`, and `bypass` actions for each header. The `normalize` action is recommended for negotiation headers like `Accept` and `Accept-Language`, while `passthrough` is for headers where exact values matter, and `bypass` is for high-cardinality or personalized headers like `Cookie` or `User-Agent`. The post also clarifies that `Vary: *` always bypasses cache. It explains the interaction between Cache Rules and the `Vary` header, noting that normalization occurs before origin contact and that the origin's `Vary` declaration determines which headers are considered for caching variants.
  2. How we could save petabytes of cache storage with Zstandard and PingoraIntroduced Cache Transcoding, a system that compresses eligible assets (compressible text, >4KiB, no existing Content-Encoding) using Zstandard (level 3) before storing them in cache. This reduces on-disk size by an average of 2.834x, saving storage and bandwidth at the cost of a small CPU increase (4.31 ns/byte encode, 1.56 ns/byte decode). The system preserves original content length and decodes before serving to the client or transferring between cache tiers. Eligibility checks prevent transcoding already compressed media or small assets.
  3. How we saved 100 terabytes of memory by optimizing 1.1.1.1’s DNS cacheThe post details five specific memory optimization techniques applied to the 1.1.1.1 DNS cache: 1. Replacing `Vec<T>` and `String` with `Box<[T]>` and `Box<str>` to eliminate capacity fields and excess heap allocation. 2. Consolidating answer, authority, and additional sections into a single list with offsets, reducing pointer and length overhead. 3. Inferring record owners when identical to the queried domain to avoid redundant storage. 4. Boxing larger enum variants for `RecordData` to reduce wasted space from padding. 5. Packing boolean fields into a bitflag to reduce surrounding padding. The post also describes the benchmarking methodology used to measure memory usage, insert throughput, and lookup latency.
  4. Introducing Cache Response RulesIntroduced Cache Response Rules, a new rule type that operates in the response phase after the origin replies but before caching. This allows for modification of cache behavior based on origin responses, addressing issues like Set-Cookie on static assets, misconfigured Cache-Control directives, and ETag/Last-Modified thrash. Cache Response Rules can strip specific headers (Set-Cookie, ETag, Last-Modified), manage cache tags (set, add, remove), and modify Cache-Control directives (duration, qualified, boolean). This complements existing Cache Rules which operate in the request phase.
  5. Improving Smart Tiered Cache for Public Cloud RegionsThis post introduces the 'Smart Tiered Cache for Public Cloud Regions' feature. It allows users to provide a cloud region hint for origins hosted on AWS, GCP, Azure, and Oracle Cloud. This hint helps Cloudflare select better primary and fallback upper tiers, even when origin IPs are ambiguous due to anycast or regional unicast networking. The system fetches IP range files from cloud providers, matches them against latency probing data, and uses a weighted vote to determine the primary upper tier. Geographic fallbacks are used when probe data is insufficient. The feature is configurable via the dashboard, API, and Terraform.
  7. Your Worker can now have its own cache in front of itIntroduced Workers Cache, a tiered cache that sits in front of Cloudflare Workers. This allows Workers to act as the origin and leverage HTTP caching for server-rendered applications. Key features include configuration via Wrangler, control via Cache-Control headers, support for stale-while-revalidate and Vary headers, programmatic purges by tag or path prefix, and per-entrypoint caching. This flips the architecture from Worker-in-front-of-cache to cache-in-front-of-Worker.
  8. How we found a bug in the hyper HTTP libraryThis post details the discovery and resolution of a race condition bug in the hyper HTTP library used by the Cloudflare Images service. The bug caused intermittent truncation of image responses, particularly for larger images, when communicating between the Workers runtime and the Images service via Unix sockets. The issue was traced to hyper's buffer management when writing response data to the socket, specifically when the receiving end was slower than the sender. A four-line code change in hyper, addressing how shutdown signals were handled in relation to buffer flushing, resolved the issue.
  9. Shared Dictionaries: compression that keeps up with the agentic webThis post introduces Cloudflare's upcoming support for shared compression dictionaries, a feature based on RFC 9842. It details the problem of increased web page weight and deployment frequency leading to caching inefficiencies. The solution involves delta compression where the browser's cached version of a resource acts as the dictionary for subsequent requests. Cloudflare's implementation will start with passthrough support for `Use-As-Dictionary`, `Available-Dictionary`, and `dcb`/`dcz` content encodings, with cache keys varying on these headers. Early testing showed significant bandwidth savings.
  10. Why we're rethinking cache for the AI eraThis post introduces the challenge of AI traffic impacting CDN cache performance due to high unique URL ratios, content diversity, and inefficient crawling patterns. It details how AI crawlers, particularly for training, lead to increased cache miss rates and churn of popular content. The post proposes directions for adapting CDN cache architectures to accommodate AI traffic, suggesting tiered caching strategies based on AI workload latency tolerance (e.g., higher latency for training data collection, lower latency for RAG). It highlights the limitations of traditional LRU cache eviction and pre-fetching strategies in the face of AI crawler behavior.
  11. Improve global upload performance with R2 Local UploadsIntroduced 'Local Uploads' for R2 object storage, allowing data to be written to a storage location close to the client first, then asynchronously copied to the bucket's region. This reduces upload request duration (TTLB) by up to 75% for cross-region uploads. The implementation uses Cloudflare Queues for asynchronous replication tasks and a pull model with a centralized polling service and Gateway Worker for execution. Local Uploads are available for non-jurisdiction restricted buckets.
  12. A deeper look at AI crawlers: breaking down traffic by purpose and industryThis post introduces new capabilities on Cloudflare Radar to analyze AI crawler traffic. It adds 'Crawl purpose' (Training, Search, User action, Undeclared) and 'Industry set' filtering to the AI Insights page. This allows users to break down AI bot traffic by its intended use and compare it against industry benchmarks. The post provides examples of how these new filters reveal different crawling patterns and crawl-to-refer ratios across various industries (News and Publications, Computer and Electronics) and specific use cases (Cryptocurrency).
  13. Resolving a request smuggling vulnerability in PingoraThis post details the discovery and mitigation of an HTTP/1.1 request smuggling vulnerability in the Pingora OSS framework, specifically within its caching component. The vulnerability arose from a parsing bug where, on a cache hit, unread request bodies could be misinterpreted as the start of a subsequent request, leading to potential request hijacking and cache poisoning. Cloudflare mitigated this by disabling traffic to vulnerable components, releasing a patch (Pingora 0.5.0+), and invalidating cached assets.
  14. First-party tags in seconds: Cloudflare integrates Google tag gateway for advertisersIntroduces a direct integration of Google tag gateway for advertisers, enabling first-party serving of Google tags from Cloudflare-proxied domains. This simplifies setup to a one-click process, improves performance and measurement accuracy by rerouting requests through the user's domain, and ensures cookies are set under the website's domain. The integration leverages Cloudflare's reverse proxy capabilities to fetch Google tag JavaScript files and serve them to the end user's browser from the customer's domain.
  15. Cloudflare Snippets are now Generally AvailableThis post announces the General Availability of Cloudflare Snippets, a feature that allows users to control HTTP traffic using lightweight JavaScript code rules. Snippets integrate with the Ruleset Engine and Workers runtime for fast execution and can be used for dynamic header modification, URL rewriting, caching fine-tuning, and more. New features include a code editor, integration with Trace for debugging, and upcoming integration with Secrets Store. The post also clarifies the distinction between Snippets and Cloudflare Workers, highlighting that Snippets are for conditional traffic modifications and extending Rules, while Workers are for compute-intensive tasks and stateful applications. Real-world use cases and code examples are provided.
  16. Improve your media pipelines with the Images binding for Cloudflare WorkersIntroduces the Images binding for Cloudflare Workers, enabling programmatic image transformation, overlaying, and encoding directly within the Workers platform. This binding decouples image optimization from delivery, allowing for more flexible workflows, including transforming images not accessible via URL and chaining multiple transformations without intermediate delivery. It also introduces a new way to specify optimization parameters, allowing for more flexible ordering. Local development support is provided via online and offline modes in Wrangler.
  17. “You get Instant Purge, and you get Instant Purge!” — all purge methods now available to all customersThis post details the engineering effort behind making all cache purge methods available to all customers. It describes the technical challenges of propagating purge requests globally, the limitations of previous lazy-purge mechanisms, and the adoption of RocksDB for "CacheDB" to enable active purging. The new architecture reduces storage needs by 10x, improves cache hit ratios, and allows for significantly higher purge throughput. It also outlines the new rate limits and the token bucket system used for managing purge requests.
  18. Dynamically optimize, clip, and resize video from any origin with Media TransformationsThis post introduces Media Transformations, a new service that extends Cloudflare's existing Image Transformations capabilities to short-form video files. It allows for dynamic optimization, clipping, and resizing of MP4 videos fetched directly from origin storage (e.g., R2, S3). Key features include URL-based transformations with options for mode (video, frame, spritesheet), time, duration, fit, height, width, and audio removal. The service leverages the same On-the-Fly Encoder (OTFE) platform as Stream Live. Input limits are initially set at 40MB for MP4 h.264 encoded files. Transformations are cached, but original content is not cached during beta. Pricing will be per second of output video for video transformations and per frame for image transformations, with a free tier and a monthly cost of $0.50 per 1,000 unique operations.
  19. Cloudflare incident on February 6, 2025This post details an incident where Cache Reserve experienced increased origin requests due to the unavailability of R2, its underlying storage. While Cache Reserve itself did not fail, customers saw an increase in requests to their origin servers as assets became unavailable in Cache Reserve during the R2 outage. This highlights the dependency of Cache Reserve on R2 and the cascading impact of R2 failures on other services.
  20. Sometimes I cache: implementing lock-free probabilistic cachingThis post introduces a probabilistic approach to cache revalidation as an alternative to traditional cache locks. It details the problem of cache stampedes when cache entries expire and multiple requests hit the origin simultaneously. The post presents a probabilistic revalidation strategy where a request to revalidate the cache is sent with a probability 'p' (e.g., 1/500). This approach avoids the latency and fallibility of contacting an external lock service, relying instead on local randomness. The post also discusses the mathematical expectation of requests hitting the origin over time with this probabilistic method and outlines the implementation using Cloudflare Workers and the Cache API.
  21. We made Workers KV up to 3x faster — here’s the dataThis post details the architectural changes made to Cloudflare Workers KV to improve read latency. Key optimizations include: 1. Bypassing the Front Line (FL) layer between Workers and KV services, saving ~20ms per operation by enabling direct connections. 2. Implementing Tiered Cache to resolve cache misses regionally, reducing requests to central storage backends by ~30%. 3. Introducing an in-memory cache within the KV Worker process for the hottest keys (less than 0.03% of keys accounting for nearly half of requests), resolving these reads in under a millisecond. These changes resulted in up to 3x faster hot reads and up to 20ms reduction in latency per operation.
  22. Introducing Speed Brain: helping web pages load 45% fasterIntroduces Speed Brain, a new feature that leverages the Speculation Rules API to prefetch and prerender content for likely next navigations. This aims to reduce page load latency by downloading and rendering pages before the user clicks on them, leading to near-instantaneous loads. Initial testing shows up to a 75% reduction in Largest Contentful Paint (LCP) with an aggressive loading model. Speed Brain will offer more aggressive speculation models in the future, eventually learning to eliminate latency for static websites without configuration.
  23. Instant Purge: invalidating cached content in under 150msThis post details the technical improvements made to Cloudflare's cache purge system, specifically focusing on reducing latency for flexible purges (by tags, hostnames, and prefixes). The core problem addressed was the high latency and scalability limitations of the previous 'lazy purge' system, which relied on Quicksilver for distribution and required significant storage for purge history. The new system is designed to be 'coreless compatible' and achieves sub-150ms average global purge latency. The post explains the challenges of flexible purges compared to URL purges, the limitations of the previous Quicksilver-based system, and the need for a new multi-purge mechanism. It highlights the trade-offs involved in avoiding continuous scanning of all disks worldwide and the benefits of the new system in enabling more purge options for all plan types.
  24. A good day to trie-hard: saving compute 1% at a timeIntroduced a new open-source Rust crate, `trie-hard`, which implements a trie data structure optimized for high-throughput string lookups. This new implementation reduced the CPU utilization of the `clear_internal_headers` function in pingora-origin from 1.71% to 0.34% in production, achieving a significant compute saving by optimizing the process of removing internal headers from HTTP requests.
  25. polyfill.io now available on cdnjs: reduce your supply chain riskThis post introduces an alternative endpoint for polyfill.io hosted on Cloudflare's cdnjs, addressing supply chain risks associated with the original provider. It details the deployment of the polyfill.io service on Cloudflare Workers using Rust, with polyfill files stored in Cloudflare D1 for efficient retrieval. The post also provides a Cloudflare Worker example for automatically rewriting links to the new cdnjs endpoint and highlights the use of Cloudflare's Rust API for metrics and logging.
  26. connect() - why are you so slow?This post investigates the performance implications of using one versus two source IPv4 addresses for cache egress, specifically analyzing the `tcp_v4_connect()` syscall. It identifies a performance bottleneck in the Linux kernel's `__inet_hash_connect()` function, attributing the latency to the port selection algorithm's parity-based iteration. The post details experimental findings using `wrk` and `funclatency` tools, and a custom benchmark, to demonstrate the bimodal distribution of connection latencies and the significant performance difference between even and odd port selection. It also provides a deep dive into the `__inet_hash_connect()` algorithm and its port selection logic, highlighting the impact of the `IP_LOCAL_PORT_RANGE` socket option.
  27. Cache Reserve goes GA: enhanced control to minimize egress costsCache Reserve has graduated to General Availability (GA) with several new features: 1. Enhanced analytics in the Cache overview showing Cache Reserve usage over time and estimated egress savings. 2. A new 'delete storage' button to clear all data in Cache Reserve without affecting the edge cache. 3. Integration with Cache Rules, allowing users to define specific eligibility criteria for content to be stored in Cache Reserve, moving beyond the default of caching all eligible files.
  28. Cache Rules are now GA: precision con...This post announces the General Availability (GA) of Cache Rules, a new feature built on the Rulesets Engine, which provides more granular control over caching configurations compared to the legacy Page Rules. It introduces new configuration options for Cache Rules, including Cache Reserve eligibility, timeout values, custom ports, and cache bypass logic. The post also details the technical challenges and scalability issues with the previous Page Rules implementation (regex-based matching) and explains how the Rulesets Engine's conditional evaluation improves performance and flexibility. It provides examples of using Cache Rules for content changing quickly and for slow origins, and announces the End-of-Life (EOL) process for Page Rules.
  29. How Prisma saved 98% on distribution costs with Cloudflare R2This post details Prisma's migration from AWS S3 + CloudFront to Cloudflare R2 for distributing Prisma ORM engines. The migration was driven by cost reduction, achieving a 98% decrease in distribution costs. The technical implementation involved a gradual DNS rollout using DNS load balancing, with health checks to ensure a fallback to AWS. Prisma also utilized the R2 Super Slurper for migrating historical engine versions. The performance and reliability of R2 were validated through latency tests across 50 global cities, confirming it met or exceeded AWS S3 + CloudFront performance.
  30. Waiting Room adds multi-host and path coverage, unlocking broader protection and multilingual setupsWaiting Room now supports multi-host and path coverage, allowing a single waiting room configuration to protect multiple hostname and path combinations within the same zone. This enables broader site coverage and supports multilingual setups by allowing customization of waiting room templates based on URL locale (subdomain or path). The feature is available to all Enterprise customers with an Advanced Purchase of Waiting Room.
  31. Race ahead with Cloudflare Pages build cachingIntroduced build caching for Cloudflare Pages, allowing for the caching of dependencies (npm, yarn, pnpm, Bun) and build outputs for frameworks like Gatsby.js, Next.js, and Astro. This feature aims to reduce build times by reusing cached artifacts and only computing modified sections of the code.
  32. Sippy helps you avoid egress fees while incrementally migrating data from S3 to R2Introduced Sippy, an incremental migration service for copying data from S3 to R2. Sippy leverages application requests to copy objects to R2 simultaneously when they are requested from S3, thereby reducing egress fees. It works by serving objects from R2 if found, and if not, returning them from S3 while also copying them to R2. This allows for gradual migration and cost savings. The post also details how to enable Sippy via API and suggests pairing it with Super Slurper for full migration completion.
  33. Image optimization made simpler and more predictable: we’re merging Cloudflare Images and Image ResizingThis post announces the merging of Cloudflare Images and Image Resizing into a single product. The primary technical changes involve a new pricing model for image transformations, billing based on unique transformations per month ($0.50 per 1,000 unique transformations) rather than uncached requests, and the introduction of a zero-storage plan for image resizing. Existing Image Resizing customers can opt into the new pricing model.
  34. Cloudflare Fonts: enhancing website font privacy and speedThis post introduces Cloudflare Fonts, a new feature that serves Google Fonts directly from the user's domain, eliminating third-party requests to Google. This is achieved by rewriting HTML on-the-fly using the ROFL (Response Overseer for FL) Rust module, which modifies font URLs to align with the user's domain. These modified responses are then cached within Cloudflare's infrastructure. The feature reduces the number of round trips from eight to one, significantly improving website performance and privacy by preventing data transmission to third-party servers. It also leverages Cloudflare's existing caching infrastructure for substantial performance gains.
  35. Connection coalescing with ORIGIN Frames: fewer DNS queries, fewer connectionsThis post details the research and prototyping of connection coalescing using HTTP/2 ORIGIN Frames. It explains the problem of excessive DNS queries and connections for web page rendering, and how ORIGIN Frames can be used as an explicit signal from servers to clients to enable the reuse of existing TLS connections for different hostnames. The post outlines the two required steps: sending an ORIGIN Frame with an origin-set and ensuring these hostnames are in the TLS certificate's SAN list. It contrasts this with IP-based coalescing and highlights the benefits of reduced latency, improved security by limiting metadata exposure, and simplified management for CDN operators.
  36. How Cloudflare Images addressed the aCropalypse vulnerabilityThis post details how Cloudflare Images and Image Resizing products inherently protect against the aCropalypse vulnerability by re-encoding images and ignoring trailing data. For JPEG, it uses libjpeg-turbo to detect trailers by checking if all input is consumed after the EOI marker. For PNG, it parses the file structure manually after decoding with lodepng to check for data after the IEND chunk. This ensures that images affected by aCropalypse are always re-encoded, providing a guarantee against data leakage.
  37. All the way up to 11: Serve Brotli from origin and Introducing Compression RulesIntroduced end-to-end Brotli compression support, enabling origins to serve Brotli at maximum compression levels (11) directly to Cloudflare. This bypasses Cloudflare's previous decompress-recompress cycle for Brotli, reducing latency and bandwidth. Also introduced Compression Rules for Enterprise customers, allowing granular control over content compression based on media type and extension, and deprecating the manual Brotli toggle.
  38. How we scaled and protected Eurovision 2023 voting with Pages and TurnstileThis post details how Cloudflare's fast cache propagation infrastructure was leveraged to handle spikes in traffic for the Eurovision voting application. The based.io platform used a cache time of three seconds for its discovery registry, with a 20% cache hit ratio for normal traffic and up to 80% during an attack. This demonstrates the effectiveness of combining Cloudflare CDN and DDoS protection for serving dynamic and real-time content.
  39. Speeding up APIs with Ricochet for API GatewayIntroduces Ricochet for API Gateway, a feature that enables automatic caching of API requests, including previously un-cacheable types like GraphQL POST requests. Ricochet reduces API latency by serving cached responses from Cloudflare's edge, thereby decreasing origin load. It uses API session identifiers or request parameter hashes to ensure secure and personalized caching. The system also implements automatic cache invalidation for RESTful endpoints when non-safe HTTP methods (POST, PUT, DELETE) are detected for a path that has been cached via a safe method (GET, OPTIONS, HEAD).
  40. Speeding up your (WordPress) website is a few clicks awayThis post introduces a method to improve website performance by identifying and prioritizing critical images (like LCP images) before they are fully parsed by the browser. It leverages Cloudflare Workers and provides a JavaScript snippet to implement this optimization. The post analyzes HTTP Archive data to quantify the opportunity for performance improvement and discusses heuristics for identifying likely LCP images, such as their position in the HTML and their size. It also references Chrome 114's image prioritization experiment.
  41. Part 2: Rethinking cache purge with a new architectureThis post details the architecture of Cloudflare's new "coreless" cache purge system, focusing on the end-to-end flow for purge by URL requests. Key components introduced include Purge Ingest workers for local validation and cache key generation, Purge Queue workers (Durable Objects) for persistent queuing and regional load balancing, Regional Autoscaler workers for managing Durable Object load, and Purge Fanout workers for efficient inter-region broadcasting. The system aims to reduce latency and increase throughput by distributing purge requests more effectively and performing local validation to filter out superfluous purges. Flexible purges are partially integrated, benefiting from edge authorization and validation.
  42. It's never been easier to migrate thanks to Cloudflare's new Migration HubThis post introduces the Cloudflare Migration Hub, a one-stop-shop for CDN migrations, and relaunches Turpentine, a project to translate VCL to Cloudflare Workers. It highlights new migration guides for self-serve customers and the establishment of a Professional Services group for assisted migrations. The hub includes product maps comparing Cloudflare features to Akamai and Fastly, with code examples. Success stories showcase cost savings and improved reliability after migrating from Akamai and other vendors.
  43. How Kinsta used Workers and Workers KV to improve cache hit rates by 56%Kinsta details how they used Cloudflare Workers and Workers KV to improve cache hit rates by 56.3%. They implemented custom cache keys by appending domain ID and feature flags (like Polish) to the request URL, ensuring cache freshness upon configuration changes. They also microcached Workers KV data with a 30-second TTL, reducing KV read operations by 80% and improving responsiveness. The post provides code examples for customizing cache keys and implementing Workers KV caching logic.
  44. Smart Hints make code-free performance simpleThis post introduces 'Smart Hints,' a new feature that automates the application of Early Hints and Fetch Priorities. It leverages Cloudflare's network, Real User Measurements (RUM), and heuristics to dynamically determine optimal resource prioritization for web assets, eliminating the need for manual configuration by developers. The goal is to improve page load performance by intelligently suggesting how browsers should load resources.
  45. Welcome to Speed Week 2023This post introduces "Speed Week 2023" and discusses the importance of measuring what truly matters for website performance, contrasting metrics like Time to First Byte (TTFB) with Real User Monitoring (RUM) and Core Web Vitals. It highlights new products and features aimed at improving application performance and user experience, and reiterates Cloudflare's commitment to being the fastest network. It also touches on migration tools and the evolution of performance metrics.
  46. Cloudflare is deprecating RailgunThis post announces the deprecation of Cloudflare Railgun, a delta compression technology for accelerating dynamic content. It explains the reasons for deprecation, including maintenance burden and the availability of superior alternatives. The post recommends migrating to Cloudflare Tunnel for persistent, secure connections without public IPs, Argo Smart Routing and Cloudflare Network Interconnect for performance improvements, and R2 storage or Bandwidth Alliance partners for reducing egress fees. The deprecation timeline is set for January 31, 2024.
  47. Reduce latency and increase cache hits with Regional Tiered CacheIntroduced Regional Tiered Cache as a new layer within the existing Tiered Cache offering. This new layer sits between lower-tier and upper-tier data centers, serving as a regional cache. When a lower-tier cache misses, it first queries the regional tier. If the regional tier also misses, it then queries the upper-tier. The regional tier caches the content, benefiting other lower-tier data centers within the same region. This aims to reduce latency for global traffic by avoiding long-distance fetches to upper-tier data centers, while still reducing origin load. It is available for Enterprise customers using Smart or Custom Tiered Cache topologies.
  48. Cloudflare R2 and MosaicML enable training LLMs on any compute, anywhere in the world, with zero switching costsThis post introduces Cloudflare R2 as a solution for storing large datasets and model checkpoints for AI model training, specifically highlighting its zero-egress pricing model. It demonstrates how R2, when combined with MosaicML's tools (StreamingDataset and Composer), enables flexible and cost-effective training of large language models across multiple cloud providers without incurring prohibitive data transfer fees. This significantly enhances the utility of R2 beyond traditional caching by enabling it as a foundational storage layer for computationally intensive AI workloads.
  49. The S3 to R2 Super Slurper is now Generally AvailableIntroduced the general availability of R2 Super Slurper for one-time data migration from S3 to R2. Enhanced speed (up to 5x increase in objects copied per second), reliability (robust retries, chunked transfers for larger objects), and added the ability to copy data between R2 buckets. Also announced the upcoming private beta for incremental migration, which copies files from origin to R2 as they are requested.
  50. Introducing Object Lifecycle Management for Cloudflare R2Introduced Object Lifecycle Management for Cloudflare R2, enabling users to define rules for object expiration and aborting incomplete multipart uploads. This feature can be configured via the R2 dashboard or the S3-compatible API, with examples provided for both.
  51. The state of HTTP in 2022This post details the significant advancements in HTTP protocols during 2022, including the publication of HTTP/3 and its underlying QUIC protocol, the republication of core HTTP specifications (Semantics, Caching, HTTP/1.1, HTTP/2), and the exploration of Early Hints (RFC 8297) for performance improvements. It also covers new privacy-focused intermediation specifications like MASQUE (RFC 9298) and Oblivious HTTP (OHTTP), and security enhancements with Digest Fields and HTTP Message Signatures. The post highlights Cloudflare's participation in these developments and their integration into Cloudflare products.
  52. Migrate from S3 easily with the R2 Super SlurperIntroduced the R2 Super Slurper, a feature to migrate data from S3-compatible object storage to Cloudflare R2. It offers two modes: a one-time 'giant slurp' for bulk imports and a future 'sip by sip' incremental migration where objects are copied to R2 upon their first request. The 'sip by sip' flow involves checking R2, fetching from origin if not found, serving from R2, and then copying to R2 for subsequent requests.
  53. Reduce origin load, save on cloud egress fees, and maximize cache hits with Cache ReserveThis post announces the open beta of Cache Reserve, a new feature that extends Cloudflare's cache by utilizing R2 persistent storage. It explains how Cache Reserve helps reduce origin load and egress fees by storing content for longer periods (default 30 days) to prevent eviction from traditional caches. The post details the technical implementation of Cache Reserve, highlighting its reliance on Cloudflare's developer platform (R2, Workers, Durable Objects) and Pingora for origin fetches and metadata management. It also explains how Cache Reserve integrates with Tiered Cache to further shield origins and improve cache hit ratios.
  54. Partial Cloudflare outage on October 25, 2022Introduced a bug in the Tiered Cache system by adding distributed tracing logic that cleared control headers, leading to 530 DNS errors for requests missing hostname information. This caused approximately 5% of requests to fail at peak. The incident was resolved by rolling back the faulty component. Remediation steps include earlier integration of larger data centers in release plans, expanded acceptance test coverage for Tiered Cache topologies, more aggressive alerting for requests lacking full context, and ensuring systems fail fast during development.
  55. Cloudflare Pages gets even faster with Early HintsThis post introduces the integration of Early Hints with Cloudflare Pages. It explains how Early Hints work by sending `preload` and `preconnect` Link headers as a 103 Early Hints response before the full HTML response, allowing browsers to start loading critical resources sooner. The post details performance testing results showing significant reductions in LCP and document load times. It also explains how to enable Early Hints on Pages, including automatic support for `pages.dev` domains and manual enablement for custom domains, as well as the ability to transform `<link>` HTML elements into `Link` headers.
  56. Dynamic URL redirects: 301 to the futureIntroduced Dynamic Redirects, a new product built on the Rulesets Engine, allowing for more sophisticated URL redirects based on request parameters like country of origin or preferred language. This expands upon previous redirect capabilities like Page Rules and Bulk Redirects by enabling dynamic URL generation and leveraging a wider range of filtering fields. The product also offers a dedicated quota, increasing the total number of available rules for customers.
  57. Introducing Cache Rules: precision caching at your fingertipsIntroduces Cache Rules as a successor to Page Rules for caching functionality. Cache Rules allow for more granular control over caching behavior by matching on additional criteria beyond URLs, such as HTTP request headers (content-type, cookies, user-agents, hostnames). It also introduces a new ruleset engine that separates caching actions into a dedicated product, improving visibility and reducing rule evaluation compute. Cache Rules will take precedence over existing Page Rules for caching. A one-click migration tool is planned for the future.
  58. Introducing Configuration RulesThis post introduces Configuration Rules as a successor to Page Rules. Configuration Rules significantly enhance granular control over Cloudflare features by allowing users to apply settings based on a wider range of HTTP request attributes (URLs, cookies, country of origin, etc.), not just URLs. This enables advanced use cases like A/B testing of features and more nuanced security configurations, moving beyond the limitations of Page Rules.
  59. The future of Page RulesThis post announces the replacement of Page Rules with four new dedicated products: Cache Rules, Configuration Rules, Dynamic Redirects, and Origin Rules. Cache Rules specifically addresses 'everything caching' and offers increased rules quota (e.g., 10+ for Free, 25+ for Pro, 125+ for Business/Enterprise) compared to the previous 3-20 Page Rules. These new rules are built on the Rulesets Engine, providing a more scalable and extensible platform. The order of execution for these new rules is now explicit: Origin Rules, then Cache Rules, then Configuration Rules, and finally Dynamic Redirects. This provides greater clarity and debuggability compared to the monolithic Page Rules.
  60. Where to? Introducing Origin RulesThis post introduces Origin Rules, a new product that allows for overriding the host header, Server Name Indication (SNI), destination port, and DNS resolution of matching HTTP requests. This directly addresses the complexity of routing traffic to different origins, especially for SaaS platforms and applications listening on non-standard ports, by providing a no-code solution that previously required custom code (Workers, Spectrum) or self-managed reverse proxies. It enhances cache management by enabling more sophisticated origin selection, including routing to cloud storage endpoints like S3-compatible buckets, and supports advanced use cases like A/B testing different cloud providers and routing users to the closest storage instance.
  61. Store and retrieve your logs on R2This post introduces the capability to store and retrieve Cloudflare logs directly on Cloudflare R2 object storage. It details the cost benefits of using R2 for logs, including no egress fees and centralized storage. It provides API examples for configuring Logpush jobs to R2 and for retrieving logs from R2 using the Log Retrieval API. The post also mentions future plans for log analysis and forensics capabilities on R2.
  62. SVG support in Cloudflare ImagesCloudflare Images now supports SVG files by implementing a security filter that removes potentially harmful elements like scripts, hyperlinks, and cross-origin resource references. This filter is open-source and written in Rust for streaming processing. Server-side resizing variants are disabled for SVGs as they are vector-based and inherently scalable.
  63. R2 is now Generally AvailableThis post announces the general availability of R2, Cloudflare's object storage service, highlighting its key features: S3 compatibility, automatic region selection, deep integration with Cloudflare Workers, presigned URLs, public bucket support, and transparent pricing (no egress fees). It marks a significant expansion of Cloudflare's data storage and management capabilities, directly impacting cache management by offering a cost-effective alternative to traditional object storage and enabling new patterns for data access and edge compute integration.
  64. Using Cloudflare R2 as an apt/yum repositoryThis post details how Cloudflare uses R2 object storage and a Cloudflare Worker to host apt and yum repositories for distributing cloudflared. It explains the structure of apt/yum repositories, how to create .deb packages using fpm, generate repository metadata with reprepro, upload these files to R2, and serve them via a Cloudflare Worker. This enables a scalable, serverless, and globally distributed package distribution system.
  65. Waiting Room Event Scheduling protects your site during online eventsIntroduced Waiting Room Event Scheduling, allowing enterprise customers to schedule changes to Waiting Room settings and custom queueing pages ahead of time for online events. This includes support for cascading changes across different event stages (pre-event, during event, post-event). New queuing methods 'Reject' and 'Passthrough' were added. 'Reject' presents a static HTML page to offload traffic, while 'Passthrough' allows unrestricted access but provides traffic stats. 'Queue All' can be quickly activated on a passive waiting room for emergency traffic control. Event Scheduling also supports pre-queuing with optional shuffling to manage traffic before an event starts and ensure fairness.
  66. Automatic Signed Exchanges may dramatically boost your site visitor numbersThis post details the performance improvements observed in customers using Cloudflare's Automatic Signed Exchanges (SXG) feature. It presents metrics showing improvements in Largest Contentful Paint (LCP), First Contentful Paint (FCP), and Time to First Byte (TTFB) for a significant percentage of users. It also introduces Dynamic SXG, a new capability that allows SXG to be used with server-side personalization by adding a 'Vary: Cookie' annotation, and announces the expansion of SXG support to Chromium-based desktop browsers.
  67. Managed Transforms: templated HTTP header modificationsIntroduced Managed Transforms as a simplified interface for common HTTP header modification use cases, building upon existing Transform Rules. This feature offers one-click solutions for adding bot management headers (bot score, JA3 hash) and security headers (HSTS, CSP, Permission-Policy). It aims to reduce user friction by packaging frequently used Transform Rule configurations into easily accessible toggles, thereby improving operational efficiency, security, and developer experience.
  68. Early Hints update: How Cloudflare, Google, and Shopify are working together to build a faster Internet for everyoneThis post details the integration and performance impact of Early Hints, a feature that leverages HTTP 103 status codes and Link headers to send resource hints to the browser before the full server response is compiled. It explains how Early Hints reduce server 'think time' by enabling the browser to preload resources and initiate preconnect connections. The post highlights Cloudflare's role in caching and emitting Early Hints from its edge network, reducing transit latency. It also presents lab testing results demonstrating significant improvements in First Contentful Paint (FCP) and Largest Contentful Paint (LCP) across various network conditions, and mentions collaboration with Google and Shopify for development and testing.
  69. Part 1: Rethinking Cache Purge, Fast and Scalable Global Cache InvalidationThis post details the current state of Cloudflare's cache purge pipeline, including its architecture, the challenges of scale, speed, and scope in cache invalidation, and benchmarks for current purge performance across different regions and purge types (URL vs. others). It sets a baseline for future improvements with a new purge system.
  70. Announcing the Cloudflare Images Sourcing KitIntroduced the Cloudflare Images Sourcing Kit, a new capability for bulk importing images from external repositories into Cloudflare Images. This kit allows users to define sources (initially AWS S3 buckets), reuse these definitions for incremental imports, filter for actual images, specify target paths and filenames, and access logs for bulk operations. The UI guides users through creating source definitions and starting migration processes, with plans for broader repository support and a CLI interface.
  71. A New Hope for Object Storage: R2 enters open betaThis post announces the open beta of Cloudflare R2, an object storage solution designed to eliminate egress charges. It details R2's internal and external APIs (In-Worker API and S3-compatible API), its features including object size limits and strong consistency, and its pricing model with a forever-free tier. Future plans focus on performance improvements, global distribution, and feature expansion such as TTL support, public buckets, pre-signed URLs, and integration with Cloudflare's cache.
  72. Introducing Cache Reserve: massively extending Cloudflare’s cacheIntroduced Cache Reserve, a new persistent data store built on R2, to act as an ultimate upper-tier cache. Cache Reserve ensures all cacheable content is persistently served, regardless of request frequency, thereby increasing cache hit ratios and reducing origin egress fees. It complements the existing popularity-based cache and tiered cache by providing guaranteed SLAs for content storage duration. Cache Reserve respects cache-control headers and purge requests for content updates.
  73. Logs on R2: slash your logging costsThis post introduces the capability for Cloudflare enterprise customers to use Logpush to store logs on R2. It highlights the cost savings compared to traditional object storage (e.g., S3) and provides an example of potential savings for a high-traffic website. It also mentions upcoming features like a Log Retrieval API and new log datasets (Network Analytics Logs, Worker's Trace Events), log filtering, and custom log formatting.
  74. From 0 to 20 billion - How We Built Crawler HintsThis post details the engineering challenges and solutions for building Cloudflare's Crawler Hints product. It describes the system architecture, including the use of Kafka for data pipelines, Redis as a distributed buffer for aggregation and deduplication, and a dispatcher service for sending batches of URLs to search partners via the IndexNow API. The post highlights the importance of customer opt-in, monitoring, and system resilience for rolling out such a large-scale product.
  75. Maximum redirects, minimum effort: Announcing Bulk RedirectsIntroduced Bulk Redirects, a new product allowing users to upload and manage hundreds of thousands of URL redirects via the dashboard without writing code. This addresses limitations of Page Rules (125 redirects) and Cloudflare Workers for users uncomfortable with coding. Bulk Redirects supports 301, 302, 307, and 308 status codes, and allows specifying destination ports. It avoids ambiguous wildcard characters, opting for explicit matching. The implementation involves a Bulk Redirect List (edge dictionary) and a backend system for processing these redirects.
  76. Crawler Hints Update: Cloudflare Supports IndexNow and Announces General AvailabilityIntroduced support for the IndexNow protocol within Crawler Hints, enabling websites to notify search engines about content creation, updates, or deletions. Made Crawler Hints generally available to all Cloudflare customers for free, accessible via a single button click in the Cache tab of the dashboard. This aims to increase the proportion of relevant crawls and limit unnecessary ones, improving customer experience and reducing origin server load.
  77. “Look, Ma, no probes!” — Characterizing CDNs’ latencies with passive measurementThis post introduces a novel method for passively measuring and predicting CDN latencies. It details a two-step process: first, predicting Anycast catchments by compiling CDN network footprints from various data sources (ISPs, PeeringDB, IXP databases, BGP data) to infer routing paths and data center usage. Second, estimating CDN path latencies by utilizing Cloudflare's own passive RTT measurements as a proxy. This approach aims to overcome the limitations of active measurements by inferring performance characteristics that cannot be directly observed, thereby enabling better understanding of CDN performance and validation of network models.
  78. Geo Key Manager: Setting up a service for scaleThis post details the scaling challenges and architectural evolution of Cloudflare's Geo Key Manager service. It describes how increased demand, particularly from API traffic and geographical data residency requirements (like GDPR), led to performance degradation and TLS handshake failures. The post explains the interaction between the initial TLS termination service, keynotto (a Rust-based key signing service), and gokeyless (a Go-based Keyless SSL keyserver). It highlights issues like head-of-line blocking in keynotto's connection handling and the architectural decisions made to optimize RSA key signatures using Rust and BoringSSL, contrasting it with Go's performance characteristics. The post also touches upon the use of worker pools in gokeyless and the decision to move gokeyless to BoringCrypto for FIPS validation.
  79. Coalescing Connections to Improve Network Privacy and PerformanceThis post details a study and implementation of Connection Coalescing, a technique that allows subresources from different hostnames to be fetched over the same TLS connection. This reduces the number of TLS handshakes and SNI exposures, improving privacy and performance. The study involved dividing Cloudflare customers into control and experiment groups, enabling coalescing for the experiment group, and measuring the impact on TLS connections and page load times. Results showed a significant reduction in TLS connections for Chrome and a moderate reduction for Firefox, with no observed performance degradation.
  80. Introducing SSL/TLS RecommenderIntroduces the SSL/TLS Recommender tool, which guides users to stronger SSL/TLS configurations for the backend connection from Cloudflare to origin servers. It details the various SSL/TLS encryption modes (Off, Flexible, Full, Full (strict), Strict) and explains the importance of securing the backend connection, addressing issues like partial HTTPS support and content inconsistencies between HTTP and HTTPS.
  81. Waiting Room: Random Queueing and Custom Web/Mobile AppsIntroduced random queueing as an alternative to FIFO queueing for Cloudflare Waiting Room. This new method selects users randomly from the queue, providing a fair chance for all participants, especially beneficial for short-lived, high-demand events. The implementation maintains the underlying FIFO structure, allowing for seamless transitions between queueing methods and preserving user arrival order when switching back to FIFO.
  82. Benchmarking Edge Network Performance: Akamai, Cloudflare, Amazon CloudFront, Fastly, and GoogleThis post details a measurement experiment using Real User Measurement (RUM) data to benchmark Cloudflare's network performance against Akamai, Amazon CloudFront, Fastly, and Google. It describes the methodology, including the use of the Resource Timing API and the measurement of TCP connection time, TTFB, and TTLB. The results indicate Cloudflare's #1 position in most performance metrics across various network segments. The post also emphasizes the importance of granular, per-ASN measurement for continuous improvement.
  83. Early Hints: How Cloudflare Can Improve Website Load Times by 30%This post introduces Cloudflare's implementation of Early Hints, a web standard utilizing the HTTP 103 Early Hints status code. It explains how Cloudflare leverages its edge network to serve these hints on behalf of origin servers, allowing browsers to asynchronously fetch critical resources during server 'think time'. This reduces page load times, particularly for first-time visitors, by enabling parallelization of resource fetching and page rendering. The post contrasts Early Hints with HTTP/2 Server Push, highlighting Early Hints' 'hinting' approach and its ability to work with 'rel=preload' and 'rel=preconnect' for improved performance.
  84. Cloudflare Images Now Available to EveryoneThis post introduces Cloudflare Images, a new product that unifies image storage, resizing, optimization, and delivery. It addresses legacy image pipeline challenges by separating stored images from variants, eliminating egress costs, and providing built-in access control via signed URLs. The product supports common file formats, direct creator uploads via API tokens, and configurable variants for resizing with various fit options. It also optimizes image delivery by automatically selecting optimal formats (WebP, PNG, JPEG, GIF) and plans to add AVIF support and analytics.
  85. How Cloudflare Images can make your life easierThis post introduces Cloudflare Images as a new product that simplifies image pipelines for customers. It addresses customer pain points such as egress fees, fragmented storage solutions (multiple buckets), slow load times due to unoptimized images, and high maintenance overhead. Cloudflare Images offers zero egress costs, a unified storage solution, automatic image variant generation, and on-the-fly optimization based on browser capabilities. It provides APIs and a dashboard for uploading, deleting, updating, and resizing images, minimizing engineering effort required for image management.
  86. Improving Origin Performance for Everyone with Orpheus and Tiered CacheThis post introduces Tiered Caching as a free offering for all customers, dividing Cloudflare's data centers into a hierarchy of lower and upper tiers to improve cache hit ratios, reduce origin load, and enhance performance. It also announces the free availability of Orpheus, a system that routes around internet problems to ensure origin reachability by analyzing data from users on every path and ordering them per data center to eliminate connection errors and minimize packet loss. Orpheus improves origin reachability by 23% and reduces 522 errors. The post details how Tiered Cache works, its benefits (e.g., 60% reduction in cache miss rate), and how to enable it. It also explains Orpheus's mechanism and its synergy with Load Balancing, Cloudflare Network Interconnect, and Tiered Cache.
  87. Improve site load times and SEO with one-click support for Signed Exchanges on Google SearchIntroduced one-click support for Signed Exchanges (SXG) for Google Search. This feature leverages Cloudflare's existing expertise in certificate management and TLS delivery infrastructure to generate SXGs. The process involves fetching original content, adding a Digest header with Merkle Integrity Content Encoding, stripping irrelevant/sensitive headers, chaining headers and metadata for signature calculation, and packing the final binary. This enables faster content delivery from search engines and aggregators, improving user experience and SEO.
  88. Vary for Images: Serve the Correct Images to the Correct BrowsersIntroduced support for the HTTP Vary header specifically for images, enabling the serving of different image formats (e.g., WebP, AVIF) based on the browser's Accept header. This feature ensures that intermediate caches, like Cloudflare's, serve the correct image variant to each user-agent, preventing the delivery of incompatible or unoptimized content. The implementation involves parsing the Accept header and creating distinct cache entries for each image variant. Configuration for Vary for Images is available via the Cloudflare API for Pro, Business, and Enterprise customers, supporting specific file extensions and requiring origin servers to send the `Vary: Accept` response header. Purging varied images will purge all content variants for that URL.
  89. Introducing Smart Edge RevalidationIntroduced Smart Edge Revalidation, a feature that automatically adds `Last-Modified` headers to cached objects when the origin response is missing them. This enables efficient revalidation for a larger percentage of cached objects, reducing unnecessary origin calls, bandwidth waste, and improving browser page load times. The feature is enabled automatically for all customers.
  90. Transform Rules:"Requests, Transform and Roll Out!"Introduced Transform Rules as a dedicated feature for modifying HTTP requests at the edge, specifically for URL normalization, URL rewriting, and header modification. This provides a simpler, script-free alternative to Cloudflare Workers for these common tasks, aiming to offload heavy lifting from origin servers and improve application performance and security by ensuring consistent request formatting before security rules are applied.
  91. CDN-Cache-Control: Precision Control for your CDN(s)Introduced CDN-Cache-Control and Cloudflare-CDN-Cache-Control response headers to provide granular control over CDN caching behavior, allowing origins to specify caching directives for specific CDNs separately from other intermediaries and browsers. Detailed header precedence rules and interactions with existing Cloudflare features like Edge Cache TTL and Browser Cache TTL page rules. Provided examples of how these new headers can be used to manage caching behavior across multiple caching layers.
  92. Dynamic URL Rewriting at the edge with CloudflareIntroduced Transform Rules, a new feature allowing administrators to create URL rewrite rules at the edge. This enables dynamic and static rewrites of URI Paths and Queries, improving SEO, security, and user experience. Also introduced URL Normalization to prevent bypasses of security rules via URL encoding and simplify traffic processing.
  93. Third Time’s the Cache, No MoreThis post details the evolution of Cloudflare's caching behavior for requests with query strings. Previously, these requests required three misses before being cached. This behavior, originating from 2010, was re-evaluated and found to be overly defensive. An A/B test demonstrated that caching on the first request for queries resulted in a minor, acceptable increase in disk writes (2.5%) while improving cache hit rates by an average of +3% for Enterprise customers and reducing origin bytes served by -5%. This change has been rolled out, leaving the 'third time's the charm' quirk behind.
  94. Automatic Platform Optimization post-launch reportThis post details the post-launch performance improvements of Automatic Platform Optimization (APO) for WordPress, using WebPageTest and Chrome User Experience Report data to demonstrate significant reductions in TTFB, First Paint, FCP, and LCP. It also outlines extended functionality released since launch, including smart caching for marketing query parameters, improved cache hit ratios by handling requests without valid Accept headers, and enhanced security against cache poisoning by bypassing caching for specific request headers or GET requests with bodies. The integration with Page Rules is also mentioned.
  95. Introducing: Smarter Tiered Cache Topology GenerationIntroduced Smart Tiered Cache Topology, which dynamically selects the single best upper-tier data center for each origin based on Argo performance and routing data. This replaces the previous static collection of upper-tier data centers. For self-serve customers, this is enabled by default when Argo Tiered Cache is active. Enterprise customers have more configuration options. The feature also provides new analytics in the Cache tab for Tiered Cache, showing primary/secondary data centers, cached hits, hit ratio, and bytes saved.
  96. Tiered Cache Smart TopologyIntroduced 'Smart Topology' for Tiered Cache, which automatically identifies the optimal data center for origin requests based on latency probing. This feature aims to maximize cache hit ratios by selecting a single proxying data center close to the origin. It includes a topology selection algorithm that uses a leaderboard of data center latencies, with a fallback to a generic topology when assumptions about origin location or Anycast networks are violated. The algorithm considers 24-hour median latency and includes a second-lowest latency data center as a fallback.
  97. Moving Quicksilver into productionThis post details the migration of Quicksilver, a core distributed data store, from Kyoto Tycoon to a new system. It describes the implementation of QSKTBridge for parallel replication and phased rollout, the challenges encountered with replication saturation due to bootstrapping and I/O saturation from aging SSDs, and the performance improvements observed after migrating the FL component to Quicksilver. It also discusses the evolution of replication topology management from static Salt configurations to dynamic DNS-based approaches.
  98. My internship: Brotli compression using a reduced dictionaryThis post details an internship project that improved Brotli compression ratios for web content by optimizing the use of its static dictionary, particularly for compression levels 5-9. The approach involved generating specialized, reduced dictionaries for HTML, CSS, and JavaScript based on content type hints and employing fast dictionary lookup data structures like radix tries, hash tables, and bloom filters. This optimization aims to improve compression at a negligible performance cost.
  99. Building Automatic Platform Optimization for WordPress using Cloudflare WorkersThis post introduces Automatic Platform Optimization for WordPress, a new feature that uses Cloudflare Workers to provide zero-config edge caching for HTML content. It explains how this feature combines the existing Cloudflare cache with Workers KV to improve cache cold starts globally. The post details the HTML caching rules, the implementation with and without the Cloudflare for WordPress plugin, and the use of custom headers like `cf-edge-cache` to communicate caching rules from the origin. It also discusses how Workers KV is used to improve loading times for cache cold starts from any location.
  100. Introducing Automatic Platform Optimization, starting with WordPressThis post introduces Automatic Platform Optimization (APO) for WordPress, a new service that extends Cloudflare's edge caching capabilities to dynamic content. APO intelligently caches dynamic content, including HTML, by leveraging Cloudflare Workers, effectively serving entire websites from the edge network. This significantly reduces origin requests and processing time, leading to substantial improvements in Time to First Byte (TTFB), First Contentful Paint (FCP), and Speed Index. The service is integrated via a WordPress plugin and offers tiered pricing. Performance improvements were validated through internal testing and external validation by Kinsta.
  101. Cloudflare’s Always Online and the Internet Archive Team Up to Fight Origin ErrorsThis post details the integration of the Internet Archive's Wayback Machine with Cloudflare's Always Online service. This partnership allows Always Online to serve archived copies of webpages when a customer's origin server is down, enhancing website availability and contributing to the Internet Archive's mission. The integration involves sharing hostname and popular URL information with the Internet Archive for crawling and archiving, and when an origin error occurs (520-527 status codes), Cloudflare first checks its local cache and then fetches the most recent archived version from the Internet Archive to serve to visitors, displaying a banner to indicate the origin is unreachable.
  102. Migrating cdnjs to serverless with Workers KVMigrated cdnjs from a traditional origin server infrastructure to a serverless architecture using Cloudflare Workers and Workers KV. This involved storing compressed versions of all cdnjs assets (Brotli and gzip) in Workers KV, enabling faster delivery and reduced bandwidth. The contribution process was also revamped with a new repository (cdnjs/packages) and an automated bot for package updates and validation, improving security and maintainability.
  103. Delivering HTTP/2 upload speed improvementsThis post details an investigation and fix for slow HTTP/2 upload speeds, particularly on high-bandwidth connections. The issue was identified as a bottleneck in NGINX's HTTP/2 receiver flow control, specifically the fixed-size `client_body_buffer_size`. The solution involved implementing an autotuning mechanism for the HTTP/2 request body buffer size, dynamically adjusting it based on the network's Bandwidth-Delay Product (BDP) to match TCP's autotuning behavior. This resulted in significant upload speed improvements, bringing HTTP/2 performance closer to or exceeding HTTP/1.1.
  104. Introducing Cache AnalyticsIntroduced Cache Analytics, a new tool providing deeper exploration capabilities into Cloudflare's caching and content delivery services. Key features include: visibility into resources missing from cache, expired, or never eligible for cache; filtering by hostnames, top URLs missing cache, cache status, path, and content type; views of requests and data transfer; and time-series graphs showing "Served by Cloudflare" vs. "Served by Origin". Detailed explanations of cache statuses (Dynamic, Revalidated, Expired, Miss) and their optimization implications are provided. Cache Analytics is available for Pro, Business, and Enterprise plans, with Pro having 3 days of history and Business/Enterprise having 21 days.
  105. Backblaze B2 and the S3 Compatible API on CloudflareThis post details how Cloudflare Workers can be used to interact with S3-compatible APIs, specifically Backblaze B2. It provides a code example using the `aws4fetch` library within a Cloudflare Worker to sign requests to a Backblaze B2 bucket, demonstrating how to configure environment variables in `wrangler.toml` for authentication and bucket endpoint. It also highlights the Bandwidth Alliance's role in reducing first-mile bandwidth costs between Cloudflare and storage providers.
  106. Why We Started Putting Unpopular Assets in MemoryThis post details a new hybrid storage system that places unpopular assets in memory (transient cache) before promoting them to SSDs after a certain number of accesses. This reduces SSD wear and improves cache hit tail latency by minimizing writes to SSDs, which can slow down reads. The system competes for memory with the page cache and process memory, requiring careful tuning. The implementation was rolled out conservatively to newer servers and a subset of assets.
  107. Pwned Passwords Padding (ft. Lava Lamps and Workers)Introduced dynamic padding to the Pwned Passwords API responses using Cloudflare Workers. This padding is generated on a per-request basis to obscure the exact size of API responses, mitigating traffic analysis attacks. The padding consists of randomly generated hash suffixes with a usage count of 0, and is applied to meet a minimum response size and add variable additional padding.
  108. When Bloom filters don't bloomThis post details the author's experience using Bloom filters for large-scale data deduplication, addressing performance issues encountered with traditional tools like 'sort' and 'uniq'. It explains the principles of Bloom filters, their parameters (n, m, k, p), and the trade-offs involved. The author developed a tool 'mmuniq-bloom' and encountered performance bottlenecks due to random memory access and cache misses, even with an optimized Bloom filter implementation. The analysis highlights the significant cost of memory fetches and the impact of cache misses on performance, suggesting that reducing memory accesses is crucial for optimizing such data structures.
  109. Cloudflare response to CPDoS exploitsThis post details Cloudflare's defenses against three newly disclosed cache poisoning denial-of-service (CPDoS) vulnerabilities: HTTP Header Method Override (HMO), Oversized HTTP Headers (HHO), and HTTP Meta Characters. For HMO, Cloudflare includes specific method override headers (X-HTTP-Method-Override, X-HTTP-Method, X-Method-Override) as part of customer cache keys to prevent cache poisoning. For HHO and HTTP Meta Characters, Cloudflare's default behavior of not caching HTTP status code 400 responses mitigates the attack vector. An exception is noted for unpatched Microsoft IIS versions that return 404 for oversized headers, recommending updates or removal of headerLimits. The post reiterates Cloudflare's commitment to industry standards and active defenses against caching pitfalls.
  110. Cloudflare Repositories FTWThis post details how Kali Linux integrated Cloudflare's CDN to serve its apt repository and large ISO images. For the apt repository, custom Nginx configurations were used to add `Cache-Tag` headers for metadata files and set `expires max` for package files. An API call was implemented to purge metadata files from the CDN cache after repository updates. For large file distribution, Cloudflare increased the maximum cacheable file size to accommodate Kali's ISO images, leading to a significant reduction in origin server load and bandwidth costs.
  111. NGINX structural enhancements for HTTP/2 performanceThis post details structural enhancements made to NGINX to improve HTTP/2 performance, specifically to increase the 'Potential' for prioritization algorithms. Key changes include: 1. HTTP/2 frame write queue reclamation: allowing unwritten frames from a partial write to be restored to per-stream queues for re-prioritization, rather than being held until the backlog clears. 2. HTTP/2 frame write event re-ordering: modifying the NGINX workflow to process frames from multiple upstream connections into per-stream queues before a single prioritization and write event, enabling frames from different streams to be in closer proximity for prioritization.
  112. Live video just got more live: Introducing Concurrent Streaming AccelerationIntroduced Concurrent Streaming Acceleration, a new technique to reduce live video latency by allowing multiple clients to read from a single file being pulled from origin simultaneously, bypassing the traditional CDN 'cache lock' that buffers entire segments before serving multiple viewers. This change was implemented across Cloudflare's infrastructure without requiring customer opt-in or configuration changes.
  113. Parallel streaming of progressive imagesIntroduced parallel streaming of progressive images by dynamically adjusting HTTP/2 priorities. This technique prioritizes image headers for layout stability, then image previews, and finally full image quality. It leverages existing browser and HTTP/2 capabilities to improve perceived image loading speed by up to 50% without additional data transfer or JavaScript. The implementation is format-independent but most beneficial for JPEG and JPEG 2000. A custom `cf-priority-change` header is supported for fine-grained control via Workers.
  114. Better HTTP/2 Prioritization for a Faster WebThis post introduces a new feature for HTTP/2 prioritization where Cloudflare servers take control of resource loading order, overriding browser defaults. This aims to optimize the delivery of critical resources like CSS, JavaScript, and images to reduce page load times, with observed improvements of up to 50%. The feature is available for paid plans and can be further customized using Cloudflare Workers.
  115. Announcing AMP Real URLIntroduced AMP Real URL, a feature that allows AMP pages served from caches (like Google's AMP Cache) to retain their original URL in the browser's address bar. This is achieved through cryptographic signing of the content provided to the AMP crawler, leveraging Web Packaging and browser support (initially Chrome on Android). This feature aims to improve brand protection, simplify analytics, increase screen space by removing the 'grey bar', potentially reduce bounce rates, and ensure content authenticity by cryptographically signing the content.
  116. Preventing Request Loops Using CDN-LoopThis post introduces the CDN-Loop header, a new IETF draft standard developed in collaboration with other CDN providers (Fastly, Akamai) to address request loop protection. It details the problem of request loops, the shortcomings of previous solutions like the Via header (performance degradation due to legacy usage and gzip issues), and the ad-hoc methods used previously (CF-Connecting-IP, X-Forwarded-For). The post explains the syntax and usage of the CDN-Loop header and Cloudflare's implementation of it at the edge, replacing previous methods and allowing for more granular control over loop detection and prevention.
  117. Better business results from faster web applications - Cloudflare is the fastestThis post highlights Cloudflare's performance advantages, particularly in CDN and DNS speed, citing Cedexis and DNSPerf benchmarks. It details how Argo Smart Routing, CDN, DNS, Load Balancing, and Web Optimizations contribute to faster web applications and improved business results (conversions, SEO, lead generation). It also provides case studies of customer performance gains.
  118. Introducing the Workers Cache API: Giving you control over how your content is cachedIntroduced the Workers Cache API, based on the Service Workers Cache API, providing `put()`, `match()`, and `delete()` methods for programmatic control over Cloudflare's global caches. This allows developers to modify requests and responses before caching, implement custom caching logic (e.g., TTL, cache tags, Vary logic), cache POST requests by transforming them into GET requests with a cache key derived from the body hash, and use the API as an ephemeral key-value store.
  119. Improving HTML Time to First ByteIntroduced a zero-config edge caching mechanism for HTML using HTTP headers (`x-HTML-Edge-Cache`). This allows origins to communicate caching rules (e.g., `cache`, `bypass-cookies`) and purge commands (`purgeall`) to Cloudflare's edge nodes without requiring explicit API integration or configuration. A companion Worker script and WordPress plugin demonstrate the implementation, leveraging Workers KV for global cache versioning and purging.
  120. Mejoramos el tiempo hasta el primer byte de HTMLIntroduced a zero-configuration HTML edge caching mechanism using custom HTTP headers (`x-HTML-Edge-Cache`) for cacheability signals and purge commands. This allows origins to communicate caching rules and invalidation requests to Cloudflare's edge without explicit API integration or configuration. Implemented a corresponding WordPress plugin and Cloudflare Worker script to demonstrate the protocol and enable edge caching for HTML content.
  121. Fast Google Fonts with Cloudflare WorkersThis post details the implementation of a Cloudflare Worker to optimize Google Fonts performance by embedding CSS and proxying font files. It demonstrates how to reduce round trips from 8 to 1 by serving fonts from the same domain as the HTML, leveraging Cloudflare's edge caching. The worker dynamically rewrites font URLs and processes HTML in streaming chunks, significantly improving page load times and visual rendering.
  122. Bandwidth Alliance Partners - Exciting ChoicesThis post details Cloudflare's approach to solution design for clients needing zero-egress storage options, focusing on a large client's needs for low-cost, high-read-volume storage compatible with the S3 API. It outlines a method for evaluating storage providers based on specific criteria (zero-egress, cost, read/write requests, volume, object size, API compatibility, security) and categorizing them as 'Checks all the boxes,' 'Soft no,' or 'Hard no.' The post highlights the importance of understanding client needs and partner differences to design effective solutions, particularly in the context of Cloudflare's Bandwidth Alliance.
  123. Improving RubyDocs with Cloudflare Workers and Workers KVThis post details the integration of Cloudflare Workers and Workers KV to improve the RubyDocs service. A Cloudflare Worker was implemented to proxy requests from a subpath (rubydocs.org/d/) to a subdomain (d3eo0xoa109f6x.cloudfront.net), allowing for a unified domain and leveraging CDN benefits. Workers KV was used to store and dynamically retrieve the latest version of Ruby projects, enabling URLs like rubydocs.org/d/ruby-latest/ to always point to the most recent documentation. The Worker script handles URL matching, redirection to the latest version, and appending trailing slashes for proper routing.
  124. Optimizing HTTP/2 prioritization with BBR and tcp_notsent_lowatThis post details the optimization of HTTP/2 prioritization by tuning the Linux kernel's networking stack. It recommends enabling BBR congestion control and setting tcp_notsent_lowat to 16KB to minimize TCP send buffer buffering, thereby enabling servers to respond more nimbly to priority shifts and deliver high-priority resources without delay from lower-priority buffered data. The post explains the interaction between browser prioritization schemes, HTTP/1.x and HTTP/2 request handling, and the impact of TCP send buffers and Bufferbloat.
  125. Mapping Factorio with LeafletThis post details the implementation of a multi-tier object storage strategy using Cloudflare Workers to serve Leaflet maps. It describes how Workers can be used to race requests against Google Cloud Storage (for higher-zoom levels) and Backblaze B2 (for lower-zoom levels), returning the fastest successful response. It also covers sending request stats to a third-party service (StatHat) to track which storage provider served requests and the effectiveness of Cloudflare caching. Finally, it explains how Cloudflare Argo is used to reduce latency for non-US/CA users accessing Backblaze B2 by routing their requests through an Argo-enabled domain.
  126. Introducing the Bandwidth Alliance: sharing the benefits of interconnected networksThis post introduces the Bandwidth Alliance, a new initiative aimed at reducing data transfer costs for mutual customers of Cloudflare and its partners. It details how the alliance leverages peered connections and smart routing to minimize incremental costs for data transfer between Cloudflare's network and participating cloud providers. The post highlights specific partnerships with Google Cloud and Microsoft Azure, detailing their CDN interconnect programs and discounted data transfer fees. It also announces founding members of the alliance and encourages other companies to join. While not directly a technical change to cache management, it represents a significant evolution in how Cloudflare delivers data to customers, impacting the overall cost and efficiency of content delivery.
  127. Cache API for Cloudflare Workers is now in Beta!Introduced the Cache API for Cloudflare Workers, allowing programmatic read and write access to the cache. This enables custom cache semantics, including caching worker output, caching POST requests, and setting Cache-Tag headers from within Workers.
  128. Using Edge-Side Includes with Workers for High AvailabilityThis post introduces the use of Cloudflare Workers to implement Edge Side Includes (ESI) for dynamic content assembly and graceful fallback mechanisms. The worker fetches the origin response, identifies fragments specified in 'X-Fragments' headers, and prefetches these fragments concurrently with a shared timeout. It then streams the origin response, replacing fragment placeholders with prefetched content or falling back to content within HTML comments if a fragment fails to load within the timeout. This enables partial rewrites and high availability during backend migrations.
  129. Refresh Stale DNS Records on 1.1.1.1Introduced a tool to purge individual DNS records from the 1.1.1.1 DNS resolver's cache. This allows domain owners to force an update of cached DNS entries, reducing the propagation delay from the default TTL (up to 3 hours) to a few seconds. The tool supports purging A, AAAA, CNAME, DNSKEY, DS, MX, NAPTR, NS, PTR, SPF, SRV, SSHFP, TLSA, and TXT record types.
  130. How Cloudflare protects customers from cache poisoningThis post details how Cloudflare protects customers from cache poisoning attacks by modifying its cache key strategy. Previously, cache keys primarily consisted of URL components. The vulnerability exploited origins reflecting data from HTTP headers not included in the cache key, allowing attackers to inject arbitrary data (e.g., JavaScript) into cached responses. Cloudflare's mitigation involves updating the cache key to include specific 'interesting' headers (X-Forwarded-Host, X-Host, X-Forwarded-Scheme) when their values differ from the Host or URL, thereby preventing the caching of poisoned responses. The post also mentions proactive customer notification and blocking of obviously malicious content via WAF.
  131. Edge-Side-Includes with Cloudflare WorkersThis post introduces the implementation of Edge-Side-Includes (ESI) using Cloudflare Workers. It demonstrates how Workers can be used to dynamically fetch and merge dynamic content fragments into static pages at the edge, improving performance for pages with dynamic elements. The solution involves intercepting text-based responses, identifying ESI include blocks, fetching the content of these blocks via sub-requests, and then merging the static and dynamic parts before sending the final response to the visitor. The worker script utilizes TransformStream for efficient streaming of the response body and includes logic for handling ESI blocks and their source URLs.
  132. Optimising Caching on Pwned Passwords (with Workers)This post details how Cloudflare's caching functionality was optimized for the Pwned Passwords API. It explains the use of custom cache key configurations to remove the 'Origin' header, which was causing duplicate caching due to varying origins. Additionally, it describes how Cloudflare Workers were used to standardize the casing of hash prefixes in API requests, preventing further cache duplication. The post also touches upon the role of Argo in providing tiered caching functionality.
  133. How we scaled nginx and saved the world 54 years every dayThis post details modifications to NGINX's event loop handling to improve disk I/O performance. Key contributions include: 1. Identifying that `read()` operations on disk files block the event loop, unlike network I/O. 2. Observing performance outliers in SSD read operations that significantly impact TTFB. 3. Enabling `SO_REUSEPORT` to improve the even distribution of requests across NGINX worker processes. 4. Modifying NGINX to perform `open()` operations within a thread pool, making it non-blocking and preventing event loop stalls. This combined approach resulted in a 6x improvement in peak p99 TTFB and an estimated saving of 54 years of wait time per day across the internet.
  134. Q2 FY 18 Product Releases, for a better Internet “end-to-end”This post announces the support for purge-by-tag for large tag sizes, allowing up to 1000 tags and a total header length of 16kb. This update simplifies file purges for customers who deploy websites with Drupal.
  135. Too Old To Rocket Load, Too Young To DieThis post details the re-engineering of Cloudflare's Rocket Loader product to improve page performance by controlling the load and execution of JavaScript. The new implementation focuses on executing blocking scripts after all other page assets have loaded, simulating the browser's loading process manually. It involves a server-side component that rewrites script tags with a nonce and inserts a client-side component. The client-side component performs two passes: first, collecting and re-inserting scripts as placeholders, and second, executing them based on their type (inline, external blocking, defer, async) to maintain intended order and avoid blocking page rendering.
  136. How we made our page-load optimisations even fasterThis post details the refactoring of Mirage and Rocket Loader's JavaScript to improve performance and browser compatibility. The original AMD-based loading mechanism was replaced with direct script inclusion and Rollup for bundling, eliminating the use of `document.write` and enabling better utilization of browser preload scanning. This resulted in smaller file sizes and faster page load times for users.
  137. Web Cache Deception Attack revisitedIntroduced 'Cache Deception Armor' Page Rule to automatically prevent Web Cache Deception attacks by verifying URL extension against Content-Type. This feature protects against attacks where dynamic scripts are cached as static assets due to URL extensions. The rule prevents caching when a mismatch is detected, with exceptions for content types like application/octet-stream and common cross-format mappings (e.g., jpg to webp). The protection relies on Origin Cache Control or Edge Cache TTL Page Rules.
  138. There’s Always Cache in the Banana StandThis post details the enhanced support for all HTTP Cache-Control response directives, including `public`, `max-age`, and `proxy-revalidate`. It explains how these directives allow origin servers to provide explicit instructions to Cloudflare's edge cache regarding content caching duration and revalidation behavior, thereby improving cache freshness and reliability.
  139. The Curious Case of Caching CSRF TokensThis post details the technical implementation of cookie-based caching bypass for dynamic content, specifically addressing issues with Magento's CSRF token handling and ensuring proper session cookie management when caching anonymous page views. It explains how Cloudflare's 'Bypass Cache on Cookie' functionality, combined with specific cookie configurations (e.g., `external_no_cache`, `PHPSESSID`, `adminhtml`), allows for static HTML caching of anonymous requests while directing dynamic requests (like adding items to a cart) to the origin server. The post also delves into debugging the interaction between Cloudflare's cache behavior (stripping server-set cookies) and Magento's requirement for a `frontend` cookie for cart functionality.
  140. A Fast, Secure Migration to Google Cloud Platform using CloudflareThis post details how Cloudflare's cache management and security features (WAF, SSL/TLS, Rate Limiting) can be used to optimize website performance and security during cloud migrations. It highlights the LUSH migration to GCP as a case study, showcasing bandwidth savings, reduced origin server requests, and threat mitigation. It also touches on SSL best practices and the termination of SSL sessions at Cloudflare.
  141. Introducing Argo — A faster, more reliable, more secure Internet for everyoneThis post introduces Argo, a "virtual backbone" for the modern Internet, which analyzes and optimizes routing decisions across the global Internet in real-time. It includes two core features: Smart Routing and Tiered Cache. Argo Smart Routing uses latency and packet loss data collected from each request that traverses Cloudflare's network to pick optimal paths across the Internet. Argo Tiered Cache uses the size of Cloudflare's network to reduce requests to customer origins by dramatically increasing cache hit ratios. It achieves this by first asking other Cloudflare PoPs if they have the requested content when a cache miss occurs, resulting in improved performance and reduced origin load. Customers enabling Argo can expect to see a 60% reduction in their cache miss rate as compared to Cloudflare's traditional CDN service. Argo also concentrates connections to origin servers, leading to fewer open connections and potential savings on cloud hosting bills.
  142. Ecommerce websites on Cloudflare: best practicesThis post details best practices for leveraging Cloudflare's caching capabilities for e-commerce websites. It explains how to use Page Rules to cache static content and dynamic content, including strategies for bypassing the cache for logged-in users or items in their shopping baskets. It also introduces the use of AJAX for populating dynamic elements and discusses the benefits of Railgun for accelerating non-cacheable dynamic content.
  143. Understanding Our Cache and the Web Cache Deception AttackThis post details the Web Cache Deception attack, explaining how misconfigurations in websites behind reverse proxies can lead to sensitive content being cached and exposed. It then describes Cloudflare's two-phase cache processing: eligibility (based on request characteristics like file extensions and cookie settings) and disqualification (based on response characteristics like Cache-Control and Expires headers, and Set-Cookie headers). It also lists specific file extensions that are always or sometimes cacheable.
  144. Introducing Accelerated Mobile Links: Making the Mobile Web App-QuickThis post introduces Cloudflare's Accelerated Mobile Links feature, which automatically identifies links to AMP content on a customer's site. When clicked from a mobile device, it loads the AMP content nearly instantly. This feature aims to make the mobile web as fast as native apps, regardless of how the content is discovered. It also allows for customization of the viewer domain for large publishers and contributes to the open-source AMP project by providing a non-Google AMP cache.
  145. Caching Anonymous Page ViewsIntroduced a new Page Rule option, "Bypass Cache on Cookie", for Business plan customers. This feature, when used with "Cache Everything", allows for caching of HTML for anonymous page views while bypassing the cache for requests containing specific cookies, thus serving dynamic content only to logged-in users or those with personalized carts. The setting supports wildcard and OR operators, and allows customization of Edge Cache TTL. Cache purging via web interface, API, and platform integrations is also supported.
  146. How we brought HTTPS Everywhere to the cloud (part 1)This post details the implementation of Automatic HTTPS Rewrites, a server-side solution to address mixed content issues by rewriting HTTP sub-resource links to HTTPS. It explains the limitations of naive approaches and browser extensions, and describes the use of Ragel to compile HTTPS Everywhere rulesets into a high-performance C state machine for efficient processing at the Cloudflare edge. The post also discusses optimizations for handling domain wildcards, particularly left-side wildcards, by reversing rules for more efficient state machine generation.
  147. Fixing the mixed content problem with Automatic HTTPS RewritesIntroduced Automatic HTTPS Rewrites to automatically upgrade HTTP subresources to HTTPS, addressing the mixed content problem and enabling full HTTPS adoption for websites. This feature parses HTML in real-time to modify links, providing a one-click solution for websites struggling to transition their legacy content to HTTPS.
  148. Accelerating Node.js applications with HTTP/2 Server PushIntroduced netjet, a Node.js middleware that parses HTML to automatically add HTTP/2 Server Push Link headers, improving performance for Node.js applications. Implemented an adjustable LRU cache keyed by ETag headers to speed up subsequent parses. Provided examples for integrating netjet with Express and plain Node.js http servers. Detailed how to verify Server Push using Chrome Developer Tools and the `cf-h2-pushed` header.
  149. HTTP/2 Server Push with multiple assets per Link headerThis post details the enhancement of Cloudflare's HTTP/2 Server Push implementation to support multiple assets per Link header, addressing a previous restriction. It introduces the `Cf-H2-Pushed` header for debugging pushed assets and confirms the live deployment of this feature, which proactively delivers critical resources like CSS, images, and scripts to the browser, improving initial page load times.
  150. Secure and fast GitHub Pages with CloudFlareThis post details the integration of Cloudflare's CDN and Universal SSL with GitHub Pages for static site hosting. It explains how to configure DNS records to point to GitHub Pages, use a CNAME file for custom domains, and leverage Cloudflare's 'Cache Everything' Page Rule to cache HTML directly from the CDN. It also covers enabling Universal SSL to provide HTTPS for custom domains, thereby enabling HTTP/2, and setting up Page Rules for enforcing HTTPS and redirecting non-www to www.
  151. Announcing Support for HTTP/2 Server PushThis post announces the general availability of HTTP/2 Server Push for all Cloudflare customers. It explains the mechanism of Server Push using `PUSH_PROMISE` and `RST_STREAM` frames, and how to enable it via `Link` headers with `rel=preload`. It also details how to disable it with `nopush` and discusses best use cases and profiling methods in various browsers. The post highlights that Server Push is most effective for uncacheable content, all assets on a requested page (if not client-cached), and predicting the next likely page.
  152. Today Is A Big Day For Page RulesThis post introduces API support for Page Rules, enabling programmatic management of rules for deployment integration and cross-domain synchronization. It also adds 13 new settings to Page Rules, significantly expanding their configurability. A 'pause' functionality is introduced for Page Rules, allowing temporary deactivation for debugging without losing configuration. The Page Rules management interface has been redesigned to be mobile-friendly and responsive.
  153. What's inside net/http? Late binding in the Go standard libraryThis post delves into the internal workings of Go's `net/http` client, specifically its connection pooling and 'late binding' mechanism. It highlights how the client races to either establish a new connection or retrieve an idle one from a pool, aiming to minimize roundtrip latency. This concept of 'late binding' is directly compared to a similar mechanism used in Cloudflare's Railgun, demonstrating a shared engineering principle for optimizing connection management and performance across different systems.
  154. HTTP/2 Demo: Under the HoodThis post details the technical implementation of an HTTP/2 demo page. It explains how iframes were used to load content from an HTTP/1.1-only CDN (Amazon CloudFront) and Cloudflare's HTTP/2-enabled CDN side-by-side. The iframe content was generated using JavaScript to sequentially request 200 image tiles, created with ImageMagick, to illustrate multiplexing benefits. Cross-domain security rules were addressed using `Window.postMessage`. Caching policies were configured to cache everything edge-side but store nothing in the browser cache to ensure accurate demo results. The post also touches on SPDY fallback for older browsers.
  155. HTTP/2 For Web DevelopersThis post details how HTTP/2's multiplexing and header compression change web optimization best practices. It advises against concatenating files, inlining assets, and sharding domains, instead recommending granular resources and optimized caching. It also reiterates the importance of reducing DNS lookups, using CDNs, leveraging browser caching, minimizing request/response sizes, and eliminating unnecessary redirects.
  156. Results of experimenting with Brotli for dynamic web contentThis post introduces Brotli as a potential replacement for gzip, detailing its compression algorithms (LZ77 and Huffman coding) and comparing its performance characteristics to gzip. It highlights Brotli's larger sliding window, smaller minimal match length, and larger maximal match length compared to gzip, as well as its static dictionary feature. The post includes experimental results showing Brotli achieving better compression ratios than gzip at comparable or slightly higher CPU costs.
  157. Simple Helix chooses CloudFlare to ignite white-hot Magento performanceThis post details how Simple Helix, a Cloudflare partner, integrated Cloudflare's CDN and Railgun to improve performance and security for their Magento hosting customers. They observed significant speed increases (up to 143% with Railgun) and bandwidth savings (up to 70% reduction at origin during high-traffic events). The post also highlights the security benefits of Cloudflare's WAF in mitigating threats like bots and DDoS attacks.
  158. Railgun v5 has landed: better, faster, lighterRailgun v5 introduces significant improvements including reduced memory utilization and CPU requirements, a new lighter-weight binary wire protocol, an extra layer of traditional non-delta compression for increased compression ratios (10-15%), streaming mode for large downloads to reduce download times, better utilization of origin web server connections via connection pooling and HTTP keep-alives, and improved cryptographic infrastructure with a new CA and bidirectional TLS certificate verification. It also offers subdomain assignment for partners and is now available on RHEL and CentOS 7.
  159. Introducing a Powerful Way to Purge Cache on CloudFlare: Purge by Cache-TagIntroduced Cache-Tags as a new method for cache purging. Cache-Tags are assigned via a Cache-Tag response header and stored as metadata with cached objects. Purges are performed using the Cloudflare dashboard or API. This feature is enabled for Enterprise plan websites.
  160. Increasing Cache Hit Rates with Query String SortIntroduced Query String Sort, an Enterprise-level feature that sorts query string arguments in a URL into a deterministic order before caching. This ensures that URLs with the same parameters but different orders are treated as identical, thereby increasing cache hit rates. The feature is particularly beneficial for API servers where query string argument order may not be significant but can lead to cache misses by default. The post explains the problem of query string permutations and how Query String Sort solves it.
  161. Google PageSpeed Service customers: migrate to CloudFlare for accelerationThis post announces the discontinuation of Google's hosted PageSpeed Service and invites its customers to migrate to Cloudflare for acceleration. It highlights Cloudflare's performance features (minification, image compression, asynchronous loading, global network, Railgun, SPDY) as comparable or superior to PageSpeed Service, and also emphasizes Cloudflare's additional offerings in security, SSL, DNS, and its free tier. It provides instructions for migration.
  162. Improving compression with a preset DEFLATE dictionaryThis post details the exploration and experimental application of preset DEFLATE dictionaries to improve compression ratios across all HTML pages served by Cloudflare. It explains the DEFLATE algorithm's LZ77 stage and how a preset dictionary can act as an initial back-reference for common strings, improving compression efficiency. An experiment is described where over 20,000 HTML pages were scanned to create 16KB and 32KB dictionaries, which were then benchmarked against a set of 19,000 HTML files. The results showed that using a 16KB dictionary improved compression by approximately 25% compared to DEFLATE alone.
  163. Welcome 1&1 Internet, CloudFlare’s Newest Optimized Partner!This post announces a partnership with 1&1 Internet, a large hosting provider. Through this partnership, 1&1 customers will gain access to Cloudflare's Railgun technology. Railgun is a caching technology that accelerates dynamic content by caching static portions, previously only available to higher-tier plans. The partnership enables Railgun to be offered to a wider audience by aggregating multiple customers behind a single hosting partner's infrastructure, solving the technical challenge of individual installations.
  164. Using CloudFlare to mix domain sharding and SPDYThis post analyzes the interaction between domain sharding and the SPDY protocol. It demonstrates that while domain sharding improves performance for older HTTP/1.1 connections by increasing the number of parallel connections, it can negatively impact SPDY performance by forcing additional SSL negotiations and separate SPDY connections. The post proposes a solution using a single certificate covering multiple subdomains to allow SPDY to multiplex requests from different domains over a single connection, achieving the benefits of both domain sharding and SPDY.
  165. Railgun Gives our Ecommerce Sites the EdgeThis post introduces Railgun, a technology that uses delta compression to reduce outbound bandwidth from origin servers to Cloudflare data centers. It demonstrates significant reductions in outbound bandwidth consumption (from a 5x-10x inbound:outbound ratio to 1:1 during peak traffic) and improvements in HTML document retrieval times (up to 2x from London). The post highlights Railgun's effectiveness for e-commerce sites with similar URIs and its international expansion benefits.
  166. Mirage 2.0: Solving the Mobile Browsing Speed ChallengeMirage 2.0 introduces image virtualization by storing a full-resolution and a reduced-size virtual image with dimension metadata. A Virtualized Image Packager (VIP) downloads virtualized images, places them correctly sized in the DOM, and progressively replaces them with full-resolution versions. It minimizes requests by streaming all images in a single request, similar to Rocket Loader. The VIP prioritizes loading based on viewport visibility and dynamically adapts its aggressiveness based on browser capabilities and connection speeds, gathering real-time browsing intelligence.
  167. Page Rules Reordering Now AvailableIntroduced the ability to reorder Page Rules by dragging and dropping them in the dashboard. This allows users to control the order of rule application, which is critical for scenarios where specific rules (e.g., excluding caching for admin pages) need to take precedence over more general rules (e.g., aggressive caching for all pages). Previously, reordering required deleting and re-adding rules.
  168. Cloudflare Keeps TheBayLights.org Running BrightThis post details the application of Cloudflare's 'Cache Everything' feature to the TheBayLights.org website to handle a significant traffic surge during its unveiling. It highlights how enabling full HTML page caching from Cloudflare's global network reduced the load on the customer's webserver and database, leading to decreased resource utilization despite increased traffic. The post also mentions basic optimizations like minification and the importance of allowing Cloudflare IPs.
  169. CloudFlare's Railgun: Easier Than EverThis post announces the broader availability and ease of adoption for Cloudflare's Railgun technology. It details self-installation options (RPMs for various Linux/BSD, and an upcoming AMI for AWS) and highlights partnerships with over 30 leading hosting providers who will offer Railgun integration, often with a single click. This significantly expands the reach and accessibility of Railgun for dynamic content optimization.
  170. Edge Cache Expire TTL: Easiest way to override any existing headersIntroduced 'Edge cache expire TTL' as a new feature within Page Rules. This setting allows users to explicitly define the Time-To-Live (TTL) for cached resources on Cloudflare's edge servers, overriding any existing cache-related headers (e.g., Cache-Control, Expires) originating from the origin server. This provides greater control over edge caching duration, especially useful during traffic surges, DDoS attacks, or when origin server headers are uncertain or undesirable. The feature is tiered by plan, offering different TTL durations.
  171. Railgun in the real world: faster web page load timesThis post details real-world performance tests of Cloudflare's Railgun technology, a delta compression technique for accelerating dynamic content delivery. It presents median improvements in HTML delivery speed (1.43x), compression ratio (0.65%), Time To First Byte (90% of non-Railgun value), and overall page load time (89% of non-Railgun time) across 51 Vexxhost websites. The analysis includes comparisons with estimations and highlights the impact of Railgun on pages with large initial HTML payloads and geographically distant users.
  172. CDNJS: The Fastest Javascript Repo on the WebThis post details the partnership with CDNJS, a project that aims to make Javascript resources load as fast as possible. Cloudflare is now serving CDNJS resources from its global network. Data shows CDNJS is 50% faster than Google's Javascript CDN and over four times as fast as Microsoft's CDN. CDNJS is also expanding to include CSS and Images.
  173. Efficiently compressing dynamically generated web contentThis post introduces the concept of using external dictionaries for compression, specifically for dynamically generated web content. It highlights the limitations of generic compression like gzip and proposes solutions like SDCH (Shared Dictionary Compression over HTTP) and ESI (Edge Side Includes) to achieve higher compression ratios by referencing common content blocks stored in a shared dictionary. The post details how SDCH works with VCDIFF and discusses the challenges of dictionary generation and management, while ESI offers an alternative by including unchanging parts of a page as separate mini-pages. This contributes to the evolution of cache management by exploring methods to reduce the size of dynamic content, thereby mitigating latency.
  174. Do you want to work with Go?This post highlights the adoption of the Go programming language for critical production systems at Cloudflare, including its use in the Railgun web optimizer. It signifies a strategic choice for high-performance, concurrent software development, directly contributing to the underlying technology that powers advanced caching and optimization features.
  175. Always Online v.2Introduced Always Online v.2, which actively crawls customer pages to build a more robust cache. This addresses the previous limitation where static pages were less likely to be cached due to reliance on search engine crawler traffic. The new crawler has a specific user agent and its crawl frequency varies by plan. Future iterations will allow users to pin and exclude pages from the cache.
  176. Introducing: Single File Cache PurgeIntroduced single file purge capability for Cloudflare's cache, allowing users to purge individual URLs without affecting other cached files. This feature is available to all users and via API, with the goal of enabling automated systems to update Cloudflare's network when files are updated on origin servers.
  177. Go at CloudFlareThis post details the technical implementation of Cloudflare's Railgun software, specifically highlighting the choice and benefits of using the Go programming language. It explains how Go's concurrency primitives (goroutines and channels) and its object-oriented features (interfaces) were instrumental in building a performant and scalable solution for caching dynamic content. The post also emphasizes the ease of distribution due to Go's single executable output and the richness of its standard library.
  178. Making Edge Side Includes (ESI) Automatic and EasyThis post introduces Railgun as a next-generation solution for caching dynamic HTML content. Unlike traditional Edge Side Includes (ESI) which require manual tagging and significant development effort, Railgun automatically identifies and caches static portions of HTML at the edge. Dynamic portions are fetched from the origin without requiring code modifications. This approach aims to deliver significant performance increases by reducing the amount of dynamic content transmitted over the network, without introducing process lock-in.
  179. Caching the uncacheable: CloudFlare's RailgunIntroduced Railgun, a premium service for Business and Enterprise customers, designed to optimize the delivery of dynamically generated or personalized web pages that are typically uncacheable. Railgun works by establishing a permanent, TLS-secured TCP connection between a sender component in Cloudflare data centers and a listener component installed at the customer's network. This connection uses a binary multiplexing protocol to run multiple HTTP requests asynchronously. By recognizing that dynamic pages change slowly, Railgun compresses differences between page versions, achieving significantly higher compression ratios than standard gzip. This effectively makes almost all web content cacheable for premium customers.
  180. The bandwidth of a Boeing 747 and its impact on web browsingThis post introduces the concepts of bandwidth and latency, explaining how TCP's reliability mechanisms (acknowledgements, receive window) interact with latency to limit effective transfer speeds. It uses the analogy of a Boeing 747's bandwidth vs. a 100 Mbps internet connection to illustrate the impact of latency. The post then positions Cloudflare's distributed network as a solution to reduce latency by bringing content closer to users.
  181. Introducing Mirage: Automatic Responsive Web Design via Intelligent Image LoadingIntroduced Mirage, a system that automatically manages image loading for responsive web design. Mirage prioritizes loading images within the viewport, lazy-loads others as needed, and dynamically resizes images to match the device's viewport and resolution. This reduces bandwidth waste and improves performance, particularly for mobile users. Mirage is available to paid customers and works via JavaScript with a fallback for disabled JavaScript.
  182. Introducing Polish: Automatic Image OptimizationIntroduced Polish, an automatic image optimization feature that reduces image file sizes by removing unnecessary bloat (lossless mode) and applying compression algorithms (lossy mode). Lossless mode offers an average file size reduction of 21%, while lossy mode achieves an average reduction of 48%. Polish is available for paid accounts and operates by optimizing images in the cache upon fetching from the origin.
  183. Moog Music: Staying online when Google doodles youThis post details how Cloudflare's Page Rules and advanced caching capabilities were used to handle a massive traffic surge for MoogMusic.com due to a Google doodle. By configuring Page Rules to 'Cache Everything' for static portions of the site, Cloudflare was able to serve approximately 92% of requests directly from its edge infrastructure, significantly reducing the load on the origin VPS and reducing bandwidth by over 90%. This demonstrates the effectiveness of edge caching for handling unpredictable traffic spikes.
  184. CloudFlare —WebOps for everyoneThis post introduces Cloudflare's core services: Security (DDoS protection, SSL, scrape protection), Metrics (accurate, non-JS-based analytics), Acceleration (caching, content optimization, bandwidth reduction), Reach (Anycast network, global distribution, uptime even if origin is down, IPv6 enablement), and Transformation (automatic page modification for analytics, email obfuscation, hotlink protection, responsive design, minification). It highlights the 'WebOps-as-a-service' model, making advanced capabilities accessible to all website owners.
  185. Introducing Page Rules: Advanced Caching (Including Configurable HTML Caching)Introduced Page Rules, a new feature that allows users to define custom caching behavior on a per-page basis. This includes the 'Cache Everything' option, which enables caching of HTML content by matching specific URL patterns. The post details how to differentiate static vs. dynamic content using URL patterns (e.g., subdirectories, file extensions, query parameters) and how to configure Page Rules to cache matching content. It also mentions limitations related to cache resources and the ability to purge the cache. Additionally, Page Rules can override default cache settings for query parameters.
  186. Introducing Page Rules: URL ForwardingThis post introduces the capability to perform URL forwarding using Cloudflare Page Rules. It details how to configure Page Rules to match specific URL patterns and forward requests to new URLs using 302 redirects. It explains basic forwarding with direct URL entry and advanced forwarding using wildcard variables ($1, $2, etc.) to preserve parts of the original URL. Troubleshooting tips for ensuring subdomains are enabled and rule precedence are also provided.
  187. Introducing Page Rules: Fine Grained Control over CloudFlare's FeaturesIntroduced Page Rules, a new feature allowing granular control over Cloudflare's features (including caching and apps) on a per-page basis using pattern matching with wildcards. This enables users to disable features like Cloudflare Apps or performance optimizations on specific administrative pages while keeping them enabled for public-facing content. Page Rules are compiled into machine code and pushed to the edge within seconds. Free accounts get 3 rules per domain, Pro accounts get 20.
  188. What Is CloudFlare?This post introduces Cloudflare's core caching capabilities as a feature within its broader offering, distinguishing it from traditional CDNs. It highlights the ability to cache static content at the edge and its function as a caching reverse proxy that handles all requests to a website, enabling features beyond simple content delivery.
  189. CloudFlare Uses Intelligent Caching to Avoid the Bot Performance TaxThis post details the evolution of caching strategies to address the performance impact of automated bots, specifically search engine crawlers. It introduces the concept of differentiating caching TTLs for human visitors versus bots, using Project Honey Pot as an example. The post explains how Project Honey Pot initially used caching layers to store frequently accessed pages and how malicious bots caused performance degradation by triggering uncached dynamic content. The solution involved restricting known malicious bots and applying longer TTLs for search engine crawlers. Cloudflare's current approach is described as more intelligent and dynamic, automatically tuning search crawler TTLs and effectively handling bot traffic to offload requests from web applications.
  190. Tales From The Pumpkin PatchThis post details the experience of The Pumpkin Lady, a seasonal e-commerce site, using Cloudflare during their peak traffic period. It quantifies the benefits of Cloudflare's caching and request reduction, reporting a saving of 1.54 Terabytes of bandwidth and 136,604,571 requests over 30 days. This allowed the customer to stay on shared hosting, saving on server expenses and avoiding downtime.
  191. Stayin' AliveThis post introduces the implementation of end-to-end Keep Alives, a new optimization that maintains persistent TCP connections between Cloudflare's network and origin servers. This reduces latency by minimizing TCP overhead for each requested resource and lessens the load on origin servers. The change is expected to improve overall site snappiness by approximately 10% for sites whose origin servers support Keep Alive connections.
  192. Combining Javascript & CSS, a Better WayIntroduced Rocket Loader, a new feature that addresses the performance bottleneck of numerous HTTP requests for JavaScript and CSS files. Rocket Loader streams individual files through a single HTTP connection, preserving file atomicity and cacheability while reducing the number of requests. It offers manual and automatic modes for enabling the feature, with options for script exclusion.
  193. We Saved Users Half a Petabyte Last Month!This post highlights the significant bandwidth savings achieved by Cloudflare's caching mechanisms, saving users over half a petabyte of data transfer in the last 30 days. It quantifies the value in terms of reduced bandwidth fees and server load, stating an average saving of 60% bandwidth and 65% requests. The post also mentions ongoing refinement of caching algorithms.
  194. Avoid Losing SEO Link Juice to Traditional CDNsThis post introduces a method for CDNs to avoid rewriting static resource URLs to a third-party domain, thereby preserving SEO credit for the original domain. Cloudflare's approach ensures that static content served from its network continues to be associated with the customer's domain, unlike traditional CDNs that require URL rewriting. This preserves the SEO value of backlinks pointing to static assets.
  195. Is Your Site Able To Handle A 'Bieber Effect' Moment?This post introduces the concept of the 'Bieber Effect' moment, where a celebrity tweet can cause massive traffic spikes that overwhelm origin servers. It highlights Cloudflare's CDN as a solution to handle such spikes by caching static content like photos, thereby reducing the load on origin servers and improving website performance. The post emphasizes the speed and security benefits of Cloudflare's service.
  196. CloudFlare's Free CDN and YouThis post introduces Cloudflare's free CDN offering, explaining its benefits for faster page loading times and reduced bounce rates. It details that Cloudflare automatically caches static content based on file extensions (JavaScript, CSS, images) with zero configuration required. It also outlines how users can integrate Cloudflare with existing CDNs or WordPress caching plugins, and explains the use of Development Mode and cache purging for updating static content. The post touches on the business model enabling the free CDN.
  197. An All New (and Improved) AutoMinifyIntroduced a new, in-line minification process for CSS, Javascript, and HTML that operates directly within the response stream, eliminating the need for caching before minification. This process is designed to be significantly faster (100x) than previous methods and overcomes challenges with dynamic content and large-scale processing across multiple data centers. The previous approach involved caching resources, minifying them, and then replacing the cached version, which was inefficient for dynamic content and did not scale well.
  198. CDNJS: Community Moderated Javascript Libraries + CloudFlareThis post details the migration of CDNJS, a community-moderated JavaScript library repository, to Cloudflare's global network. The migration addressed prohibitive costs associated with Amazon's CloudFront service and enabled SSL/HTTPS support, which was previously a limitation. Cloudflare's network provided significantly lower latency and improved caching capabilities, benefiting all users of CDNJS libraries. Latency improvements of approximately 1/3rd were observed compared to the previous setup, with CDNJS powered by Cloudflare showing an average latency of 14ms compared to 82ms for Google Libraries API.
  199. How CloudFlare Rocket Loader Redefines the Modern CDNIntroduced Rocket Loader, a new feature that addresses script blocking and asynchronous loading. Rocket Loader ensures scripts do not block page rendering, loads them asynchronously, bundles script requests into a single stream, and uses LocalStorage for intelligent caching. It aims to provide SPDY-like performance benefits across most browsers and smartphones by modifying HTML on the fly.
  200. Zone Apex / Naked Domain / Root Domain CNAME Support for Amazon EC2, Google App Engine and Other Cloud HostsThis post introduces CNAME Flattening, a feature that overcomes DNS RFC limitations to allow zone apex domains (naked domains) to be CNAME records. This directly benefits users of cloud hosting providers like AWS EC2, Google App Engine, and Rackspace, enabling them to point their root domains to these services without requiring workarounds, thereby improving flexibility and performance.
  201. News From CloudFlare Labs: Javascript Preloader ResearchThis post details research into Web Content Optimization (WCO) and introduces innovative techniques for preloading Javascript without execution. This work aims to further enhance web performance, especially on mobile devices, and will be deployed to all Cloudflare users.
  202. CloudFlare Keeps Groundhog Day Online!This post details how Cloudflare's Always Online feature kept the groundhog.org website online during a traffic spike on Groundhog Day. The feature served cached content when the origin server crashed, preventing downtime and reducing server load. The site also experienced a 40% speed improvement due to Cloudflare's global network.
  203. Website Performance MattersThis post introduces Cloudflare's core caching mechanism as a reverse proxy distributed globally. It explains how caching resources like images at edge nodes closer to visitors reduces latency and offloads the origin server. The system automatically caches resources without manual configuration, leading to an average of 30% faster website loading times. It also addresses dynamic websites by ensuring only static assets are cached, keeping dynamic content fresh while still offloading larger static assets like images, CSS, and JavaScript.
  204. CloudFlare Guest Blog Post: Liew Cheon FongThis post details a user's experience with Cloudflare's CDN capabilities for their personal blog. The user describes how Cloudflare mitigated malicious traffic, reduced server load, and improved page load times. They also mention upgrading to the Pro account for advanced security and caching features, noting specific improvements in page load speed (73% faster) and bandwidth cost savings (38%). The user highlights the ease of setup and the benefits of Cloudflare's CDN functionality for website performance.
  205. Always Online: Because Downtime SucksIntroduced the 'Always Online' feature, which leverages cached copies of a website to maintain accessibility during origin server downtime. This feature ensures basic content remains available and search engines continue indexing, mitigating the impact of outages on site availability and sales.
  206. CloudFlare Guest Blog Post: Steven Nims of Streamline ConsultingThis post details the benefits of Cloudflare's caching and security features for small businesses. It highlights how Cloudflare blocked nearly 9,000 bad requests from over 1600 unique threats, saved 10.3 days of visitor browsing time, reduced bandwidth usage by 29.9 GB, and decreased average page load time from 2.03 seconds to 1.2 seconds (a 40% improvement). It also mentions the ease of integration via DNS changes and the utility of the development mode for seeing immediate changes to cachable content.
  207. Introducing the Cloudflare Cache Purge FeatureIntroduced the 'Cache Purge' feature, allowing users to immediately purge all cached resources for their website. This feature addresses the need to update static files (CSS, Javascript, images) without waiting for cache expiration. It is available at the domain level and does not support purging specific file extensions. The post also contrasts this with 'Development Mode', recommending the latter for frequent development changes.