Recently, we made an optimization to the Cloudflare Workers runtime which reduces the amount of time Workers need to spend in memory. We're passing the savings on to you for all your Unbound Workers.

Workers are often used to implement HTTP proxies, where JavaScript is used to rewrite an HTTP request before sending it on to an origin server, and then to rewrite the response before sending it back to the client. You can implement any kind of rewrite in a Worker, including both rewriting headers and bodies.

Many Workers, though, do not actually modify the response body, but instead simply allow the bytes to pass through from the origin to the client. In this case, the Worker's application code has finished executing as soon as the response headers are sent, before the body bytes have passed through. Historically, the Worker was nevertheless considered to be "in use" until the response body had fully finished streaming.

For billing purposes, under the Workers Unbound pricing model, we charge duration-memory (gigabyte-seconds) for the time in which the Worker is in use.

On December 15-16, we made a change to the way we handle requests that are streaming through the response without modifying the content. This change means that we can mark application code as “idle” as soon as the response headers are returned.

Since no further application code will execute on behalf of the request, the system does not need to keep the request state in memory – it only needs to track the low-level native sockets and pump the bytes through. So now, during this time, the Worker will be considered idle, and could even be evicted before the stream completes (though this would be unlikely unless the stream lasts for a very long time).

Visualized it looks something like this:

As a result of this change, we've seen that the time a Worker is considered "in use" by any particular request has dropped by an average of 70%. Of course, this number varies a lot depending on the details of each Worker. Some may see no benefit, others may see an even larger benefit.

This change is totally invisible to the application. To any external observer, everything behaves as it did before. But, since the system now considers a Worker to be idle during response streaming, the response streaming time will no longer be billed. So, if you saw a drop in your bill, this is why!

The change also applies to a few other frequently used scenarios, namely Websocket proxying, reading from the cache and streaming from KV.

WebSockets: once a Worker has arranged to proxy through a WebSocket, as long as it isn't handling individual messages in your Worker code, the Worker does not remain in use during the proxying. The change applies to regular stateless Workers, but not to Durable Objects, which are not usually used for proxying.

export default {
  async fetch(request: Request) {
    //Do anything before
    const upgradeHeader = request.headers.get('Upgrade')
    if (upgradeHeader || upgradeHeader === 'websocket') {
      return await fetch(request)
    }
    //Or with other requests
  }
}

Reading from Cache: If you return the response from a cache.match call, the Worker is considered idle as soon as the response headers are returned.

export default {
  async fetch(request: Request) {
    let response = await caches.default.match('https://example.com')
    if (response) {
      return response
    }
    // get/create response and put into cache
  }
}

Streaming from KV: And lastly, when you stream from KV. This one is a bit trickier to get right, because often people retrieve the value from KV as a string, or JSON object and then create a response with that value. But if you fetch the value as a stream, as done in the example below, you can create a Response with the ReadableStream.

interface Env {
  MY_KV_NAME: KVNamespace
}

export default {
  async fetch(request: Request, env: Env) {
    const readableStream = await env.MY_KV_NAME.get('hello_world.pdf', { type: 'stream' })
    if (readableStream) {
      return new Response(readableStream, { headers: { 'content-type': 'application/pdf' } })
    }
  },
}

If you are already using Unbound, your bill will have automatically dropped already.

Now is a great time to check out Unbound if you haven’t already, especially since recently, we’ve also removed the egress fees. Unbound allows you to build more complex workloads on our platform and only pay for what you use.

We are always looking for opportunities to make Workers better. Often that improvement takes the form of powerful new features such as the soon-to-be released Service Bindings and, of course, performance enhancements. This time, we are delighted to make Cloudflare Workers even cheaper than they already were.

Our mission is to enable developers to build their applications, end to end, on our platform, and ruthlessly eliminate limitations that may get in the way. Today, we're excited to announce you can build large, data-intensive applications on our network, all without breaking the bank; starting today, we're dropping egress fees to zero.

Building more on any platform historically comes with a caveat — high data transfer cost. These costs often come in the form of egress fees. Especially in the case of data intensive workloads, egress data transfer costs can come at a high premium, depending on the provider.

What exactly are data egress fees? They are the costs of retrieving data from a cloud provider. Cloud infrastructure providers generally pay for bandwidth based on capacity, but often bill customers based on the amount of data transferred. Curious to learn more about what this means for end users? We recently wrote an analysis of AWS’ Egregious Egress — a good read if you would like to learn more about the ‘Hotel California’ model AWS has spun up. Effectively, data egress fees lock you into their platform, making you choose your provider based not on which provider has the best infrastructure for your use case, but instead choosing the provider where your data resides.

At Cloudflare, we’re working to flip the script for our customers. Our recently announced R2 Storage waives the data egress fees other providers implement for similar products. Cloudflare is a founding member of the Bandwidth Alliance, aiming to help our mutual customers overcome these data transfer fees.

We’re keeping true to our mission and, effective immediately, dropping all Egress Data Transfer fees associated with Workers Unbound and Durable Objects. If you’re using Workers Unbound today, your next bill will no longer include Egress Data Transfer fees. If you’re not using Unbound yet, now is a great time to experiment. With Workers Unbound, get access to longer CPU time limits and pay only for what you use, and don’t worry about the data transfer cost. When paired with Bandwidth Alliance partners, this is a cost-effective solution for any data intensive workloads.

This week has been about defining what the future of computing is going to look like. Workers are great for your latency sensitive workloads, with zero-milliseconds cold start times, fast global deployment, and the power of Cloudflare’s network. But Workers are not limited to lightweight tasks — we want you to run your heavy workloads on our platform as well. That’s why we’re announcing you can now use up to 15 minutes of CPU time on your Workers! You can run your most compute-intensive tasks on Workers using Cron Triggers. To get started, head to the Settings tab in your Worker and select the ‘Unbound’ usage model.

Once you’ve confirmed your Usage Model is Unbound, switch to the Triggers tab and click Add Cron Trigger. You’ll see a ‘Maximum Duration’ is listed, indicating whether your schedule is eligible for 15 Minute workloads.

That’s not all. As a platform, it is validating to see our customers want to grow even more with us, and we’ve been working to address these restrictions. That’s why, starting today, all customers will be allowed to deploy up to 100 Worker scripts. With the introduction of Services, that represents up to 100 environments per account. This higher limit will allow our customers to migrate more use cases to the Workers platform.

We’re also delighted to announce that, alongside this increase, the Workers platform will plan to support scripts larger in size. This increase will allow developers to build Workers with more libraries and new possibilities, like running Golang with WASM. Check out an example of esbuild running on a Worker, in a script that’s just over 2MB compressed. If you’re interested in larger script sizes, sign up here.

The future of cloud computing is here, and it’s on Cloudflare. Workers has always been the secure, fast serverless offering, and has recently been named a leader in the space. Now, it is even more affordable and flexible too.

We can’t wait to see what ambitious projects our customers build. Developers are now better positioned than ever to deploy large and complex applications on Cloudflare. Excited to build using Workers, or get engaged with the community? Join our Discord server to keep up with the latest on Cloudflare Workers.

In this blog post we’re going to look at how you can optimize the page experience of your AMP pages by running AMP Optimizer in a Cloudflare Worker.

A great user experience on the web means more than just having a website that loads fast (although that continues to be a critical part of the user experience). There are many factors that contributing to a great experience, such as:

• Loading speed

• Responsiveness

• Content stability

Traditionally, these have been hard to measure, but with Core Web Vitals we now have a new way to measure user experience on the web. The key is: Core Web Vitals are based on real world user data. To score well on Core Web Vitals you need to make sure that your website performs well - for all your users around the world.

Image URL

This becomes even more important soon, as Core Web Vitals are also going to be a signal in the upcoming page experience ranking update in Google Search. You can find more details in the page experience FAQ.

AMP is an open source web components framework that has been developed with page experience in mind. AMP ensures a good page experience by providing guardrails that help avoid common performance pitfalls. For example, AMP features a static layout system, which avoids content shifts by design.

However, AMP pages can still fail Core Web Vitals. The reason for this is clear: some performance best practices required for performing well on Core Web Vitals can’t be implemented at client-side. For example, image optimization, fast server-response times and effective font-loading are all critical for a good user experience, but need to be done on the server. Even AMP documents themselves can be further optimized. For example, AMP’s layout system can be pre-rendered at build or serving time which greatly improves page load times while still ensuring that there are no content jumps.

The good news is, if an AMP page is surfaced in Google Search or Bing, it’ll be served from an AMP Cache which performs all these optimizations for you. But when someone visits your AMP page directly, for example through a link shared on social media, they won’t get the same experience. In order to ensure that you are getting great Core Web Vitals scores for all your users, it is very important to optimize your AMP pages on your origin as well!

To help with this, the AMP team has created AMP Optimizers, which will automatically perform common performance best practices for you. Using AMP Optimizers combined with Cloudflare Workers makes it super easy to serve optimized AMP pages on your own origin.

We are happy to announce a new AMP Optimizer integration for Cloudflare Workers. So far, there are two AMP Optimizer versions available: one for NodeJS and one for PHP. Both take an AMP HTML document as input and turn it into an optimized AMP HTML document. Depending on when your pages are created, one of these needs to be run either as part of your build system or in on your backend as part of your rendering pipeline. However, integrating an AMP Optimizer is not always straightforward, for example if you’re not using PHP or NodeJS in your backend or when you don’t control the hosting environment.

With the Cloudflare Worker integration for AMP Optimizer you can seamlessly optimize all your AMP pages. You can find installation instructions on the Github repository.

Let’s dive into how the Cloudflare Worker works, so that we can get a better understanding of where it optimises things.

Whenever a request comes in for an HTML file (1), the Worker will first check in the global cache if an optimised version has already been generated (2). If that is not the case (3), the Worker will request the version of the file from your origin (4)(5), optimize the document if it is using AMP (6), and return that to the user (7). Only after the response has been fully streamed to the user will we start saving the generated version in the cache (8).

For subsequent requests, in a Worker anywhere else in the world, the result will be retrieved from the global KV cache, cached locally in that data center and returned straight away.

Because the AMP Optimizer parses the HTML document, it will discover what other resources are used, and will add preload tags for external resources such as fonts and hero images.

Images are often the biggest contributors to the total download size of a web page. Customers on the Business or Enterprise plans can automatically make use of the Cloudflare Image Optimization functionality. For those customers, the AMP Optimizer can automatically generate image source sets with links for the Cloudflare Image Optimizer.

Image sourcesets give the browser different options to pick the most appropriate image size for that particular browser viewport. This can greatly reduce the size of the image downloads for, say, a low end mobile phone, which needs much smaller images than a 4K desktop monitor.

While most of the requests will be handled very quickly, even the ones that need optimising, the optimisation of large files can take more than 50ms of CPU time. Which is why Workers Unbound is a perfect match for the AMP Optimizer Worker.

Workers Unbound allows Workers to execute for up to 30 seconds, so that even if it does take a bit longer than 50ms to optimize a document, your users will never see any errors.

Web performance is much more complex than any synthetic test can prove, so you should absolutely do your own performance testing on your own sites. But here is an example of a regular AMP page with and without the Cloudflare Worker AMP Optimizer in front of it. This is tested on a simulated Moto G4 on a fast 3G network.

Here is the full WegPageTest data if you want to explore this example further.

There is also an example benchmark script you can adapt if you want to run performance tests on your own site.

Cloudflare Workers offer a simple way to prepare your AMP pages for Google’s upcoming page experience launch. They offer a seamless integration that doesn’t require any changes in your CMS or server. Even better — with the new Cloudflare Workers Unbound, it becomes possible to perform even more advanced optimizations. Check out the cloudflare-amp-optimizer repository for more details on how to get started.

Since the Workers Unbound beta announcement last year, we’ve been hard at work tuning our systems to prepare for the public launch for Workers Unbound. We’ve seen enormous demand from developers, customers, and the Cloudflare community at large. We’ve been inspired to see our users develop a wide range of use cases, from enterprise features to entirely new applications and unlock creativity with personal projects.

Workers Unbound is intended for applications that need long execution times. Today, we are making our extended CPU limits of up to 30 seconds for HTTP requests generally available to customers on the Workers Paid plan. Please note that you will still be able to access Bundled Workers, which are capped at 50 milliseconds, by toggling your Workers at a per script level.

In addition, we are offering a private beta for Cron Triggers of up to 15 minutes for those who need even longer execution times. HTTP Workers are triggered by HTTP requests as part of the Fetch API, whereas Cron Workers are scheduled jobs invoked by Cron Triggers. Our aim with this release is to allow customers to bring all of their intensive workloads to Workers and access the benefits of our edge network, without having to worry about computation limits.

The feedback has been fantastic and we’re excited to see that our work to extend compute limits to unlock new use cases is resonating with our community (please join our Discord server here)!  We want Workers Unbound to be the choice that developers turn to for any workload that might otherwise be run on traditional serverless platforms like AWS Lambda  — and we’re thrilled to see that the message is resonating.

Workers Unbound aims to be the cheapest general purpose computing platform, and we’ve made changes to our pricing plan to solidify that position. As announced during the beta, the Workers Unbound pricing model includes charges for duration and egress as well as requests, but we will not include any additional charges as other providers do, such as API Gateway or CloudFront.

Over the course of development, we also heard your feedback on the cost of egress. We know that these costs are top of mind for developers who need to do intensive storage and transfer operations. In response to that, we have cut our egress in half from \$0.09 per GB to \$0.045 per GB.

Furthermore, we increased the usage that is included in our $5 a month cost, detailed below. Now, as a part of the Workers Paid plan, we will give you more usage for the same rate.

We know that cost can be a major pain point for other serverless providers, and we want to make sure that developers using Workers Unbound can spend more time building applications with cutting edge technologies and less time worrying about their bill. You can read more about our pricing in these docs.

Back in 2017, when we launched the Workers platform, we opted to tackle the lower latency use cases first. This approach helped us serve our existing customers, who wanted to modify Cloudflare products they were already using, like WAF and who usually required little time to execute. We retained the ability to adjust the CPU time limit in special cases. Sometimes we did this for customers with specific needs, and often those customers were our own teams at Cloudflare building on Workers. As these requests became more and more frequent, we began to see the real-world practicality of offering higher compute limits to the general market. Our beta program has helped validate this hypothesis.

We’ve seen some of our early access Unbound testers use the platform for more complex compute use cases like genomic analysis. Dr. Robert Aboukhalil, a software engineer and bioinformatics specialist, used Workers Unbound to build an API that simulates DNA sequencing data, requesting subsets of a reference genome and streaming it back to the user. To power those simulations, he compiled wgsim, an open source genomics tool for simulating sequence reads from a reference genome, from C to WebAssembly using biowasm. Next, he used the human genome referenced hosted on the public repo of the 1,000 Genomes Project as a starting point to apply random modifications to simulate errors introduced during the experiment. You can read more about his explorations in this blog.

In Dr. Aboukhalil’s own words: "Cloudflare Workers Unbound and KV are well-suited for complex workloads such as powering genomics analysis. For example, I was able to build an API that simulates DNA sequencing data. Workers was well suited as it features 0 ms initialization time (i.e. no “cold starts”), runs at the edge (i.e. in a data center close to your users), and has a pricing model that doesn’t require a degree in quantum physics to understand."

We’ve also seen that Workers Unbound can be a critical part of scaling applications at large enterprise companies. Thomson Reuters used Workers Unbound to build EverCache, a cache implementation designed to improve efficiency and load times across thousands of their partner websites.

According to Randy Kleinhuizen, an architect at Thomson Reuters, "We use Cloudflare Workers Unbound and Workers KV to reduce the burden on our origin servers and pre-populate our cache. We are early users of Unbound's long running Workers, and the simple integration with Workers KV has made it easy to use, with consistent performance and reliability."

Furthermore, our testers have taught us that Workers Unbound is a powerful environment for sandboxing and experimentation. Customers who originally used our platform for more simple use cases are able to expand by testing out ideas, prototyping and building out optimizations with Unbound.

As we heard from Kenn North, principal product manager at National Instruments, "Workers has been our go-to tool for scaling and tuning ni.com. We first started using Workers for redirects, and then began using Workers Unbound once we realized it could be a powerful tool for other features such as detecting the location of users and adjusting the experience accordingly. We started experimenting with using includes for deploying common header and footer HTML across the site, and currently we are improving routing, image optimization, and page caching. Our development team loves having the ability to experiment with building new features on top of Workers."

Starting today, Workers Unbound is available to anyone with a Cloudflare Workers Paid subscription. Navigate to the Workers dashboard, click "Change" under the Default Usage Model section, and follow the prompts to enable Unbound on your account. You can also change the Usage Model for individual Workers under the Settings tab of each Worker.

Once enabled, Unbound can also be used through wrangler, the command-line tool for deploying Workers. First, make sure to update wrangler to release 1.15.1 or later. Then, configure the usage model of your Worker by setting the usage_model field in your wrangler.toml to either "bundled" or "unbound".

As a reminder, the “bundled” usage model gives you access to our original Workers model with up to 50ms of compute time. The model “unbound” opts you into the higher execution limits with the pricing listed above. If you don't specify a usage model, new Workers scripts will use the default usage model set through the dashboard.

If you want to try Workers Unbound today, please take a look at this template, licensed under the MIT license, and give it a whirl!

// Try running this script first with Usage Model: Bundled
// see how far it can count.
//
// Then update the script's Usage Model to Unbound to see
// how much further it can go!
//
// note: 1st requests on a connection in Bundled mode
// might get higher cpu allocation than average requests.
 
addEventListener('fetch', event => {
 event.respondWith(handleEvent(event))
})
 
async function handleEvent(event) {
 let { readable, writable } = new TransformStream()
 let countingIsDone = countToOneTrillion(writable)
 event.waitUntil(countingIsDone)
 
 // start streaming response while still counting
 return new Response(readable, {
   status: 200,
   headers: {
     'Content-Type': 'text/plain; charset=utf8',
     'X-Content-Type-Options': 'nosniff',
   },
 })
}
 
async function countToOneTrillion(writableStream) {
 // This is an example of a cpu-heavy long running task.
 //
 // Try your own example here instead!
 // Fractal Generator? ML model training?
 
 const million = 1000000
 const intro = `Hello World!
Let's count to one trillion:
(we'll stop when cpu limits are exceeded)
 
`
 const writer = writableStream.getWriter()
 const encoder = new TextEncoder()
 await writer.write(encoder.encode(intro))
 
 for (let i = 1; i <= million * million; i++) {
   if (i % (2 * million) == 0) {
     // send an update to client every 2M cycles
     const count = i / million
     const line = `${count} million\n`
     await writer.write(encoder.encode(line))
   }
 }
 await writer.close()
 return
}

We hope you give Workers Unbound a try - and if you have any feedback or questions please let us know on our Discord server here! If you are interested in signing up for the beta program for 15 minute Cron Workers, please contact us with this form.