Two months ago we launched Cloudflare Images for everyone, and we are amazed about the adoption and the feedback we received.

Let’s start with some numbers:

More than 70 million images delivered per day on average in the week of November 5 to 12.

More than 1.5 million images have been uploaded so far, growing faster every day.

But we are just getting started and are happy to announce the release of the most requested features, first we talk about the AVIF support for Images, converting as many images as possible with AVIF results in highly compressed, fast delivered images without compromising on the quality.

Secondly we introduce blur. By blurring an image, in combination with the already supported protection of private images via signed URL, we make Cloudflare Images a great solution for previews for paid content.

For many of our customers it is important to be able to serve Images from their own domain and not only via imagedelivery.net. Here we show an easy solution for this using a custom Worker or a special URL.

Last but not least we announce the launch of new attractively priced bundles for both Cloudflare Images and Stream.

We announced support for the new AVIF image format in Image Resizing product last year.

Last month we added AVIF support in Cloudflare Images. It compresses images significantly better than older-generation formats such as WebP and JPEG. Today, AVIF image format is supported both in Chrome and Firefox. Globally, almost 70% of users have a web browser that supports AVIF.

As we explained previously, AVIF is a combination of the HEIF ISO standard, and a royalty-free AV1 codec by Mozilla, Xiph, Google, Cisco, and many others.

“Currently, JPEG is the most popular image format on the web. It's doing remarkably well for its age, and it will likely remain popular for years to come thanks to its excellent compatibility. There have been many previous attempts at replacing JPEG, such as JPEG 2000, JPEG XR, and WebP. However, these formats offered only modest compression improvements and didn't always beat JPEG on image quality. Compression and image quality in AVIF is better than in all of them, and by a wide margin.”¹

As a reminder, image delivery is done through the Cloudflare managed imagedelivery.net domain. It is powered by Cloudflare Workers. We have the following logic to request the AVIF format based on the Accept HTTP request header:

const WEBP_ACCEPT_HEADER = /image\/webp/i;
const AVIF_ACCEPT_HEADER = /image\/avif/i;

addEventListener("fetch", (event) => {
  event.respondWith(handleRequest(event));
});

async function handleRequest(event) {
  const request = event.request;
  const url = new URL(request.url);
  
  const headers = new Headers(request.headers);

  const accept = headers.get("accept");

  let format = undefined;

  if (WEBP_ACCEPT_HEADER.test(accept)) {
    format = "webp";
  }

  if (AVIF_ACCEPT_HEADER.test(accept)) {
    format = "avif";
  }

  const resizingReq = new Request(url, {
    headers,
    cf: {
      image: { ..., format },
    },
  });

  return fetch(resizingReq);
}

Based on the Accept header, the logic in the Worker detects if WebP or AVIF format can be served. The request is passed to Image Resizing. If the image is available in the Cloudflare cache it will be served immediately, otherwise the image will be resized, transformed, and cached. This approach ensures that for clients without AVIF format support we deliver images in WebP or JPEG formats.

The benefit of Cloudflare Images product is that we added AVIF support without a need for customers to change a single line of code from their side.

The transformation of an image to AVIF is compute-intensive but leads to a significant benefit in file-size. We are always weighing the cost and benefits in the decision which format to serve.

It Is worth noting that all the conversions to WebP and AVIF formats happen on the request phase for image delivery at the moment. We will be adding the ability to convert images on the upload phase in the future.

One of the most requested features for Images and Image Resizing was adding support for blur. We recently added the support for blur both via URL format and with Cloudflare Workers.

Cloudflare Images uses variants. When you create a variant, you can define properties including variant name, width, height, and whether the variant should be publicly accessible. Blur will be available as a new option for variants via variant API:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/9a7806061c88ada191ed06f989cc3dac/images/v1/variants" \
     -H "Authorization: Bearer <api_token>" \
     -H "Content-Type: application/json" \
     --data '{"id":"blur","options":{"metadata":"none","blur":20},"neverRequireSignedURLs":true}'

One of the use cases for using blur with Cloudflare Images is to control access to the premium content.

The customer will upload the image that requires an access token:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/9a7806061c88ada191ed06f989cc3dac/images/v1" \
     -H "Authorization: Bearer <api_token>"
     --form 'file=@./<file_name>' \
     --form 'requireSignedURLs=true'

Using the variant we defined via API we can fetch the image without providing a signature:

To access the protected image a valid signed URL will be required:

The combination of image blurring and restricted access to images could be integrated into many scenarios and provides a powerful tool set for content publishers.

The functionality to define a variant with a blur option is coming soon in the Cloudflare dashboard.

One important use case for Cloudflare Images customers is to serve images from custom domains. It could improve latency and loading performance by not requiring additional TLS negotiations on the client. Using Cloudflare Workers customers can add this functionality today using the following example:

const IMAGE_DELIVERY_HOST = "https://imagedelivery.net";

addEventListener("fetch", async (event) => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const url = new URL(request.url);
  const { pathname, search } = url;

  const destinationURL = IMAGE_DELIVERY_HOST + pathname + search;
  return fetch(new Request(destinationURL));
}

For simplicity, the Workers script makes the redirect from the domain where it’s deployed to the imagedelivery.net. We assume the same format as for Cloudflare Images URLs:

https://<customdomain.net>/<encoded account id>/<image id>/<variant name>

The Worker could be adjusted to fit customer needs like:

• Serving images from a specific domains' path e.g. /images/

• Populate account id or variant name automatically

• Map Cloudflare Images to custom URLs altogether

For customers who just want the simplicity of serving Cloudflare Images from their domains on Cloudflare we will be adding the ability to serve Cloudflare Images using the following format:

https://<customdomain.net>/cdn-cgi/imagedelivery/<encrypted_account_id>/<_image_id>/<variant_name>

Image delivery will be supported from all customer domains under the same Cloudflare account where Cloudflare Images subscription is activated. This will be available to all Cloudflare Images customers before the holidays.

Creator platforms, eCommerce, and many other products have one thing in common: having an easy and accessible way to upload, store and deliver your images and videos in the best and most affordable way is vital.

We teamed up with the Stream team to create a set of bundles that make it super easy to get started with your product.

The Starter bundle is perfect for experimenting and a first MVP. For just $10 per month it is 50% cheaper than the unbundled option, and includes enough to get started:

• Stream: 1,000 stored minutes and 5,000 minutes served

• Images: 100,000 stored images and 500,000 images served

For larger and fast scaling applications we have the Creator Bundle for $50 per month which saves over 60% compared to the unbundled products. It includes everything to start scaling:

• Stream: 10,000 stored minutes and 50,000 minutes served

• Images: 500,000 stored images and 1,000,000 images served

These new bundles will be available to all customers from the end of November.

We are not stopping here, and we already have the next features for Images lined up. One of them is Images Analytics. Having great analytics for a product is vital, and so we will be introducing analytics functionality for Cloudflare Images for all customers to be able to keep track of all images and their usage.

¹http://blog.cloudflare.com/generate-avif-images-with-image-resizing/#what-is-avif

We’re excited to announce that, starting today, Cloudflare customers will be able to generate Signed Exchanges (SXG) for Google Search with just one click. Signed Exchanges is an open web platform specification Google developed as a way of verifying a cached version of a website — enabling massively faster delivery of a website from a third party, such as Google itself from its search results page, or from a news aggregator that is linking out to other sites.

The advantage to you as a website owner? Not only will your site load faster when linked to from a site supporting SXG, but because many search engines use page load times in order to determine search results, you should see a very nice boost in SEO.

Introduced by Google, a Signed Exchange (SXG) is an open standard delivery mechanism that makes it possible to authenticate the origin of a resource, independent of how it was delivered. This decoupling advances a variety of use cases, such as prefetching, offline Internet experiences, and serving from third-party caches. It does so in a secure and privacy-preserving manner.

Now, imagine yourself as the ruler of your kingdom with an important message to deliver to all your subjects. You have too many people to reach, so you can’t do it alone. You decide to enlist your trusty knights to ride out with large chests filled with copies of your message. There are villains everywhere that would love to take these messages and modify them for their own nefarious machinations for their own profit.

You, being the wise ruler you are, have a crafty plan: you have a very special stamp made that can imprint a seal that everyone can recognize, yet no one can recreate. With this wondrous seal, no one can tamper with the messages without breaking the seal and proving the forgery for all to see. Now, your knights can bring these chests to all corners of the kingdom and hand out the messages to the masses, and your subjects can trust that the message came from you. There is a side benefit for your people, too. They can come whenever they want to pick up the message without your watchful eye, so they’re more inclined to read it at their leisure.

Maybe this is stretching the analogy a bit, but in the case of Signed Exchanges, a cryptographic signature on a digest of the response and headers acts as the tamper proof seal for the message. Fast forwarding our example to the present day: you want to get your newest web experience out to global distribution with the understanding that just about everyone will come through a search engine or aggregator site. Ahead of time, when you publish your content, the search engine crawls your site for content, but instead of delivering the raw content, you negotiate the delivery of the signed exchange. (This is accomplished simply through additional “Accept: application/signed-exchange;v=” request headers from the crawler that announces the preference for signed exchanges).

Then Cloudflare generates the Signed Exchange, using the following process:

1. Cloudflare fetches the original content that you want to sign, including the response headers.

2. An additional Digest header is added that uses Merkle Integrity Content Encoding to support the progressive detection of data modification/corruption.

3. We also strip out headers that don’t make sense within the context of Signed Exchanges (like Connection, Keep-Alive, etc.) as well as security sensitive headers (Set-Cookie, Authentication-Info, etc.).

4. Then these headers, including the digest, along with additional metadata, like request URL, URL of the certificate, hash of the certificate, expiration time, etc., are all chained together into a stream that is used to calculate the final signature.

5. The original content, along with the headers, signature, and a fallback URL are then packed into a final binary for delivery.

This Signed Exchange is then cached and sent to the crawler, which also stores the Signed Exchange. After indexing the content, it can now show up in searches. The user then discovers the link to your content in the search results. The search engine also preloads the signed exchange for your content in the background in the meantime, effectively pre-filling the cache in the client’s browser. This exchange was delivered from the search engine, so no signal has gone to the origin yet. Thus, the search intent of the user isn’t leaked to the origin. Since the exchange is signed and validated against your certificate, the browser trusts the contents and can display the content with attribution to the original URL. Now, when the user clicks on the link to view the contents, it magically loads instantaneously from the local cache.

There are many resources on the web available that go into detail about the specific format of Signed Exchanges, so we won’t rehash them here in detail. But one important aspect that isn’t obvious at first glance is the complexity of managing the signing process itself. The many details involve:

• The inclusion of the atypical CanSignHttpExchanges extension to your certificate.

• The requirement to deliver your certificates in a specific CBOR (like binary JSON) format.

• OCSP stapling to ensure the validity of the certificates is required.

• Renewals of these certificates on a more frequent basis (i.e. requires automation).

• Caching of the generated signed exchanges, since they can be expensive to generate.

Luckily, all of these are in Cloudflare’s wheelhouse, since we already have deep expertise in Certificate Management and TLS delivery infrastructure. By partnering with Google on the Signed Exchange implementation, we can ensure the consistency of implementation, but improve the simplicity of integrating the technology with the single push of a button.

“Signed Exchanges make the web faster and a better user experience for users, by enabling cross-site prefetching. Site owners have seen clear improvement to Largest Contentful Paint, one of the Core Web Vitals, as well as increased user stickiness. Cloudflare now makes it simple for sites to implement Signed Exchanges and derive these benefits.” — Jeff Jose, Product Manager, Google

The broader implication of SXGs is that they make content portable: content delivered via an SXG can be easily distributed by third parties while maintaining full assurance and attribution of its origin. Historically, the only way for a site to use a third party to distribute its content while maintaining attribution has been for the site to share its SSL certificates with the distributor. This has security drawbacks. Moreover, it is a far stretch from making content truly portable.

In the long-term, truly portable content can be used to achieve use cases like fully offline experiences. In the immediate term, the primary use case of SXGs is the delivery of faster user experiences by providing content in an easily cacheable format. Specifically, Google Search will cache and sometimes prefetch SXGs. For sites that receive a large portion of their traffic from Google Search, SXGs can be an important tool for delivering faster page loads to users.

It’s also possible that all sites could eventually support this standard. Every time a site is loaded, all the linked articles could be pre-loaded. Web speeds across the board would be dramatically increased. Matthew’s blog post talks more about this possibility.

Automatic Signed Exchanges will be free for all Cloudflare Pro, Business and Enterprise customers as well as for customers using our Advanced Platform Optimization product.

Sign up for the Automatic Signed Exchange beta waitlist today and after being approved, activating is only one flip of a switch.

To sign up for the waitlist go to the Speed page on the Cloudflare dashboard and click on “Join Waitlist” on the Automatic Signed Exchanges (SXGs) card.

We’ll take care of the rest.

Today, we are announcing the beta of Cloudflare Images: a simple service to store, resize, optimize, and deliver images at scale.

In 2018, we launched Stream to provide a single product that could be used to store, encode, and deliver videos. With Cloudflare Images, we are doing for images what Stream did for videos. Just like Stream, Cloudflare Images eliminates the need to think about storage buckets, egress costs, and many other common problems that are solved for you out of the box. Whether you are building an ecommerce platform with millions of high-res product pictures and videos or a new app for creators, you can build your entire media pipeline by combining Cloudflare Images and Stream.

Any time you are building infrastructure for image storage and processing, there are four fundamental questions you must answer:

1. “Where do we store images?”

2. “How do we secure, resize, and optimize the images for different use cases?”

3. “How do we serve the images to our users reliably?”

4. “How do we do all of these things at scale while having predictable and affordable pricing, especially during spikes?”

Cloudflare Images has a straightforward set of APIs and simple pricing structure that answers all of these pesky questions. We built Images so your team can spend less energy maintaining infrastructure and more time focusing on what makes your product truly special.

We talked to many Cloudflare customers who are using Cloudflare to serve millions of images every day. We heard two recurring themes. First, customers wished there was a simpler way for them to securely store, resize, and serve the images. Their current infrastructure generally involves using product A for storage, product B for resizing, and product C for the actual delivery. Combining these products together (often from multiple vendors) quickly becomes messy with multiple points of failure. Moreover, maintaining this infrastructure requires ongoing monitoring and tweaks.

Second, we heard that customers often end up with an ever-growing egress bill due to multiple vendors and products. It blew our minds that the egress bill can be a multiple of the storage cost itself. Every time your pictures move from product A (storage provider) to product B (resizing service) to product C (the CDN), you generally pay an egress cost which can quickly add up depending on the number of pictures and their variants. Multiplied by tens of millions of images and variants, this cost can add up to tens of thousands of dollars per month.

Each time you upload an image to Cloudflare Images, you receive an :image_id. There are no buckets and folders to manage the originals and the variants. And because of Images built-in support for resizing and delivery, there is no egress cost. If you have internal metadata that you’d like to associate with a picture, you can set the meta field for every upload to any arbitrary JSON value.

When talking to customers we saw two main patterns of how customers would like to deliver images:

1. Upload an image and get an :image_uid back that allows future operations on the image. In this case, the image URL would be https://imagedelivery.net/small-thumbnail/:image_uid

2. Upload images with the filename as their main identifier, e.g. filename reflects SKU.In this case, it is up to you to make sure there are no duplicate filenames, as they would be rejected.

Here the image URL would be https://imagedelivery.net/small-thumbnail/:account_hash/:filename

Cloudflare Images supports Variants. When you create a variant, you can define properties including variant name, width, height, and whether the variant should be publicly accessible. You can then associate an image with one or more variants using the UI or the API.

Let’s say you are storing user profile pictures. You could define a variant called “profile-thumbnail” and configure that variant to serve images of a fixed width and height. Once you have a variant, you can associate the profile pictures with the profile-thumbnail variant. Whenever you need to display a profile picture in your app, you simply call https://imagedelivery.net/profile-thumbnail/:image_uid or https://imagedelivery.net/profile-thumbnail/:account_hash/:filename.

Variants also offer access control. You might only want logged-in users to view the larger version of the profile pictures. You could create another variant called large-profile-picture and make it require a signed URL token. When a user tries to access the large profile picture with a URL such as https://imagedelivery.net/large-profile-picture/:image_uid, the request will fail because there is no valid token provided.

An indirect upside of using variants is that your organization has a single source of truth for the different ways you are using images across your apps. Different teams can create variants for their use cases, enabling you to audit the security and optimization settings for different types of pictures from one central place. We learned that as our customers' products grow in complexity, separate teams may be responsible for handling various aspects of the product. For example, one team may be responsible for user profile pictures and the different variants associated with it. Another team may be responsible for creator uploads and maintaining different variations that are available to the public and to paid members. Over time, organizations can lose track of this logic with no single source of truth. With variants, this logic is clearly laid out and can serve as the source of truth for all the ways you are securing and optimizing different types of image uploads in your product.

There is no additional cost for using variants. Every picture uploaded to Images can be associated with up to five variants. You will be able to associate an image with a variant using the UI or the API.

Cloudflare Images automatically serves the most optimized version of the image. You no longer need to worry about things like file extensions. When a client requests a picture hosted on Cloudflare Images, we automatically identify the ideal supported format at the Cloudflare edge and serve it to the client from the edge. For example, 93.55% of all users use a web browser that supports webp. For those users, Images would automatically serve webp images. To the remaining users, Images would serve PNGs (and in very rare cases where neither webp or PNGs are supported, it would serve JPGs). In future, we plan to automatically support AVIF for highly-requested images.

When you use Images, you no longer need to worry about cache hit rates, image file types, configuring origins for your image assets.

To use Cloudflare Images, you will pay a fixed monthly fee for every 100,000 images stored in Cloudflare Images (up to 10MB per image). And at the end of each month, you pay for the number of images served. There are no additional costs for resizing, egress, or optimized routing.

If you want to be part of Cloudflare Images beta, request an invite. We will start inviting a limited set of users to try out Cloudflare Images in the coming weeks. Pricing and developer docs for Images will be posted at the time we start sending invites.

We can’t wait to see what you build using Cloudflare Images!

Last December we opened up our brand new privacy-first Web Analytics platform to everyone. Today, we’re excited to announce the release of three of the most requested features: adding multiple websites to an account, supporting Single-page Applications (SPA) as well as showing Core Web Vitals in Web Analytics.

Since we launched two months ago, we’ve received a lot of feedback from our users. We are really happy that we are able to provide our privacy-first analytics to so many of you.

Popular analytics vendors have business models driven by ad revenue. Using them implies a bargain: they track visitor behavior and create buyer profiles to retarget your visitors with ads; in exchange, you get free analytics.

Our mission is to help build a better Internet, and part of that is to deliver essential web analytics to everyone with a website without compromising user privacy. We’ve never been interested in tracking users or selling advertising. We don’t want to know what you do on the Internet — it’s not our business.

When we launched Web Analytics, each account was only able to measure one website. We are happy to announce that all users can now add up to 10 websites.

Add one or more new sites via the Cloudflare Dashboard by selecting "Add site" in Quick Actions.

For measuring multiple subdomains (a.example.com and b.example.com) there are two options:

1. Add the root domain (example.com) to Web Analytics and add the same JavaScript snippet on all subdomains (a.example.com and b.example.com)

2. Add the subdomains separately using multiple sites. Here you have to add separate snippets.

We use the hostname to validate the request, so remember that you can only use the JavaScript snippet if both the configured and actual hostnames match.

When we talked to customers about the multiple site feature, we got the feedback that it is very important to add all sites to Web Analytics and be able to track them. But they also said that it would be even more powerful to have the option to see analytics for all your sites combined in one place.

We listened. If you select "View Web Analytics for all sites’ on the Web Analytics overview page, you can now see all your sites listed and apply filters to them using site tags.

With frameworks such as Angular, React, or Vue.js being very popular, one of the most requested features for Web Analytics was supporting single-page applications (SPA).

SPAs work differently from a standard web application or website because they don't load a new page every time there's user interaction. Instead, they dynamically rewrite the current web page with new data retrieved from the web server.

Since we've previously collected metrics only when the page load event is triggered, we had to change the transmission and interpretation of the signals from our JavaScript snippet to include sending metrics whenever there are any route changes made by the application or the website.

We are happy to announce that we successfully implemented SPA support and enabled it for all customers.

You might have noticed that some websites keep the # in the URL whenever you navigate their webpages. You would see URLs like the following:

https://cloudflare.com/#blog
https://cloudflare.com/#marketing

The portion separated by the # is called a fragment, and based on the fragment changes, SPAs dynamically pull the resources to rewrite the webpage. That is how it was done before the HTML 5 History API was introduced and widely used. These days most SPA libraries/frameworks use HTML 5 History API to keep your UI in sync with the URL instead of using # (although, some still support #-based routers). In most cases you won’t easily notice a SPA by looking at the URL path.

To support analytics for SPAs, we implemented sending additional payloads to the beacon endpoint, which collects the data for analytics, whenever we detect any changes to the state of the History API. The JavaScript snippet overrides the pushState method and listens to the onpopstate event. By tracking the History API's state, you'll now see the route changes in SPAs within the Web Analytics dashboard.

Some older SPA libraries/frameworks still support hash-based routers. If your application or website is using a hash-based router, unfortunately it is not yet supported in Web Analytics. However, this is our initial launch to support SPAs, so stay tuned for any improvements and updates.

SPA support is automatically enabled for all domains in Web Analytics.

Core Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.

In September 2020, we introduced Web Vitals for customers using Browser Insights, and many customers love getting those unique insights into their website performance. But we were also aware that Browser Insights wasn't available to all our Web Analytics customers simply because they're not able to onboard to the rest of Cloudflare for Infrastructure. Specifically, they're not able to change their DNS servers.

So today, we're introducing Core Web Vitals to Web Analytics as well.

You can see the Core Web Vitals metrics in the same dashboard as Visits and Page Views and check how healthy your website performance is.

This is just the start for our privacy-first Web Analytics.

We’re excited to integrate more closely with the rest of Cloudflare and give customers even more detailed stats about performance and security (not just traffic). We’re also hoping to make our analytics even more powerful as a standalone product by building support for alerts, real-time updates, and more.

Please let us know if you have any questions or feedback, and happy measuring!

Unlike the tides, Internet use ebbs and flows with the motion of the sun not the moon. Across the world usage quietens during the night and picks up as morning comes. Internet use also follows patterns that humans create, dipping down when people stopped to applaud healthcare workers fighting COVID-19, or pausing to watch their country’s president address them, or slowing for religious reasons.

And while humans leave a mark on the Internet, so do automated systems. These systems might be doing useful work (like building search engine databases) or harm (like scraping content, or attacking an Internet property).

All the while Internet use (and attacks) is growing. Zoom into any day and you’ll see the familiar daily wave of Internet use reflecting day and night, zoom out and you’ll likely spot weekends when Internet use often slows down a little, zoom out further and you might spot the occasional change in use caused by a holiday, zoom out further and you’ll see that Internet use grows inexorably.

And attacks don’t only grow, they change. New techniques are invented while old ones remain evergreen. DDoS activity continues day and night roaming from one victim to another. Automated scanning tools look for vulnerabilities in anything, literally anything, connected to the Internet.

Sometimes the Internet fails in a country, perhaps because of a cable cut somewhere beneath the sea, or because of government intervention. That too is something we track and measure.

All this activity, good and bad, shows up in the trends and details that Cloudflare tracks to help improve our service and protect our customers. Until today this insight was only available internally at Cloudflare, today we are launching a new service, Cloudflare Radar, that shines a light on the Internet’s patterns.

Each second, Cloudflare handles on average 18 million HTTP requests and 6 million DNS requests. With 1 billion unique IP addresses connecting to Cloudflare’s network we have one of the most representative views on Internet traffic worldwide.

And by blocking 72 billion cyberthreats every day Cloudflare also has a unique position in understanding and mitigating Internet threats.

Our goal is to help build a better Internet and we want to do this by exposing insights, threats and trends based on the aggregated data that we have. We want to help anyone understand what is happening on the Internet from a security, performance and usage perspective. Every Internet user should have easy access to answer the questions that they have.

There are three key components that we’re launching today: Radar Internet Insights, Radar Domain Insights and Radar IP Insights.

At the top of Cloudflare Radar we show the latest news about events that are currently happening on the Internet. This includes news about the adoption of new technologies, browsers or operating systems. We are also keeping all users up to date with interesting events around developments in Internet traffic. This could be traffic patterns seen in specific countries or patterns related to events like the COVID-19 pandemic.

Sign up for Radar Alerts to always stay up-to-date.

Below the news section users can find rapidly updated trend data. All of which can be viewed worldwide or by country. The data is available for several time frames: last hour, last 24 hours, last 7 days. We'll soon make available the 30 days time frame to help explore longer term trends.

You can drill down on specific countries and Cloudflare Radar will show you the change in aggregate Internet traffic seen by our network for that country. We also show an info box on the right with a snapshot of interesting data points.

Worldwide and for individual countries we have an algorithm calculating which domains are most popular and have recently started trending (i.e. have seen a large change in popularity). Services with multiple domains and subdomains are aggregated to ensure best comparability. We show here the relative rank of domains and are able to spot big changes in ranking to highlight new trends as they appear.

The trending domains section are still in beta as we are training our algorithm to best detect the next big things as they emerge.

There is also a search bar that enables a user to search for a specific domain or IP address to get detailed information about it. More on that below.

The attack activity section gives information about different types of cyberattacks observed by Cloudflare. First we show the attacks mitigated by our Layer 3 and 4 Denial of Service prevention systems. We show the used attack protocol as well as the change in attack volume over the selected time frame.

Secondly, we show Layer 7 threat information based on requests that we blocked. Layer 7 requests get blocked by a variety of systems (such as our WAF, our layer 7 DDoS mitigation system and our customer configurable firewall). We show the system responsible for blocking as well as the change of blocked requests over the selected time frame.

Based on the analytics we handle on HTTP requests we are able to show trends over a diverse set of data points. This includes the distribution of mobile vs. desktop traffic, or the percentage of traffic detected as coming from bots. We also dig into longer term trends like the use of HTTPS or the share of IPv6.

The bottom section shows the top browsers worldwide or for the selected country. In this example we selected Vietnam and you can see that over 6% of users are using Cốc Cốc a local browser.

We give users the option to dig in deeper on an individual domain. Giving the opportunity to get to know the global ranking as well as security information. This enables everyone to identify potential threats and risks.

To look up a domain or hostname in Radar by typing it in the search box within the top domains on the Radar Internet Insights Homepage.

For example, suppose you search for cloudflare.com. You’ll get sent to a domain-specific page with information about cloudflare.com.

At the top we provide an overview of the domain’s configuration with Domain Badges. From here you can, at a glance, understand what technologies the domain is using. For cloudflare.com you can see that it supports TLS, IPv6, DNSSEC and eSNI. There’s also an indication of the age of the domain (since registration) and its worldwide popularity.

Below you find the domain’s content categories. If you find a domain that is in the wrong category, please use our Domain Categorization Feedback to let us know.

We also show global popularity trends from our domain ranking formula. For domains with a global audience there’s also a map giving information about popularity by country.

For an individual IP address (instead of a domain) we show different information. To look up an IP address simply insert it in the search bar within the top domains on the Radar Internet Insights. For a quick lookup of your own IP just open radar.cloudflare.com/me.

For IPs we show the network (the ASN) and geographic information. For your own IP we also show more detailed location information as well as an invitation to check the speed of your Internet connection using speed.cloudflare.com.

The current product is just the beginning of Cloudflare’s approach to making knowledge about the Internet more accessible. Over the next few weeks and months we will add more data points and the 30 days time frame functionality.  And we’ll allow users to filter the charts not only by country but also by categorization (such as by industry).

Stay tuned for more to come.