Every day, website visitors spend far too much time waiting for websites to load in their browsers. This waiting is partially due to browsers not knowing which resources are critically important so they can prioritize them ahead of less-critical resources. In this blog we will outline how millions of websites across the Internet can improve their performance by specifying which critical content loads first with Cloudflare Workers and what Cloudflare will do to make this easier by default in the future.

Popular Content Management Systems (CMS) like WordPress have made attempts to influence website resource priority, for example through techniques like lazy loading images. When done correctly, the results are magical. Performance is optimized between the CMS and browser without needing to implement any changes or coding new prioritization strategies. However, we’ve seen that these default priorities have opportunities to improve greatly.

In this co-authored blog with Google’s Patrick Meenan we will explain where the opportunities exist to improve website performance, how to check if a specific site can improve performance, and provide a small JavaScript snippet which can be used with Cloudflare Workers to do this optimization for you.

Before we dive into where the opportunities are to improve website performance, let’s take a step back to understand how browsers load website assets by default.

After the browser sends a HTTP request to a server, it receives a HTTP response containing information like status codes, headers, and the requested content. The browser carefully analyzes the response's status code and response headers to ensure proper handling of the content.

Next, the browser processes the content itself. For HTML responses, the browser extracts important information from the section of the HTML, such as the page title, stylesheets, and scripts. Once this information is parsed, the browser moves on to the response which has the actual page content. During this stage, the browser begins to present the webpage to the visitor.

If the response includes additional 3rd party resources like CSS, JavaScript, or other content, the browser may need to fetch and integrate them into the webpage. Typically, browsers like Google Chrome delay loading images until after the resources in the HTML have loaded. This is also known as “blocking” the render of the webpage. However, developers can override this blocking behavior using fetch priority or other methods to boost other content’s priority in the browser. By adjusting an important image's fetch priority, it can be loaded earlier, which can lead to significant improvements in crucial performance metrics like LCP (Largest Contentful Paint).

Images are so central to web pages that they have become an essential element in measuring website performance from Core Web Vitals. LCP measures the time it takes for the largest visible element, often an image, to be fully rendered on the screen. Optimizing the loading of critical images (like LCP images) can greatly enhance performance, improving the overall user experience and page performance.

But here's the challenge – a browser may not know which images are the most important for the visitor experience (like the LCP image) until rendering begins. If the developer can identify the LCP image or critical elements before it reaches the browser, its priority can be increased at the server to boost website performance instead of waiting for the browser to naturally discover the critical images.

In our Smart Hints blog, we describe how Cloudflare will soon be able to automatically prioritize content on behalf of website developers, but what happens if there’s a need to optimize the priority of the images right now? How do you know if a website is in a suboptimal state and what can you do to improve?

Using Cloudflare, developers should be able to improve image performance with heuristics that identify likely-important images before the browser parses them so these images can have increased priority and be loaded sooner.

Just increasing the fetch priority of all images won't help if they are lazy-loaded or not critical/LCP images. Lazy-loading is a method that developers use to generally improve the initial load of a webpage if it includes numerous out-of-view elements. For example, on Instagram, when you continually scroll down the application to see more images, it would only make sense to load those images when the user arrives at them otherwise the performance of the page load would be needlessly delayed by the browser eagerly loading these out-of-view images. Instead the highest priority should be given to the LCP image in the viewport to improve performance.

So developers are left in a situation where they need to know which images are on users' screens/viewports to increase their priority and which are off their screens to lazy-load them.

Recently, we’ve seen attempts to influence image priority on behalf of developers. For example, by default, in WordPress 5.5 all images with an IMG tag and aspect ratios were directed to be lazy-loaded. While there are plugins and other methods WordPress developers can use to boost the priority of LCP images, lazy-loading all images in a default manner and not knowing which are LCP images can cause artificial performance delays in website performance (they’re working on this though, and have partially resolved this for block themes).

So how do we identify the LCP image and other critical assets before they get to the browser?

To evaluate the opportunity to improve image performance, we turned to the HTTP Archive. Out of the approximately 22 million desktop pages tested in February 2023, 46% had an LCP element with an IMG tag. Meaning that for page load metrics, LCP had an image included about half the time. Though, among these desktop pages, 8.5 million had the image in the static HTML delivered with the page, indicating a total potential improvement opportunity of approximately 39% of the desktop pages within the dataset.

In the case of mobile pages, out of the ~28.5 million tested, 40% had an LCP element as an IMG tag. Among these mobile pages, 10.3 million had the image in the static HTML delivered with the page, suggesting a potential improvement opportunity in around 36% of the mobile pages within the dataset.

However, as previously discussed, prioritizing an image won't be effective if the image is lazy-loaded because the directives are contradictory. In the dataset,  approximately 1.8 million LCP desktop images and 2.4 million LCP mobile images were lazy-loaded.

Therefore, across the Internet, the opportunity to improve image performance would be about ~30% of pages that have an LCP image in the original HTML markup that weren’t lazy-loaded, but with a more advanced Cloudflare Worker, the additional 9% of lazy-loaded LCP images can also be improved improved by removing the lazy-load attribute.

If you’d like to determine which element on your website serves as the LCP element so you can increase the priority or remove any lazy-loading, you can use browser developer tools, or speed tests like Webpagetest or Cloudflare Observatory.

39% of desktop images seems like a lot of opportunity to improve image performance. So the next question is how can Cloudflare determine the LCP image across our network and automatically prioritize them?

We thought that how soon the LCP image showed up in the HTML would serve as a useful indicator. So we analyzed the HTTP Archive dataset to see where the cumulative percentage of LCP images are discovered based on their position in the HTML, including lazy-loaded images.

We found that approximately 25% of the pages had the LCP image as the first image in the HTML (around 10% of all pages). Another 25% had the LCP image as the second image. WordPress seemed to arrive at a similar conclusion and recently released a development to remove the default lazy-load attribute from the first image on block themes, but there are opportunities to go further.

Our analysis revealed that implementing a straightforward rule like "do not lazy-load the first four images," either through the browser, a content management system (CMS), or a Cloudflare Worker could address approximately 75% of the issue of lazy-loading LCP images (example Worker below).

In trying to find other ways to identify likely LCP images we next turned to the size of the image. To increase the likelihood of getting the LCP image early in the HTML, we looked into ignoring “small” images as they are unlikely to be big enough to be a LCP element. We explored several sizes and 10,000 pixels (less than 100x100) was a pretty reliable threshold that didn’t skip many LCP images and avoided a good chunk of the non-LCP images.

By ignoring small images (<10,000px), we found that the first image became the LCP image in approximately 30-34% of cases. Adding the second image increased this percentage to 56-60% of pages.

Therefore, to improve image priority, a potential approach could involve assigning a higher priority to the first four "not-small" images.

An experiment running in Chrome 114 does exactly what we described above. Within the browser there are a few different prioritization knobs to play with that aren’t web-exposed so we have the opportunity to assign a “medium” priority to images that we want to boost automatically (directly controlling priority with “fetch priority” lets you set high or low). This will let us move the images ahead of other images, async scripts and parser-blocking scripts late in the body but still keep the boosted image priority below any high-priority requests, particularly dynamically-injected blocking scripts.

We are experimenting with boosting the priority of varying numbers of images (2, 5 and 10) and with allowing one of those medium-priority images to load at a time during Chromes “tight” mode (when it is loading the render-blocking resources in the head) to increase the likelihood that the LCP image will be available when the first paint is done.

The data is still coming in and no “ship” decisions have been made yet but the early results are very promising, improving the LCP time across the entire web for all arms of the experiment (not by massive amounts but moving the metrics of the whole web is notoriously difficult).

Now that we’ve seen that there is a large opportunity across the Internet for helping prioritize images for performance and how to identify images on individual pages that are likely LCP images, the question becomes, what would the results be of implementing a network-wide rule that could boost image priority from this study?

We built a test worker and deployed it on some WordPress test sites with our friends at Rocket.net, a WordPress hosting platform focused on performance. This worker boosts the priority of the first four images while removing the lazy-load attribute, if present. When deployed we saw good performance results and the expected image prioritization.

export default {
  async fetch(request) {
    const response = await fetch(request);
 
    // Check if the response is HTML
    const contentType = response.headers.get('Content-Type');
    if (!contentType || !contentType.includes('text/html')) {
      return response;
    }
 
    const transformedResponse = transformResponse(response);
 
    // Return the transformed response with streaming enabled
    return transformedResponse;
  },
};
 
async function transformResponse(response) {
  // Create an HTMLRewriter instance and define the image transformation logic
  const rewriter = new HTMLRewriter()
    .on('img', new ImageElementHandler());
 
  const transformedBody = await rewriter.transform(response).text()
 
  const transformresponse = new Response(transformedBody, response)
 
  // Return the transformed response with streaming enabled
  return transformresponse
}
 
class ImageElementHandler {
  constructor() {
    this.imageCount = 0;
    this.processedImages = new Set();
  }
 
  element(element) {
    const imgSrc = element.getAttribute('src');
 
    // Check if the image is small based on Chrome's criteria
    if (imgSrc && this.imageCount < 4 && !this.processedImages.has(imgSrc) && !isImageSmall(element)) {
      element.removeAttribute('loading');
      element.setAttribute('fetchpriority', 'high');
      this.processedImages.add(imgSrc);
      this.imageCount++;
    }
  }
}
 
function isImageSmall(element) {
  // Check if the element has width and height attributes
  const width = element.getAttribute('width');
  const height = element.getAttribute('height');
 
  // If width or height is 0, or width * height < 10000, consider the image as small
  if ((width && parseInt(width, 10) === 0) || (height && parseInt(height, 10) === 0)) {
    return true;
  }
 
  if (width && height) {
    const area = parseInt(width, 10) * parseInt(height, 10);
    if (area < 10000) {
      return true;
    }
  }
 
  return false;
}

When testing the Worker, we saw that default image priority was boosted into “high” for the first four images and the fifth image remained “low.” This resulted in an LCP range of “good” from a speed test. While this initial test is not a dispositive indicator that the Worker will boost performance in every situation, the results are promising and we look forward to continuing to experiment with this idea.

While we’ve experimented with WordPress sites to illustrate the issues and potential performance benefits, this issue is present across the Internet.

Website owners can help us experiment with the Worker above to improve the priority of images on their websites or edit it to be more specific by targeting likely LCP elements. Cloudflare will continue experimenting using a very similar process to understand how to safely implement a network-wide rule to ensure that images are correctly prioritized across the Internet and performance is boosted without the need to configure a specific Worker.

Cloudflare’s Automatic Platform Optimization (APO) is a plugin for WordPress which allows Cloudflare to deliver your entire WordPress site from our network ensuring consistent, fast performance for visitors. By serving cached sites, APO can improve performance metrics. APO does not currently have a way to prioritize images over other assets to improve browser render metrics or dynamically rewrite HTML, techniques we’ve discussed in this post. Although this presents a potential opportunity for future development, it requires thorough testing to ensure safe and reliable support.

In the future we’ll look to include the techniques discussed today as part of APO, however in the meantime we recommend using Snippets (and Experiments) to test with the code example above to see the performance impact on your website.

If you are interested in using the JavaScript above, we recommended testing with Workers or using Cloudflare Snippets. We’d love to hear from you on what your results were. Get in touch via social media and share your experiences.

Cloudflare’s mission is to help build a better Internet. We’ve been at it since 2009 and we’re making progress — with approximately 25 million Internet properties being secured and accelerated by our platform.

When we look at other companies that not only have the scale to impact the Internet, but who are also on a similar mission, it’s hard to ignore Automattic, maintainers of the ubiquitous open-source WordPress software and owner of one the web’s largest WordPress hosting platforms WordPress.com, where up to 409 million people read 20 billion pages every month.¹

When we started brainstorming ways to combine our impact, one shared value stood out: privacy. We both share a vision for a more private Internet. Today we’re excited to announce a number of initiatives, starting with the integration of Cloudflare’s privacy-first web analytics into WordPress.com. This integration gives WordPress.com publishers choice in how they collect usage data and derive insights about their visitors.

Figure 1) Cloudflare Web Analytics tracking code integrated in the WordPress.com dashboard

Figure 2) An example of Cloudflare Web Analytics in the Cloudflare dashboard.

This is not the first time we’ve launched a WordPress-focused product. In October, we introduced Automatic Platform Optimization for WordPress sites, a service that our testing has shown to improve the TTFB by up to 72%!  This feature has been incredibly popular with our shared customer base and so we continued to look for ways to bring our two platforms closer together.

Starting today, Cloudflare Web Analytics settings will appear under the Marketing area of the WordPress.com dashboard, meaning users can simply paste in the analytics code snippet and WordPress.com will take care of injecting the code into their site at runtime. Users will also see links throughout the dashboard to Cloudflare APO and Cloudflare’s CDN, which they can enable within the Cloudflare dashboard.

Figure 3) Additional links to Cloudflare performance and security features in the WordPress.com dashboard

WordPress.com + Cloudflare has always been a best-of-breed collaboration, combining security and performance on one hand, with the world’s leading content management and publishing platform on the other. Integrating privacy-first web analytics with native support in the WordPress.com platform is just the latest step towards a better Internet.

To learn more and get started, visit our landing page.

¹https://wordpress.com/activity/

In the blog post, we answer the following questions:

• How fast is Automatic Platform Optimization? Can you demonstrate it with data?

We will show real-world improvements for several performance metrics.

• Is Automatic Platform Optimization flexible enough to integrate smoothly with my WordPress site?

We have added and improved lots of features since the initial launch.

• Will Automatic Platform Optimization work when used with other plugins?

We will cover the most common use cases and explain how Automatic Platform Optimization could be fined-tuned.

We use WebPageTest as a go-to tool for synthetic testing at Cloudflare. It measures web performance metrics in real browsers, is highly programmable, and could scale to test millions of sites per day. Among the benefits of synthetic testing are easy to produce results and their relatively high reproducibility.

Automatic Platform Optimization internal testing with WebPageTest demonstrated a very promising 72% reduction in Time to First Byte (TTFB) and 23% reduction to First Contentful Paint. Follow the original blog post to learn more about our test setup and results analysis.

In comparison to synthetic testing, Real User Monitoring (RUM) is invaluable in painting the picture of how a website performs in real-world conditions: on different form factors and variable connection types. Although noise to signal ratio could be high in RUM data, there is no substitute for measuring web performance in the wild.

We analyzed Google's Chrome User Experience Report of Automatic Platform Optimization websites and compared results from two months before enabling CrUX to the two months after. We present results of Time To First Byte, First Paint, First Contentful Paint, and Largest Contentful Paint.

Time To First Byte (TTFB) is the time taken from the user or client making an HTTP request until the first byte arrives back to the browser.

Automatic Platform Optimization improvements in the TTFB metric demonstrated the largest increase in the 'good' bucket and the largest decrease in the 'poor' bucket both on desktop and phone form factors among all metrics. The improvement in the 'poor' bucket on mobile demonstrates how Automatic Platform Optimization makes a difference even on slow connection types like 3G, 2G, slow 2G. Faster response times with Automatic Platform Optimization from edge servers translate directly into quicker TTFB timings, positively affecting all other performance measurements.

First Paint measures the first time the browser rendered any content. First Paint signifies the earliest point when something happens on the screen after a user requests a page. It is a good proxy for a user believing the website is not broken.

Almost a 10% increase in the 'good' bucket on a desktop is the highlight for the First Paint metric. It's nice to see a clear trend of improvement in both desktop and phone data. It's also worth mentioning that the exact values used to define 'good’, 'moderate’, and the 'poor' buckets are picked arbitrarily for each timing metric. This trend means it's more important to look at the percentage of improvement rather than absolute values for each 'bucket'.

First Contentful Paint (FCP) metric measures how long a page takes to start rendering any text, image, non-white canvas, or SVG content. FCP is a good indicator of perceived speed as it portrays how long people wait to see the first signs of a site loading.

It is the third straight metric that has been improved in both form factors after customers activated Automatic Platform Optimization. FCP happens even later than the First Paint event. We can draw a hypothesis that Automatic Platform Optimization positively impacts the loading performance metrics of the site. Still, the later the event happens, the less impact Automatic Platform Optimization has on that particular metric.

The Largest Contentful Paint (LCP) metric reports the render time for the largest image or text block visible within the viewport.

Our hypothesis holds ground with LCP as well. Interestingly enough, the positive impact of Automatic Platform Optimization activation is relatively equal on desktops and phones.

Overall, Automatic Platform Optimization consistently demonstrated better aggregate performance among sites we analyzed in TTFB, First Paint, FCP, and LCP metrics. Even more impressive are improvements on both desktop and phone form factors. It’s worth pointing out that apart from noticeable differences in hardware characteristics, phone data capture all mobile connection types from slow 2G to fast 4G.

We explored almost 200 websites with the activated Automatic Platform Optimization feature in Chrome User Experience Report data. To smooth the variance, we combined two months of data before and after Automatic Platform Optimization activation. To further decrease inaccuracy, we dropped a month’s worth of data that included the activation period. As an example, for a website that activated Automatic Platform Optimization last October, we used Chrome User Experience Report measurements from August and September as the before bucket. The after bucket combined data from November and December.

It is important to note that due to the limitations of iOS, Chrome User Experience Report mobile results don't include devices running Apple's mobile operating system.

Chrome User Experience Report data provides performance metrics per geographic location, form factor, or connection type. We analyzed aggregated data across all countries and connection types to focus on the overall performance.

Since the product launch, we have been listening carefully to the customers' reports of Automatic Platform Optimization’s missing functionality or unexpected behavior. The number of different use cases our customers have underlines how broad the WordPress ecosystem is. One of the advantages of Automatic Platform Optimization utilizing the Workers platform is that we can quickly iterate and release in a matter of hours instead of days or weeks. Granted, some features like Cache By Device Type or subdomains support took us longer to build. Still, for apparent bugs or missing functionality, the ability to release on demand made all the difference for the team and our customers.

We start the second part of the report with a brief description of the features we have released since October. Afterward, we will paint a bigger picture of how Automatic Platform Optimization fits together with a broad WordPress plugins ecosystem.

By default Automatic Platform Optimization doesn’t cache pages with query parameters. One of the first feature requests from the community was to add caching support for marketing attribution (for example, UTMs) query parameters. We did exactly that, and the full list of the supported parameters is in the documentation.

Cloudflare provides static caching out of the box by default. The caching system for static content relies on file extensions to determine the content type. In contrast, HTML pages don't always have file extensions in the URL. That's why Automatic Platform Optimization caching relies on HTTP's content negotiation mechanism for HTML content.

We check both the request's Accept and the response's Content-Type headers for the 'text/html' substring. When humans access sites on the Internet, browsers send correct Accept headers behind the scene. When bots access the sites, they don't always send Accept headers. Initially, the Automatic Platform Optimization cache passed all requests without a valid Accept header to the origin servers. When customers tried to migrate from using the "Cache Everything" page rule to only using Automatic Platform Optimization, they noticed extra load on the origin servers.. Now all GET and HEAD requests are checked against the Automatic Platform Optimization cache. The change noticeably improved the cache hit ratio for all Automatic Platform Optimization customers and enhanced page loads for good bots.

Cache poisoning is a common attack vector against any caching system. One of the benefits of Automatic Platform Optimization is that most of the logic runs on edge servers, and we can update it without any changes on the origin server. To mitigate potential cache poisoning, we released a new version to bypass caching if any of the following request headers are present:

• X-Host

• X-Forwarded-Host

• X-Original-URL

• X-Rewrite-URL

Additionally, any GET request with a body will bypass Automatic Platform Optimization caching.

Automatic Platform Optimization's primary goal is to improve page load performance while keeping the configuration as simple as possible. On the other hand, the Automatic Platform Optimization service should allow fine-tuning for advanced use cases. One such mechanism is Cloudflare's Page Rules. As of today, Automatic Platform Optimization supports the following rules:

• Cache Level: Bypass

• Cache Level: Ignore Query String

• Cache Level: Cache Everything

• Bypass Cache on Cookie (Biz and Ent plans only)

• Edge Cache TTL

• Browser Cache TTL

For a detailed description, refer to the official documentation.

Automatic Platform Optimization aims to provide seamless integration with the WordPress ecosystem. It recognizes specific cookies for the most popular plugins like WooCommerce, JetPack, BigCommerce, Easy Digital Downloads, etc.

Currently, we limit Automatic Platform Optimization usage to WordPress sites. During the initial launch, we restricted Automatic Platform Optimization to run against root domains only, but we learned later of the high demand to run Automatic Platform Optimization on subdomains. To make it possible, we updated both the plugin and API to allow Automatic Platform Optimization to run on subdomains. Three steps are required to enable Automatic Platform Optimization on a subdomain:

• Install version 3.8.7 or later of the Cloudflare WordPress plugin.

• Log in using Global key. (You can only use an API token for the root domain.)

• Enable APO. The subdomain displays in the list of hostnames in the card.

The initial cost of $5 per month for Free plans includes running Automatic Platform Optimization against any number of subdomains.

The majority of site visits come from users accessing the web on mobile devices. And website visitors expect sites to work well on mobile devices. In fact, responsive design is a recommended approach for websites. APO works well for responsive design websites because the cache's content will adjust to the client's screen size seamlessly. The alternative method is to serve different markup on mobile browsers.

Many popular WordPress plugins add a mobile-friendly theme to the site. For sites with such plugins installed, Automatic Platform Optimization breaks functionality by serving the same cached version for all users. As we learned about the growing number of customers with this problem, we looked for the solution. Cloudflare’s caching already has support for cache by device type functionality, but it's only available for customers on the Enterprise plan. As was a case for the Bypass Cache on Cookie page rule, we decided to include the functionality as part of the Automatic Platform Optimization offering. As a recap, Caching by Device Type relies on the User-Agent request header for detection. There are three types:

• Mobile

• Tablet

• Everything else

For each type, the Cloudflare cache will store content in a separate bucket. To enable caching by device type, either navigate to the dashboard's Automatic Platform Optimization card or the Cloudflare WordPress plugin. We recommend using a single cache whenever possible because caching by device type can decrease cache hit ratio and increase the load on origin servers.

There are many improvements including:

• Improved purging infrastructure of content from KV.

• Extended automatic cache purging for categories and tags.

• Addressed many edge cases for Google Fonts optimization.

• Added support for HEAD requests.

• Automated release pipeline for the Cloudflare WordPress plugin.

There are over 50,000 WordPress plugins currently available for download, and because there are so many, we can't test the compatibility of Automatic Platform Optimization with each one individually. We do know, however, that it's vital to provide compatibility for the most popular plugins. Thanks to the vibrant community, we quickly learned about the most widely used issues with Automatic Platform Optimization caching. The plugins that experienced problems could be grouped into the following categories:

• Plugins with custom cookies

• Plugins with geolocation functionality

• Plugins with mobile themes

• Plugins with AMP support

• Plugins that generate HTML

• Caching and optimizations plugins

Let's review those categories and available solutions for improved compatibility.

One of the critical features Automatic Platform Optimization provides out of the box is cookie-based rules to bypass APO caching. For any plugin that uses custom cookies, Automatic Platform Optimization requires extending the rules. We have a list of supported plugins that uses our cookies bypass logic.

This broad category of plugins relies on geolocation information based on the client's (visitor) IP address (connecting to Cloudflare) to provide its functionality. Early on, we had a misconfiguration in Automatic Platform Optimization functionality that resulted in sending a dummy IP address in the CF-Connecting-IP request header that was forwarded to the origin server.

This behavior effectively broke the functionality of the widely used Wordfence Security plugin. We promptly released a fix. Because we use Cloudflare Workers internally, Cloudflare Workers treated Automatic Platform Optimization requests sent to the origin as cross-zone requests due to security concerns. As a result, the CF-Connecting-IP header value was replaced with a dummy IP address. The change was to send the Automatic Platform Optimization worker's subrequest to the origin as a same-zone request to pass the real client IP without a security concern. Also, Automatic Platform Optimization now sends the client's IP via the X-Forwarded-For request header to the origin to improve plugin compatibility.

There are several WordPress plugins that render custom themes for mobile visitors. Those plugins rely on the browser's User-Agent to detect visitors from mobile devices. In December, we released Automatic Platform Optimization support for the "Cache by device type" feature. With a single configuration change, you can activate a separate cache based on the device type: mobile, tablet, and everything else. You can learn more about the feature in the official documentation.

The AMP (Accelerated Mobile Pages) project's goal is to make the web, and, in particular, the mobile web, much more pleasant to surf. The AMP HTML framework is designed to help web pages load quickly and avoid distracting the user with irrelevant content.

The most popular AMP WordPress plugins render AMP-compatible markup when the page URL contains the amp= query parameter. AMP markup is a subset of HTML with several restrictions and we looked into possible solutions to provide Automatic Platform Optimization caching for AMP pages. It requires a separate cache for AMP pages similar to the "Cache by device type" feature. Considering Google's recent push with Core Web Vitals, the AMP format's importance will decrease going forward. Based on the complexity of supporting dedicated AMP caching and Google's deprioritization of the AMP format, we decided to bypass Automatic Platform Optimization caching of AMP pages.

There are two possible approaches for caching AMP pages. The first one is to change the URL schema for AMP pages from, for example, site.com/page/?amp= to site.com/amp/page/. With this option, Automatic Platform Optimization caches AMP pages out of the box. Another solution is to activate the "Cache Everything" Page rule for AMP pages served with amp= query parameter. Note that AMP pages will require manual cache purging in both cases on content change.

Using Automatic Platform Optimization with Page Rules makes it possible to:

• Bypass caching pages that contain CAPTCHAs.

• Set Edge TTL for pages that contain nonces or server-rendered ads to six hours or shorter.

Among the most popular caching and optimizations WordPress plugins are LiteSpeed Cache, W3 Total Cache, WP Rocket, WP Fastest Cache, WP Super Cache, Autoptimize. To successfully activate Advanced Platform Optimization when any of the plugins above already present, follow these steps:

• Install and activate the Cloudflare WordPress plugin.

• Enable Automatic Platform Optimization in the plugin.

• Clear any server cache used via other plugins.

• Verify that your origin starts serving the response header "cf-edge-cache: cache,platform=wordpress".

That should make caching plugins and Automatic Platform Optimization compatible.

In using optimizations features inside the plugins, additional steps are necessary to integrate with Automatic Platform Optimization. Any of the following plugin's optimizations require subsequent purging of Cloudflare cache:

• JavaScript minification and async-loading

• CSS minification, inlining, and aggregation

• HTML minification

• Images optimization and lazy-loading

• Google fonts optimizations

There are three potential solutions we discuss in the order of preference.

Most of the optimizations are possible with Cloudflare today:

• Auto Minify provides minification for HTML, CSS, and JavaScript

• Rocket Loader provides JavaScript lazy loading

• Mirage and Image-resizing allows image optimization and lazy-loading

• Advanced Platform Optimization optimizes Google fonts out of the box

• WP Rocket integrates with Cloudflare API.

• WP Fastest Cache integrates with Cloudflare API.

• W3 Total Cache integrates with Cloudflare API. Make sure to enable the Page Caching option.

The rest of the plugins in the list, when producing content optimizations, require triggering of Cloudflare cache purging manually or via API:

• LiteSpeed Cache

• WP Super Cache

• Autoptimize

Automatic Platform Optimization is compatible with the most popular caching plugins. Content optimizations should be preferably migrated to Cloudflare offerings. Alternatively, plugins require triggering Cloudflare cache purging via API integration. The action of the last resort is to disable plugins optimizations but keep caching functionality.

We work closely with the WordPress plugins community to improve compatibility with Advanced Platform Optimization.

Automatic Platform Optimization demonstrated improved performance metrics in both synthetic and real-world settings. The public Chrome User Experience Report dataset proved to be an invaluable source of RUM metrics for web performance analysis. Automatic Platform Optimization showed noticeable improvements on desktops and phones. TTFB is the most improved metric, but we also noticed positive changes in the First Paint, First Contentful Paint, and Largest Contentful Paint metrics.

It has been intensive and rewarding several months since the Automatic Platform Optimization launch, and we greatly increased Automatic Platform Optimization applicability based on customer feedback. Our community forum is a great place to get help and ask questions about Cloudflare products, including Advanced Platform Optimization.

There are more exciting Automatic Platform Optimization improvements the team is actively working on, and we can't wait to share them. Stay tuned!

The service is an evolution of the ideas explained in an earlier zero-config edge caching of HTML blog post. The post will explain how Automatic Platform Optimization combines the best qualities of the regular Cloudflare cache with Workers KV to improve cache cold starts globally.

The optimization will work both with and without the Cloudflare for WordPress plugin integration. Not only have we provided a zero config edge HTML caching solution but by using the Workers platform we were also able to improve the performance of Google font loading for all pages.

We are launching the feature first for WordPress specifically but the concept can be applied to any website and/or content management system (CMS).

There are many individual WordPress plugins for performance that use similar optimizations to existing Cloudflare services. Automatic Platform Optimization is bringing them all together into one easy to use solution, deployed at the edge.

Traditionally you have to maintain server plugins with your WordPress installation. This comes with maintenance costs and can require a deep understanding of how to fine tune performance and security for each and every plugin. Providing the optimizations on the client side can also lead to performance problems due to the costs of JavaScript execution. In contrast most of the optimizations could be built-in in Cloudflare’s edge rather than running on the server or the client. Automatic Platform Optimization will be always up to date with the latest performance and security best practices.

By default Cloudflare CDN caches assets based on file extension and doesn’t cache HTML content. It is possible to configure HTML caching with a Cache Everything Page rule but it is a manual process and often requires additional features only available on the Business and Enterprise plans. So for the majority of the WordPress websites even with a CDN in front them, HTML content is not cached. Requests for a HTML document have to go all the way to the origin.

Even if a CDN optimizes the connection between the closest edge and the website’s origin, the origin could be located far away and also be slow to respond, especially under load.

One of the primary recommendations for speeding up websites is to move content closer to the end-user. This reduces the amount of time it takes for packets to travel between the end-user and the web server - the round-trip time (RTT). This improves the speed of establishing a connection as well as serving content from a closer location.

We have previously blogged about the benefits of edge caching HTML. Caching and serving from HTML from the Cloudflare edge will greatly improve the time to first byte (TTFB) by optimizing DNS, connection setup, SSL negotiation, and removing the origin server response time.If your origin is slow in generating HTML and/or your user is far from the origin server then all your performance metrics will be affected.

Most HTML isn’t really dynamic. It needs to be able to change relatively quickly when the site is updated but for a huge portion of the web, the content is static for months or years at a time. There are special cases like when a user is logged-in (as the admin or otherwise) where the content needs to differ but the vast majority of visits are of anonymous users.

The goal is to make updating content to the edge happen automatically. The edge will cache and serve the previous version content until there is new content available. This is usually achieved by triggering a cache purge to remove existing content. In fact using a combination of our WordPress plugin and Cloudflare cache purge API, we already support Automatic Cache Purge on Website Updates. This feature has been in use for many years.

Building automatic HTML edge caching is more nuanced than caching traditional static content like images, styles or scripts. It requires defining rules on what to cache and when to update the content. To help with that task we introduced a custom header to communicate caching rules between Cloudflare edge and origin servers.

The Cloudflare Worker runs from every edge data center, the serverless platform will take care of scaling to our needs. Based on the request type it will return HTML content from Cloudflare Cache using Worker’s Cache API or serve a response directly from the origin. Specifically designed custom header provides information from the origin on how the script should handle the response. For example worker script will never cache responses for authenticated users.

With or without Cloudflare for WordPress plugin, HTML edge caching requires all of the following conditions to be met:

• Origin responds with 200 status

• Origin responds with "text/html" content type

• Request method is GET.

• Request path doesn’t contain query strings

• Request doesn’t contain any WordPress specific cookies: "wp-*", "wordpress*", "comment_*", "woocommerce_*" unless it’s "wordpress_eli" or "wordpress_test_cookie".

• Request doesn’t contain any of the following headers:

  • "Cache-Control: no-cache"

  • "Cache-Control: private"

  • "Pragma:no-cache"

  • "Vary: *"

Note that the caching is bypassed if the devtools are open and the “Disable cache” option is active.

The preferred solution requires a configured Cloudflare for WordPress plugin. We provide the following features set when the plugin is activated:

• HTML edge caching with 30 days TTL

• 30 seconds or faster cache invalidation

• Bypass HTML caching for logged in users

• Bypass HTML caching based on presence of WordPress specific cookies

• Decrease load on origin servers. If a request is fetched from Cloudflare CDN Cache we skip the request to the origin server.

When an eyeball requests a page from a website and Cloudflare doesn’t have a copy of the content it will be fetched from the origin. As the response is sent from the origin and goes through Cloudflare’s edge, Cloudflare for WordPress plugin adds a custom header: cf-edge-cache. It allows an origin to configure caching rules applied on responses.

Based on the X-HTML-Edge-Cache proposal the plugin adds a cf-edge-cache header to every origin response. There are 2 possible values:

• cf-edge-cache: no-cache

The page contains private information that shouldn’t be cached by the edge. For example, an active session exists on the server.

• cf-edge-cache: cache, platform=wordpress

This combination of cache and platform will ensure that the HTML page is cached. In addition, we ran a number of checks against the presence of WordPress specific cookies to make sure we either bypass or allow caching on the Edge.

If the header isn’t present we assume that the Cloudflare for WordPress plugin is not installed or up-to-date. In this case the feature operates without a plugin support.

Using the Automatic Platform Optimization feature in combination with Cloudflare for WordPress plugin is our recommended solution. It provides the best feature set together with almost instant cache invalidation. Still, we wanted to provide performance improvements without the need for any installation on the origin server.

We provide the following features set when the plugin is not activated:

• HTML edge caching with 30 days TTL

• Cache invalidation may take up to 30 minutes. A manual cache purge could be triggered to speed up cache invalidation

• Bypass HTML caching based on presence of WordPress specific cookies

• No decreased load on origin servers. If a request is fetched from Cloudflare CDN Cache we still require an origin response to apply cache invalidation logic.

Without Cloudflare for WordPress plugin we still cache HTML on the edge and serve the content from the cache when possible. The logic of cache revalidation happens after serving the response to the eyeball. Worker’s waitUntil() callback allows the user to run code without affecting the response to the eyeball and is run in background.

We rely on the following headers to detect whether the content is stale and requires cache update:

• ETag. If the cached version and origin response both include ETag and they are different we replace cached version with origin response. The behavior is the same for strong and weak ETag values.

• Last-Modified. If the cached version and origin response both include Last-Modified and origin has a later Last-Modified date we replace cached version with origin response.

• Date. If no ETag or Last-Modified header is available we compare cached version and origin response Date values. If there was more than a 30 minutes difference we replace cached version with origin response.

Cloudflare Cache works great for the frequently requested content. Regular requests to the site make sure the content stays in cache. For a typical personal blog, it will be more common that the content stays in cache only in some parts of our vast edge network. With the Automatic Platform Optimization release we wanted to improve loading time for cache cold start from any location in the world. We explored different approaches and decided to use Workers KV to improve Edge Caching.

In addition to Cloudflare's CDN cache we put the content into Workers KV. It only requires a single request to the page to cache it and within a minute it is made available to be read back from KV from any Cloudflare data center.

After an update has been made to the WordPress website the plugin makes a request to Cloudflare’s API which both purges cache and marks content as stale in KV. The next request for the asset will trigger revalidation of the content. If the plugin is not enabled cache revalidation logic is triggered as detailed previously.

We serve the stale copy of the content still present in KV and asynchronously fetch new content from the origin, apply possible optimizations and then cache it (both regular local CDN cache and globally in KV).

To store the content in KV we use a single namespace. It’s keyed with a combination of a zone identifier and the URL. For instance:

1:example.com/blog-post-1.html => "transformed & cached content"

For marking content as stale in KV we write a new key which will be read from the edge. If the key is present we will revalidate the content.

stale:1:example.com/blog-post-1.html => ""

Once the content was revalidated the stale marker key is deleted.

On top of caching HTML at the edge, we can pre-process and transform the HTML to make the loading of websites even faster for the user. Moving the development of this feature to our Cloudflare Workers environment makes it easy to add performance features such as improving Google Font loading. Using Google Fonts can cause significant performance issues as to load a font requires loading the HTML page; then loading a CSS file and finally loading the font. All of these steps are using different domains.

The solution is for the worker to inline the CSS and serve the font directly from the edge minimizing the number of connections required.

If you read through the previous blog post’s implementation it required a lot of manual work to provide streaming HTML processing support and character encodings. As the set of worker APIs have improved over time it is now much simpler to implement. Specifically the addition of a streaming HTML rewriter/parser with CSS-selector based API and the ability to suspend the parsing to asynchronously fetch a resource has reduced the code required to implement this from ~600 lines of source code to under 200.

export function transform(request, res) {
  return new HTMLRewriter()
    .on("link", {
      async element(e) {
        const src = e.getAttribute("href");
        const rel = e.getAttribute("rel");
        const isGoogleFont =
          src.startsWith("https://fonts.googleapis.com")

        if (isGoogleFont && rel === "stylesheet") {
          const media = e.getAttribute("media") || "all";
          const id = e.getAttribute("id") || "";
          try {
            const content = await fetchCSS(src, request);
            e.replace(styleTag({ media, id }, content), {
              html: true
            });
          } catch (e) {
            console.error(e);
          }
        }
      }
    })
    .transform(res);
}

The HTML transformation doesn’t block the response to the user. It’s running as a background task which when complete will update kv and replace the global cached version.

We are launching the feature for WordPress specifically but the concept can be applied to any website and content management system (CMS).

Today, we are announcing a new service to serve more than just the static content of your website with the Automatic Platform Optimization (APO) service. With this launch, we are supporting WordPress, the most popular website hosting solution serving 38% of all websites. Our testing, as detailed below, showed a 72% reduction in Time to First Byte (TTFB), 23% reduction to First Contentful Paint, and 13% reduction in Speed Index for desktop users at the 90th percentile, by serving nearly all of your website’s content from Cloudflare’s network. This means visitors to your website see not only the first content sooner but all content more quickly.

With Automatic Platform Optimization for WordPress, your customers won’t suffer any slowness caused by common issues like shared hosting congestion, slow database lookups, or misbehaving plugins. This service is now available for anyone using WordPress.

APO for WordPress costs $5/month for customers on our Free plan and is included, at no additional cost, in our Professional, Business, and Enterprise plans. No usage fees, no surprises, just speed.

The easiest way to get started with APO is from your WordPress admin console.

1. First, install the Cloudflare WordPress plugin on your WordPress website or update to the latest version (3.8.2 or higher). 2. Authenticate the plugin (steps here) to talk to Cloudflare if you have not already done that. 3. From the Home screen of the Cloudflare section, turn on Automatic Platform Optimization. Free customers will first be directed to the Cloudflare Dashboard to purchase the service.

At Cloudflare, we jump at the opportunity to make hard problems for our customers disappear with the click of a button. Running a consistently fast website is challenging. Many businesses don’t have the time nor money to spend on complicated and expensive performance solutions for their site. Even if they do, it can be extremely costly to pay for specialized attention to ensure you get the best performance possible. Having a fast website doesn’t have to be complicated, though. The closer your content is to your customers, the better your site will perform. Static content caching does this for files like images, CSS and JavaScript, but that is only part of the equation. Dynamic content is still fetched from the origin incurring costly round trips and additional processing time. For more info on dynamic versus static content, see our learning center.

WordPress is one of the most open platforms in the world, but that means you are always at risk of incurring performance penalties because of plugins or other sources that, while necessary, may be hard to pinpoint and resolve. With the Automatic Platform Optimization service, we put your website into our network that is within 10 milliseconds of 99% of the Internet-connected population in the developed world, all without having to change your existing hosting provider. This means that for most requests your customers won’t even need to go to your origin, reducing many costly round trips and server processing time. These optimizations run on our edge network, so they also will not impact render or interactivity since no additional JavaScript is run on the client.

Evaluating performance of a website is difficult. There are many different metrics you can track and it is not always obvious which metrics most meaningfully represent a user’s experience. As discussed when we blogged about our new Speed page, we aim to simplify this for customers by automating tests using the infrastructure of webpagetest.org, and summarizing both the results visually and numerically in one place.

The visualization gives you a clear idea of what customers are going to see when they come to your site, and the Critical Loading Times provide the most important metrics to judge your performance. On top of seeing your site’s performance, we provide a list of recommendations for ways to even further increase your performance. If you are using WordPress, then we will test your site with Automatic Platform Optimizations to estimate the benefit you will get with the service.

We tested APO on over 500 Cloudflare customer websites that run on WordPress to understand what the performance improvements would be. The results speak for themselves:

Test Results

Note: Results are based on test results of 505 randomly selected websites that are cached by Cloudflare. Tests were run using WebPageTest from South Carolina, USA and the following environment: Chrome, Cable connection speed.

Most importantly, with APO, a site’s TTFB is made both fast and consistent. Because we now serve the HTML from Cloudflare’s edge with 0 origin processing time, getting the first byte to the eyeball is consistently fast. Under heavy load, a WordPress origin can suffer delays in building the HTML and returning it to visitors. APO removes the variance due to load resulting in consistent TTFB <400 ms.

Additionally, between faster TTFB and additional caching of third party fonts, we see performance improvements in both FCP and SI for both the fastest and slowest of the sites we tested. Some of this comes naturally from reducing the TTFB, since every millisecond you shave off of TTFB is a potential millisecond gain for other metrics. Caching additional third party fonts allows us to reduce the time it takes to fetch that content. Given fonts can often block paints due to text rendering, this improves the rate at which the page paints, and improves the Speed Index.

We asked the folks at Kinsta to try out APO, given their expertise on WordPress, and tell us what they think. Brian Li, a Website Content Manager at Kinsta, ran a set of tests from around the world on a website hosted in Tokyo. I’ll let him explain what they did and the results:

At Kinsta, WordPress performance is something that’s near and dear to our hearts. So, when Cloudflare reached out about testing their new Automatic Platform Optimization (APO) service for WordPress, we were all ears. This is what we did to test out the new service:

1. We set up a test site in Tokyo, Japan – one of the 24 high-performance data center locations available for Kinsta customers.

2. We ran several speed tests from six different locations around the world with and without Cloudflare’s APO.

The results were incredible! By caching static HTML on Cloudflare’s edge network, we saw a 70-300% performance increase. As expected, the testing locations furthest away from Tokyo saw the biggest reduction in load time. If your WordPress site uses a traditional CDN that only caches CSS, JS, and images, upgrading to Cloudflare’s WordPress APO is a no-brainer and will help you stay competitive with modern Jamstack and static sites that live on the edge by default.

Brian’s test results are summarized in this image:

_{Page Load Speeds for loading a website hosted in Tokyo from 6 locations worldwide - comparing Kinsta, Kinsta with KeyCDN, and Kinsta with Cloudflare APO.}

One of the clear benefits, from Kinsta’s testing of APO, is the consistency of performance for serving your site no matter where your visitors are in the world. The consistent sub-second performance shown with APO versus two or three second load times in other setups makes it clear that if you have a global customer base, APO delivers an improved experience for all visitors.

Automatic Platform Optimization is the result of being able to use the power of Cloudflare Workers to intelligently cache dynamic content. By caching dynamic content, we can serve the entire website from our edge network. Think ‘static site’ but without any of the work of having to build or maintain a static site. Customers can keep managing and updating content on their website in the same way and leave the hard work for performance to us. Serving both static and dynamic content from our network results, generally, in no origin requests or origin processing time. This means all the communication occurs between the user’s device and our edge. Reducing the multitude of round trips typically required from our edge to the origin for dynamic content is what makes this service so effective. Let’s first see what it normally looks like to load a WordPress site for a visitor.

_{A sequence diagram for a typical user visiting a site‌‌}

In a regular request flow, Cloudflare is able to cache some of the content like images, CSS, or JS, while other requests go to either the origin or a third party service in order to fetch the content. Most importantly the first request to fetch the HTML for the site needs to go to the origin which is a typical cause of long TTFB, since no other requests get made until the client can receive the HTML and parse it to make subsequent requests.

_{The same site visit but with APO enabled.}

Once APO is enabled, all those trips to the origin are removed. TTFB benefits greatly because the first hop starts and ends at Cloudflare’s network. This also means the browser starts working on fetching and painting the webpage sooner meaning each paint event occurs earlier. Last by caching third party fonts, we remove additional requests that would need to leave Cloudflare’s network and extend the time to display text to the user. Often, websites use fonts hosted on third-party domains. While this saves bandwidth costs that would be incurred from hosting it on the origin, depending on where those fonts are hosted, it can still be a costly operation to fetch them. By rehosting the fonts and serving them from our cache, we can reduce one of the remaining costly round trips.

With APO for WordPress, you can say bye bye to database congestion or unwieldy plugins slowing down your customers’ experience. These benefits are stacked on top of our already fast TLS connection times and industry leading protocol support like HTTP/2 that ensure we are using the most efficient and the fastest way to connect and deliver your website to your customers.

For customers with WordPress sites that support authenticated sessions, you do not have to worry about us caching content from authenticated users and serving it to others. We bypass the cache on standard WordPress and WooCommerce cookies for authenticated users. This ensures customized content for a specific user is only visible to that user. While this has been available to customers with our Business-level service, it is now available for any WordPress customer that enables APO.

You might be wondering: “This all sounds great, but what about when I change content on my site?” Because this service works in tandem with our WordPress plugin, we are able to understand when you make changes and ensure we quickly purge the content in Cloudflare’s edge and refresh it with the new content. With the plugin installed, we detect content changes and update our edge network worldwide with automatic cache purges. As part of this release, we have updated our WordPress plugin, so whether you use APO, you should upgrade to the latest version today. If you do not or cannot use our WordPress plugin, then APO will still provide the same performance benefits, but may serve stale content for up to 30 minutes and when the content is requested again.

This service was built on the prototype work originally blogged about here and here. For a more in depth look at the technical side of the service and how Cloudflare Workers allowed us to build the Automatic Platform Optimization service, see the accompanying blog post.

While today’s announcement is focused on supporting WordPress, this is just the start. We plan to bring these same capabilities to other popular platforms used for web hosting. If you operate a platform and are interested in how we may be able to work together to improve things for all your customers, please get in touch. If you are running a website, let us know what platform you want to see us bring Automatic Platform Optimization to next.

WordPress is the most popular CMS (content management system) in the world, powering over a third of the top 10 million websites, according to W3Techs.

WordPress is an open source software project that many website service providers host for end customers to enable them to build WordPress sites and serve that content to visitors over the Internet.  For hosting providers, one of the opportunities and challenges is to host one version of WordPress on their infrastructure that is high performing for all their customers without modifying the WordPress code on a per customer basis.

Hosting providers are increasingly turning to Cloudflare’s Serverless Workers Platform to deliver high performance to their end customers by fixing performance issues at the edge while avoiding modifying code on an individual site basis.

One innovative WordPress hosting provider that Cloudflare has been working with to do this is Bluehost, a recommended web host by WordPress.org. In collaboration with Bluehost, Cloudflare’s Workers have been able to achieve a 40% performance improvement for those sites running Workers. Bluehost started with Cloudflare Workers code for Fast Google Fonts which in-lines the browser-specific font CSS and re-hosts the font files through the page origin. This removes the multiple calls to load the CSS and the font file from Google and improves WordPress site response time.  Bluehost then went further and added additional performance enhancements that rehosted commonly run third party scripts and caches dynamic HTML on the edge in conjunction with Bluehost’s own plugin infrastructure.

Bluehost will offer Cloudflare Workers in early 2020. Once implemented, customers will see faster response times, which could result in more website visitors sticking with the site while it renders. Additional benefits could include improved ad dollars from a higher number of impressions and ecommerce revenue from more shoppers.

“We were so impressed to see a 40% performance improvement for websites leveraging Workers, and can’t wait to offer this to our customers in 2020. Our team is excited to partner with Cloudflare and continue to innovate with Workers for added benefits for our customers,” said Suhaib Zaheer, General Manager for Bluehost.

Stay tuned for more performance improvements with Cloudflare Workers!

Looking at a recent test data set (~100k pages):

20% TTFB > 3s80% start render > 5s (10% > 10s)500 pages were > 15MB

So much slow to fix

— Patrick Meenan (@patmeenan) August 10, 2016

There is a reason why TTFB appears as one of the few “grades” that WebPageTest scores a site on and, specifically, why it is the first grade in the list.

If the first byte is slow, EVERY other metric will also be slow. Improving it is one of the few cases where you can predict what the impact will be on every other measurement. Every millisecond improvement in the TTFB translates directly into a millisecond of savings in every other measurement (i.e. first paint will be 500ms faster if TTFB improves by 500ms). That said, a fast ttfb doesn't guarantee a fast experience but a slow ttfb does guarantee a slow experience. I’d estimate that roughly 50% of all requests for help with WebPageTest results come from site owners struggling with a slow TTFB.

Many things can roll up into the TTFB, including redirects, DNS, connection setup, SSL negotiation and the actual server response time. Most of them can be fixed relatively easily by using a service like Cloudflare, but the server response time for the HTML itself is often the biggest problem and the hardest one to solve.

The waterfall diagram below shows the server response time as a light blue bar on the first request and it can be painfully obvious when it is slow. Under optimal conditions, the server response time would be no longer than the orange socket connect bar right before it.

Over three seconds for the server to respond.

Slow origin response times can be caused by an enormous assortment of issues from the server configuration, system load, back-end databases and systems it talks to, to the application code itself. Getting to the root of the performance issues usually involves teams of Dev Ops engineers working with Application Performance Management tools to track down the slowest parts of the application and improve them.

A huge portion of the site owners I have worked with don’t have the resources or expertise to handle that kind of an investigation. More often than not, they paid someone a one-time development fee to build their site or built it themselves on WordPress and are hosting it on the lowest-cost hosting they could find. The hosting is generally designed to run as many sites as possible, not necessarily for the highest performance.

The thing is, most HTML isn’t really dynamic. It needs to be able to change relatively quickly when the site is updated but for a huge portion of the web the content is static for months or years at a time.

There are special cases like when a user is logged-in (as the admin or otherwise) where the content needs to differ but the vast majority of visits are of anonymous users. If the HTML can be cached and served directly from the edge then the performance gains can be substantial (over 3 seconds faster on all metrics in this case).

Much faster server response time.

There are dozens of plugins for WordPress for caching content at the origin but they require configuration (where to cache the pages) and the performance still depends heavily on the performance of the hosting itself. Pushing the content cache further out to the edge reduces the complexity, eliminates the additional time to get back to the origin and completely removes the hosting performance from the equation. It can also significantly reduce the load on the hosting systems by offloading all of the anonymous traffic.

Cloudflare supports caching static HTML, and business and enterprise customers can enable logged-in users to skip the cache by enabling “bypass cache on cookies”. It works in tandem with the Cloudflare plugin for WordPress so the cache can be cleared whenever content is updated. There are also several other caching plugins that integrate with various CDN’s but in all of the cases they need to be configured with API keys for the CDN and the implementations are specific for each CDN.

For broad adoption, we need to make the caching of HTML happen automatically (or as close to automatically as possible). To that end, we need a way to communicate between an origin (like a WordPress site) and an edge cache (like Cloudflare’s edge nodes) for managing a remote cache that can be explicitly purged.

The Origin needs to be able to:

• Recognize when there is a supported edge cache in front of it.

• Specify content that should be cached and for what visitors (i.e. visits without a login cookie).

• Purge the cached content when it has changed (globally across all edges).

Instead of requiring the origin to integrate with an API for purging on changes and requiring manual configuration for what to cache an when we can accomplish everything using HTTP headers on the requests that travel back and forth between the edges and the origin:

1 - A HTTP header is added to requests going from the edge to the origin to advertise that there is an edge cache present and the capabilities it supports:

x-HTML-Edge-Cache: supports=cache|purgeall|bypass-cookies

2 - When the origin responds with a cacheable page it adds a HTTP header on the response to indicate that it should be cached and any rules for when the cached version shouldn’t be used (to allow for bypassing the cache for logged-in users):

x-HTML-Edge-Cache: cache,bypass-cookies=wp-|wordpress

In this case the HTML will be cached but any requests that have cookies that start with “wordpress” or “wp-” for the cookie name will bypass the cache and go to the origin.

3 - When a request modifies the site content (updating a post, changing a theme, adding a comment) the origin adds a HTTP response header indicating that the cache needs to be purged:

x-HTML-Edge-Cache: purgeall

The only tricky part to deal with is that the purge needs to clear the cache from ALL of the edges, not just the one edge that the request went through.

4 - When a new request comes in for HTML that is in the edge cache, the request cookies are checked against the rules for the cached response. If the cookies are not present then the cached version is served; otherwise, the request is passed through to the origin.

With this simple header-based command and control interface we can eliminate the need for an origin to talk to an API and for any explicit configuration. It also makes the logic on the origin significantly easier to implement as there is no configuration (or UI) and no need to make any outbound requests to a vendor-specific API. The example WordPress plugin is less than 50 lines of code and the vast majority of that is hooking up callbacks for all of the events that change content.

One of the things I love most about Workers is that it gives you a fully programmable edge to experiment with ideas and implement your own logic. I created a Worker script that implements the header-based protocol and edge caching on the Cloudflare edges and a WordPress plugin that implements the origin logic for WordPress.

The only tricky part with the Worker was finding a way to purge items from the cache globally. The Worker caches are local to each edge and don’t provide an interface for doing any global operations. One way it does it is to use the Cloudflare API to purge the global cache but that is a bit of a heavy hammer (purging everything from the cache including scripts and images) and it requires some configuration. If you know the specific URLs that will be changed by a content change then doing a targeted purge through the API for just those URLs would probably be the best solution.

Using the new Workers KV store we can purge the cache a different way. The Worker script uses a versioning scheme for the cache where every URL gets a version number appended to it (i.e. http://www.example.com/?cf_edge_cache_ver=32). The modified URL is only ever used locally by the worker as a key for the cached responses and the current version number is stored in KV which is a global store. When the cache is purged, the version number is incremented which changes the URL for all of the resources. Old entries will age out of the cache normally since they will no longer be accessed. It requires a little configuration to set up KV for the worker but hopefully at some point in the future that can also be automatic.

I think there is a huge value for the web in standardizing a way for edge caches and origins to communicate for caching of dynamic content. That would provide incentive for content management systems to build support directly into the platforms and provide a standard interface that could be used across different providers (and even for local edge caches in load balancers or other reverse proxies). After doing some more testing with different types of sites I’m planning to bring the concept to the IETF HTTP Working Group to see if we can come up with an official standard for the control headers (using different names). If you have opinions about how it should work or what features you’d need exposed I’d love to hear about it (like purging specific URLs, varying content for mobile/desktop or region, expanding it to cover all content types, etc).

We’ve had the tremendous pleasure of working with WP Engine for nearly 5 years, starting when both companies employed fewer than 100 people in total. From the beginning, we noticed striking similarities between our two companies—both were founded in 2010, both are incredibly passionate about their customers’ success, and both strive to make their technology as simple and accessible as possible. Fast forward to 2018: with WP Engine already leveraging Cloudflare for DNS, thousands of mutual WP Engine and Cloudflare customers, and millions of WordPress websites already protected behind Cloudflare, it was a no-brainer to formally partner together.

Today, we are thrilled to announce WP Engine as a Cloudflare partner! The joint offering, Global Edge Security powered by Cloudflare, integrates WP Engine’s platform with Cloudflare’s managed web application firewall (WAF), advanced distributed denial of service mitigation (DDoS), SSL/TLS encryption, and CDN across a global edge network to deliver the world’s most secure and scalable digital experience on WordPress today.

We couldn’t be more excited about our opportunity to collaborate with WP Engine to deploy business-critical security and CDN edge services to Enterprises and SMBs globally.

CC BY-SA 2.0 image by Nicola Sap De Mitri

The problem was found by the team at Sucuri and reported to WordPress. The WordPress team worked with WAF vendors, including Cloudflare, to roll out protection before the patch became available.

Earlier this week we rolled out two rules to protect against exploitation of this issue (both types mentioned in the Sucuri blog post). We have been monitoring the situation and have not observed any attempts to exploit this vulnerability before it was announced publicly.

Customers on a paid plan will find two rules in WAF, WP0025A and WP0025B, that protect unpatched WordPress sites from this vulnerability. If the Cloudflare WordPress ruleset is enabled then these rules are automatically turned on and blocking.

As we have in the past with other serious and critical vulnerabilities like Shellshock and previous issues with JetPack, we have enabled these two rules for our free customers as well.

Free customers who want full protection for their WordPress sites can upgrade to a paid plan and enable the Cloudflare WordPress ruleset in the WAF.

Install or upgrade to CloudFlare's new plugin to speed up your WordPress site.

Our new plugin adds all of CloudFlare's performance and security benefits in a simple one-click install of recommended settings specifically developed for WordPress.

One-click WordPress-optimized settings is the easiest way to setup CloudFlare for your WordPress site.

Web application firewall (WAF) rulesets, available on CloudFlare’s paid plans, has built-in rulesets, including rules that mitigate WordPress specific threats and vulnerabilities. These security rules are always kept up-to-date: once the WAF is enabled, you can rest easy knowing your site is protected from all the latest threats.

Automatic cache purge occurs when you change the appearance of your website. This means that you can focus on your website, while we ensure that the latest content is always available to your visitors.

You can also change CloudFlare settings such as the Security Level, Image Optimization, etc. from within the plugin itself without needing to navigate to the cloudflare.com dashboard, and view analytics such as total visitors, bandwidth saved, and threats blocked. In addition the plugin restores your visitors' original IP addresses in your WordPress logs.

Do I need a CloudFlare account to use the plugin?

Yes, on install and activation the plugin, first time users will be asked to enter their email address (used to sign-up for an account at cloudflare.com) and their user API key. This is needed to support all the features offered by the plugin.

How do I install the plugin?

A few clicks are all it takes to install the plugin from your WordPress admin dashboard.

What settings are applied when I click "Apply Default Settings" in CloudFlare's WordPress plugin?

You can review the recommended settings that are applied here.

Any more questions or feedback? We’d love to hear from you in the comments.

The vulnerability can easily be abused by a simple script to try a significant number of username and password combinations with a relatively small number of HTTP requests. The following diagram shows a 4-fold increase in login attempts to HTTP requests, but this can trivially be expanded to a thousand logins.

This form of brute force attack is harder to detect, since you won’t necessarily see a flood of requests. Fortunately, all CloudFlare paid customers have the option to enable a Web Application Firewall ruleset to stop this new attack method.

To understand the vulnerability, it’s important to understand the basics of the XML remote procedure protocol (XML-RPC).

XML-RPC uses XML encoding over HTTP to provide a remote procedure call protocol. It’s commonly used to execute various functions in a WordPress instance for APIs and other automated tasks. Requests that modify, manipulate, or view data using XML-RPC require user credentials with sufficient permissions.

Here is an example that requests a list of the user’s blogs:

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
 <param>
  <value>
   <string>admin</string>
  </value>
 </param>
 <param>
  <value>
   <string>password123</string>
  </value>
 </param>
</params>
</methodCall>

The server responds with an XML message containing the requested information. The isAdmin name-value pair tells us our credentials were correct:

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<params>
	<param>
	  <value>
	  <array><data>
	  <value><struct>
	  <member>
		<name>isAdmin</name>
		<value><boolean>1</boolean></value>
	  </member>
	  <member>
		<name>url</name>
		<value><string>http://example.com/</string></value>
	  </member>
	  <member>
		<name>blogid</name>
		<value><string>1</string></value>
	  </member>
	  <member>
		<name>blogName</name>
		<value><string>testing</string></value>
	  </member>
	  <member>
		<name>xmlrpc</name>
		<value><string>http://example.com/xmlrpc.php</string></value>
	  </member>
	  </struct></value>
	  </data></array>
	  </value>
	</param>
</params>
</methodResponse>

As shown in this request, you must provide proper authentication to get a successful response. You can, in theory, create a script that tries different combinations of the username and password, but that is a noisy option that isn’t very effective and is easily detected (the server logs would show a flood of failed login attempts).

This is where the system.multicall functionality comes into play. You can run multiple methods with a single HTTP request. This is useful for mass editing blogs or deleting large numbers of comments, etc. Any method that requires authentication can be abused to brute force credentials. Here is what a sample XML system.multicall payload would look like:

<?xml version="1.0"?>
<methodCall>
<methodName>system.multicall</methodName>
<params>
  <param><value><array><data>
  <value><struct>
  <member>
	<name>methodName</name>
	<value><string>wp.getUsersBlogs</string></value>
  </member>
  <member>
	<name>params</name><value><array><data>
	<value><array><data>
	<value><string>admin</string></value>
	<value><string>password</string></value>
	</data></array></value>
	</data></array></value>
  </member>
  </struct></value>
  <value><struct>
  <member>
	<name>methodName</name>
	<value><string>wp.getUsersBlogs</string></value>
  </member>
  <member>
	<name>params</name>
	<value><array><data>
	<value><array><data>
	  <value><string>admin</string></value>
	  <value><string>password</string></value>
	  </data></array></value>
	</data></array></value>
  </member>
  </struct></value>
  </data></array></value>
  </param>
</params>
</methodCall>

As you can see, this can lead to very obvious abuse.

During testing, I was able to call the method wp.getUserBlogs 1,000 times in a single HTTP request (limited only by PHP memory issues). If a user creates a simple shell loop that executes one thousand times and runs a PHP script that crafts an HTTP request with one thousand method calls all requiring authentication, then that user would be able to try one million unique logins in a very short period of time.

This makes brute forcing the login very fast and can run down a pretty large wordlist in a short period of time. Also note that the wp.getUserBlogs method isn’t the only RPC call requiring authentication. It’s possible to use any RPC method which requires authentication to attempt logins and brute force the Wordpress credentials.

When using CloudFlare with a Pro level plan or higher, you have the ability to turn on the Web Application Firewall (WAF) and take advantage of the new WordPress ruleset I created to mitigate this attack—all without any major interaction or supervision on your end.

Our WAF works by checking HTTP requests for consistencies that line up with known attacks and malicious activities. If a request does appear to be malicious, we drop it at the edge so it never even reaches the customer’s origin server.

To enable the rule, navigate to your CloudFlare Firewall dashboard, and reference the rule named "Blocks amplified brute force attempts to xmlrpc.php" with the rule ID WP0018.

That’s all there is to it. Now you are protected from the new WordPress XML-RPC brute force amplification attack.

Another way to mitigate this attack is by disabling the ability to call thesystem.multicall method in your Wordpress installation by editing yourfunctions.php file. Adding the function mmx_remove_xmlrpc_methods() will alleviate the problem, like so:

function mmx_remove_xmlrpc_methods( $methods ) {
	unset( $methods['system.multicall'] );
	return $methods;
}
add_filter( 'xmlrpc_methods', 'mmx_remove_xmlrpc_methods');

XML-RPC can be a useful tool for making changes to WordPress and other web applications; however, improper implementation of certain features can result in unintended consequences. Default-on methods like system.multicall and pingback.ping (we have a WAF rule for that one, too) are just a few examples of possible exploits.

Properly configuring the CloudFlare Web Application Firewall for your Internet facing properties will protect you from such attacks with no changes to your server configuration.

One attack that is particularly interesting because it appears to be using a brand new WordPress 0day.

The first sign we typically see that indicate a new phishing campaign is underway are the phishing emails themselves. Generally, there's a constant background noise from a few of these emails targeting individual customers every day. However, when a larger campaign starts up that trickle typically turns into a flood of similar messages.

Here's an example we've recently received:

Note — CloudFlare will never send you an email like this. If you see one like it, it is fake and should be reported to our abuse team by forwarding it to support@cloudflare.com.

In terms of the phishing campaign timeline, these emails aren’t the first event. Much like a spider looking to trap flies, a phisher first has to build a web to trap his or her victims. One way is through landing pages.

Looking like the legitimate login page of a target domain, these landing pages have one goal - to collect your credentials. Since these landing pages are quickly identified, the phisher will often go to great lengths to ensure that he or she can put up tens or even hundreds of pages during the lifetime of a campaign, all while being extra careful that these pages can't be traced back to him or her. Generally, this means compromising a large number of vulnerable websites in order to inject a phishing toolkit.

It's no surprise that first step in most phishing campaigns will usually be the mass compromise of a large number of vulnerable websites. This is why you will often see a notable uptick in the volume of phishing emails whenever a major vulnerability comes out for one of the popular CMS platforms. This is also why protecting the Internet’s back-office is a critical step in building a better Internet. If vulnerable CMS sites are protected, not only can they flourish, but the thousands of potential victims that could get abused when their infrastructure gets hijacked for malicious purposes are also protected.

This is why, at CloudFlare, we feel that providing free, basic security to every website is such important thing and why ultimately it could be such a game changer in building a better Internet.

Returning to our phishing attack, we see that it's no different. Analyzing the “load.cloudflare.com” hyperlink on the message, we see that it's actually a link pointing to a compromised WordPress site hosted by Bluehost.

Note: This is not a reflection on Bluehost, every hosting provider gets targeted at some point. What's more important is how those hosting providers subsequently respond to reports of compromised sites. In fact, Bluehost should be commended for the speed with which they responded to our requests and the way they handled the affected sites we reported.

Every other email in this particular campaign followed the same pattern. Here is the source for another one of those links that uses “activate.cloudflare.com”:

As you can see, while the message will display that you are going to “activate.cloudflare.com”, in reality, anyone that clicks on the link will be diverted to the victim website. Which, unsurprisingly, is running an old, vulnerable version of WordPress.

Every phishing email from this campaign has followed exactly the same pattern: a basic email template addressed to $customer informing them that their site has been locked, and inviting them to click on a link that takes them to a compromised WordPress site on Bluehost.

It looks like is this attacker harvested a large number of target domains using public DNS and email records identifying administrative email addresses. This became the victim list. The attacker then targeted a convenient, vulnerable CMS platform and injected his or her phishing kit into every innocent domain that's been compromised. Finally, once that is complete the attacker will send out the phishing emails to the victim list.

As phishing attacks go, this one is remarkably unsophisticated. All a savvy user had to do to reveal the true nature of this link is a quick mouse over. As soon as you do mouse over, the link you will see -- “activate.cloudflare.com” -- does not match the true destination.

A clever phisher could have used one of the many well known tricks to obfuscate the URL. Below are some of those techniques possible so you will know them if you see them.

• Image Maps. Instead of using a traditional hyperlink as above, phishers have been known to put an image map in their emails. The image, of course, is of a link to a trusted site such as “www.safesite.com”. When an unsuspecting user clicks within the coordinates of the image map, they are diverted to the phishing site.

Here's an example of this technique taken from an old eBay phishing email:

In order to fool Bayesian filters looking for phishing spam like this, the phisher also added some legitimate sounding words in white font to keep them from appearing. The user experience, however, is the same as the earlier phishing email. As soon as you mouse over the image map, you will see the true destination.

• Misspelled domain names and homoglyphs. Misspelled domains can look very similar to their legitimate counterparts and by using a homoglyph -- or look-a-like character -- an attacker can make a misspelling look even less obvious. Examples include “microsft.com” or “g00gle.com” These domains look so similar to the advertised link in the phishing email that many people will miss the discrepancy when they mouse over the link.

• Reflection, Redirection, and javascript. Many websites -- even sites like answers.usa.gov -- have search features, offsite links, or vulnerable pages that have historically been abused by phishers. If the offsite link can be manipulated, typically with a cross site scripting vulnerability, it's possible for the phisher to present a link from the target domain that takes the victim to a page under the Phisher’s control. Below is an example of a historic flaw of this nature that existed on the answers.usa.gov site

In this case, the URL looks like a legitimate “answers.usa.gov” ur,l but if you clicked on it, you would activate a cross-site scripting flaw that executes the javascript in your browser. The attacker could easily turn a page with this sort of flaw into a malicious credential harvester, all while continuing to use a link to the legitimate site.

Note - All those extra %20’s are encoded spaces to push the javascript far enough away that it won’t be visible on mouse over.

A slightly different flaw, also on the USA.gov site, involved its URL shortening service. Open to anyone, Phishers quickly discovered that they could use this service to create shortened URLs that looked important because of the .gov prefix. A victim that might be reluctant to click on an unsolicited bit.ly link might be less reluctant if faced with a .gov link. Here's an example of an email from a campaign abusing that service:

• URL obfuscation. Historically, this has been one of the most popular and varied techniques. The concept is simple: use any of the available URL encoding methods to disguise the true nature of the destination URL. I'll describe a couple of historic techniques below.

Note: many modern browsers now warn against some of these techniques.

First is username:password@url abuse. This notation, now deprecated because only an idiot would pass credentials in the HTTP query string these days, was designed to allow seamless access to password protected areas. Abuse is easy, for example:

www.safesite.com@www.evilsite.com

Next is IP address obfuscation. You are probably familiar with the IP address as a dotted quad? 123.123.123.123 Well, IP addresses can also be expressed in a number of other formats which browsers will accept. By combining this with the “username:password@” trick above, an attacker can effectively hide his true destination. Below are four different methods for presenting one of Google’s IP addresses -- 74.125.131.105

• http://www.safesite.com@74.125.131.105

• http://www.safesite.com@1249739625/

• http://www.safesite.com@0x4a.0x7d.0x83.0x69/

• http://www.safesite.com@0112.0175.0203.0151/

All of these URLs go to 74.125.131.150.

Finally we have Punycode and Homoglyph based obfuscation. Punycode was created as a way for international characters to map to valid characters for DNS, e.g., “café.com”. Using punycode this would be represented as xn--caf-dma.com. As mentioned at the start, homoglyphs are symbols which closely resemble other symbols, like 0 and O, or I and l.

By combining these two methods we can create URLs like:

www.safesite.com⁄login.html.evilsite.com

The secret to this obfuscated URL is to use a non-standard character which happens to be a homoglyph for /. The result? Instead of a page on safesite.com, you are actually taken to a subdomain of the following punycode domain:

www.safesite.xn--comlogin-g03d.html.evilsite.com

New obfuscation techniques like these appear all the time. Phishing is both the most common and arguably the most effective method of attack for medium to low skill attackers. Staying up to date with these techniques can be extremely useful when it comes to spotting potential phishing attempts.

After further analysis, it quickly became clear that all of the endpoints in this campaign were compromised WordPress sites running WordPress 4.0 - 4.1.1.

The most likely scenario is that a new critical vulnerability has surfaced in WordPress 4.1.1 and earlier. Given that 4.1.1 was, at the time of writing, the most current version of WordPress, this can only mean one thing -- a WordPress 0day in the wild.

Checking the WordPress site confirms that that a few hours ago they announced a new critical cross-site scripting vulnerability:

While we can’t confirm for certain that this is the vulnerability our phisher was using, it seems highly likely given the version numbers compromised.

Over the last few hours, we've worked closely with our friends at Bluehost to identify the remaining affected sites compromised by this phisher so they could take them offline. A quick response like this essentially renders all remaining phishing emails in this current campaign harmless. The need to quickly neutralize Phishing sites is why CloudFlare engineers developed our own process for rapidly identifying and tagging suspected compromised sites. When a site on our network is flagged as phishing site, we impose an interstitial page that serves to both to warn potential visitors and give the site owner time to fix the issue.

You can read more about our own process in this blog post.

By enabling the CloudFlare's WAF, CloudFlare customers have some protection against the sort of cross-site scripting vulnerability involved in this attack. However, anyone can still fall victim to a phishing email. Below are 7 tips to help you stay safe:

• NEVER click on links in unsolicited emails or advertisements.

• Be vigilant, poor spelling and strange URLs are dead giveaways.

• Mouse over the URL and see if it matches the what’s presented in the email.

• Type URLs in manually where possible.

• Stay up to date on your software and make sure you are running a current up-to-date antivirus client — yes, even if you're using Mac.

• It’s possible to set traps for phishers: use unique, specific email addresses for each account you set up. That way if you get an email to you Bank of America email address asking for your Capital One password, you immediately know it's a phishing attack.

• Finally, where possible enable two-factor authentication. While not foolproof, it makes it much harder for attackers.

As many are aware, CloudFlare launched Universal SSL several months ago. We saw lots of customers sign up and start using these new, free SSL certificates. For many customers that didn’t already have an SSL certificate, they were able to use “Flexible SSL”.

Flexible SSL creates a secure (HTTPS) connection between the website visitor and CloudFlare and then an in-secure (HTTP) connection between CloudFlare and the origin server. For any site using absolute links to assets (i.e. javascript, css, and image files), this can lead to a “Mixed Content” error.

What is “Mixed Content”? This can be understood as mixed protocol. When the webpage is loaded over SSL (HTTPS protocol), most browsers expect all of the assets to be loaded over the same protocol. Some browsers will display an error about loading “insecure content” while others will just block the insecure content outright.

This error only applies to pages loaded over SSL, since the browser is working to make sure that secure pages only load equally secure assets.

The latest version of the CloudFlare plugin for Wordpress works to resolve a lot of these errors by altering the protocol within the links to assets. Where currently your Wordpress site may link to your stylesheet like this:

http://www.example.com/wp/wp-content/themes/twentyfifteen/style.css?ver=4.1

We’ll remove the “http:” part to make this into a relative protocol:

//www.example.com/wp/wp-content/themes/twentyfifteen/style.css?ver=4.1

A further update to this rewriting doesn’t enable this rewriting for canonical URLs, since Google and other search engines expect this to be an absolute URL. Google also recommends securing your site with SSL, and being able to enable Flexible SSL is a great way to achieve this SEO boost!

A relative protocol //www.example.com tells your browser to load the asset over the same protocol as the main page. If your site loads over HTTPS, then the browser will try to load the asset over HTTPS as well. (In other words, NOT mixed. Everything is over HTTPS!)

This approach has no negative side effects for customers who don’t enable SSL (or who have traffic visit over HTTP as well as HTTPS), since if the page is loaded over HTTP, the assets will be loaded on the same protocol.

Protocol rewriting is on by default in our current version of the Wordpress plugin, so you should be able to enable Flexible SSL on your account and have traffic go to https://www.yourdomain.com.

CloudFlare recommends also adding a page rule for http://www.yourdomain.com* that redirects all traffic to HTTPS (assuming that Wordpress is set up for the WWW subdomain and isn’t within a directory on your domain).

With these two changes we can secure all traffic to your Wordpress site between the customer and CloudFlare’s server.

While this improvement should allow many Wordpress users to enable Flexible SSL without any other changes to their website, there are a few items to consider:

If after upgrading to the latest version of the Wordpress plugin, you still get “Mixed Content” errors, it’s likely that a plugin you are using adds assets to the site though javascript. The ways and methods to do this vary greatly, so it’s not currently possible to catch all of these instances. Plugin developers are encouraged to link to assets relatively or use Wordpress’s built-in methods for adding assets to the page.

It’s also important to note the limitation of Flexible SSL. For websites that collect credit cards and other secure information, it’s important to secure this information from the customer all the way to your server, so we recommend using Full SSL and having an SSL certificate on your server because this also secures the traffic between CloudFlare and your origin.

That's because CloudFlare pushes updates to these rules automatically when new vulnerabilities are found. If you enable the relevant ruleset for your technology then you'll be protected the moment new rules are published.

For example, here's a screenshot of the WAF Settings for a customer who uses WordPress (but doesn't use Joomla). If CloudFlare pushes rules to the WordPress set then they'll be protected automatically.

Enabling a ruleset is simple. Just click the ON/OFF button and make sure it's set to ON.

Here's a customer with the Drupal ruleset disabled. Clicking the ON/OFF button would enable that ruleset and provide protection from existing vulnerabilities and automatic protection if new rules are deployed.

For common problems we've rolled out protection across the board. For example, we rolled out Heartbleed protection and Shellshock automatically, but for technology-specific updates it's best to enable the appropriate ruleset in the WAF Settings.

Jetpack is an extremely popular plugin to provide self-hosted blogs with all of the additional functionality that WordPress provide to sites hosted with their own hosted platform at WordPress.com.

Very recently, a serious security flaw in Jetpack was discovered. It has the potential to allow an attacker to complete actions on a blog without having to log in, such as posting. The WordPress team has written about the the problem here.

This problem was assigned the CVE number CVE-2014-0173 and is fixed in Jetpack 2.9.3 released today. Everyone using Jetpack on their WordPress site should update immediately.

All CloudFlare customers who use WordPress are automatically protected against this bug. We rolled out a Web Application Firewall (WAF) rule that is automatically enabled for all customers (free or paid) to protect against this problem.

Customers using Jetpack should still upgrade immediately, but the WAF rule gives a little breathing space.

WordPress' ubiquity on the web can make it an ideal target for Layer 7 attacks, and its powerful features as a blogging platform can be demanding on small web and database servers, meaning Layer 7 attacks can be effective in making a WordPress server go offline using a relatively low number of requests.

Recently the folks at Sucuri observed a large DDoS using WordPress' pingback mechanism. A pingback is a way of one website telling another that it has linked to their content. We’ve seen this attack in the past and already had WAF rules in place to block it.

WordPress exposes an XMLRPC endpoint - xmlrpc.php - which other sites can make POST requests to in a standard format to inform a blog that their content has been linked to. The message it sends contains the blog link they referred to, and the page on which they placed that link.

When WordPress receives a pingback, it makes a request back to the source page to check that the link is actually there. Attackers can use this mechanism to specify a genuine link on a WordPress site and an intended victim, which will trigger a HTTP request to the victim's site. You can think of this as a kind of HTTP Reflection attack, in that the attacker can send a relatively small request to an XMLRPC endpoint that supports pingbacks, and trigger a much larger amount of effort and response on the victim's server.

Fortunately, our WordPress WAF rule WP0001 "WordPress Pingback Blocker" will immediately stop your WordPress blog from being used for this type of pingback abuse. If you run WordPress, you may want to consider enabling this today.

You can find the “CloudFlare WordPress” ruleset under the CloudFlare Settings > Security > Manage WAF section, toggle the switch to turn the CloudFlare Wordpress ruleset on, and you’re all set.

For an added sting in the tail, the attack Sucuri observed also used a mutating query string when specifying a URL on which they had placed a link. This bogus mutating URL will neutralise most caches and means a server has to expend the effort of producing a page from scratch over and over again. Fortunately we also have CloudFlare WordPress rule 100000 "WordPress Numbers Botnet" which will block this type of behaviour.

So whether your blog is used to attack others or to be attacked itself, our WAF can help. For more information on our WAF cloudflare.com/waf

The team at the research firm Sucuri announced a serious vulnerability to W3TC and WP Super Cache this afternoon. (Update: it appears the vulnerability was first reported on WordPress.org about a month ago.) The vulnerability allows remote PHP code to be executed locally on a server for anyone running either of the two most popular WordPress caching plugins. This is a serious vulnerability as it could allow an attacker to execute code on your server.

Here are the versions of each plugin that are vulnerable:

• W3 Total Cache (version 0.9.2.8 and below are vulnerable, version 0.9.2.9 and up are not vulnerable) / upgrade here

• WP Super Cache (version 1.2 and below are vulnerable, version 1.3.x and up are not vulnerable) / upgrade here

As a precaution, CloudFlare has applied a rule to our network which protects against this specific vulnerability in both plugins. The protection is applied for all CloudFlare accounts automatically, even free accounts. You do not need to do anything to enable the protection.

Even with this protection in place, if you are running either of these plugins you should upgrade immediately (W3TC Upgrade / WP Super Cache Upgrade). The vulnerability is serious enough that we recommend you disable the plugins until you have completed an upgrade. If you're not already a CloudFlare customer, you can signup for free to get protection immediately.

The attack takes advantage of several functions in these plugins including: mfunc, mclude, and dynamic-cached-content. An attacker can execute a PHP command running on the server by pasting a comment to a WordPress blog running a vulnerable version of W3 Total Cache or WP Super Cache. For example, if you are running a vulnerable version of the plugins, the following will result in your current PHP version being printed in the comment:

While this is harmless, the same mfunc call in either plugin can run other arbitrary commands on your server. This could be used to gain access to the server, execute arbitrary database commands, or remotely install malware. Again, this is a very severe vulnerability and all W3TC and W3 Super Cache users should upgrade immediately (W3TC Upgrade / WP Super Cache Upgrade).

There is currently a significant attack being launched at a large number of WordPress blogs across the Internet. The attacker is brute force attacking the WordPress administrative portals, using the username "admin" and trying thousands of passwords. It appears a botnet is being used to launch the attack and more than tens of thousands of unique IP addresses have been recorded attempting to hack WordPress installs.

One of the concerns of an attack like this is that the attacker is using a relatively weak botnet of home PCs in order to build a much larger botnet of beefy servers in preparation for a future attack. These larger machines can cause much more damage in DDoS attacks because the servers have large network connections and are capable of generating significant amounts of traffic. This is a similar tactic that was used to build the so-called itsoknoproblembro/Brobot botnet which, in the Fall of 2012, was behind the large attacks on US financial institutions.

We just pushed a rule out through CloudFlare's WAF that detects the signature of the attack and stops it. Rather than limiting this to only paying customers, CloudFlare is rolling it out the fix to all our customers automatically, including customers on our free plan. If you are a WordPress user and you are using CloudFlare, you are now protected from this latest brute force attack.

Because CloudFlare sits in front of a significant portion of web requests we have the opportunity to, literally, patch Internet vulnerabilities in realtime. We will be providing information about the attack back to partners who are interested in hardening their internal defenses for customers who are not yet on CloudFlare.

If you are running a WordPress blog and want to ensure you are protected from this attack, you can sign up for CloudFlare's free plan and the protection is automatic. We'll continue to monitor the details of the attack and publish details about what we learn.

There were two talks: I was preceded by designer Laura Kalbag who talked about designing icons for WordPress sites. This is something that she made look incredibly easy using a tool called Sketch. I suspect that however good Sketch is, I'd end up drawing icons that looked awful!

My talk was about using WordPress and CloudFlare together. CloudFlare has a ton of features and I highlighted some that are of great interest to WordPress users including the CloudFlare WordPress Plugin and our integration with W3TC.

The other features that people found most interesting were:

1. Always Online: CloudFlare crawls the WordPress site and keeps a copy in a special cache. If the original site goes down CloudFlare serves up the most recent version from the crawler cache with a banner indicating that it is old content. This helps keep sites online when things go badly wrong.

2. Auto-minify: many WordPress sites have large amount of HTML, CSS, and JavaScript (especially if they use lots of plugins). Auto-minify helps shrink those resources so that sites are delivered faster to web browsers.

3. Rocket Loader: a tool that reorganizes the loading of resources such as CSS and JavaScript to that they are downloaded to web browsers quickly by bundling them.

4. A new, unannounced feature that I'm calling "Help, I've gone viral!" which allows any web site owner to instantly tell CloudFlare to start completely caching a URL (overriding any caching headers set by the site) to cope with load. With this if a URL goes viral and is overloading a WordPress site it's possible to just paste in its URL and ask CloudFlare to take the load of that page. We'll be writing more about that feature when it's released.

And, of course, other CloudFlare features like Easy SSL, SPDY, and IPv6 help everyone get the latest technology onto their site quickly.

We get a lot of questions from our customers about CloudFlare and how we impact SEO. So when SEO.com signed up for CloudFlare, I thought it would be a great opportunity to talk to an expert to get the scoop on all things SEO. I was fortunate enough to connect with Derek Perkins, Vice President of Technology at SEO.com. With more than 12 years of industry experience, Derek provided his insight on SEO in general, debunked some of the myths out there, and gave us his take on what really works, and what doesn't, when it comes to SEO and your site.

DP - Step one - use WordPress and WordPress SEO. For most website owners, a Content Management System is key. The WordPress platform would be my first choice, you don't have to deal with structure of a Wordpress site to make sure it's easily searchable and findable. WordPress ranks high, especially if you activate WordPress SEO by Yoast. A combination of those two alone put you a long way ahead of where smaller business are. Correct structure is a good thing.

Step two - Focus on great content. Sporadic posting is never going to yield a tangible output. The more Google changes their algorithms, the more likely you will get ranked lower if you're not posting often. Just posting frequently however isn't enough. Content has always risen to the top of rankings, and as search engines mature, they are continuing to increase the signal to noise ratio. Posting great content regularly is the key to SEO success.

Step three - find good website hosting that will be elastic. Great content that gets picked up on TechCrunch, Digg, Reddit - any viral site - is going to see heavy spikes in traffic. If you're on a cheap hosting plan you often won't be able to scale to meet demands.

Actually, one of the first things I do is recommend CloudFlare. I love the CDN and scalability, it takes load off of the server so you don' have to worry so much about load spikes.

DP - A big misperception about SEO is the idea that you have to somehow change your writing or write things that are for search engines instead of humans. That's not the case. A lot of people also say you have to have unnaturally high keyword density and that's the only way you're going to rank. That's not good, it's harmful. Google sees that as if you're writing it specifically for SEO. Search engines try to read content as if they were human. If the content doesn't flow well or read well for a human, chances are it's not going to read well for a search engine or spider.

SEO is all about having good content. Write content you and others would like to read. It is more likely be shared socially, bringing more people to your site, and more people will link back to your site, growing your online presence.

When people think of SEO they tend to focus on the 10 percent that's the little tweaks that SEO companies can do for you, whereas the bulk of the value comes from writing good content.

DP - There are a number of places on the web that have good SEO forums. We have a link on our own site,www.SEO.com/forums, that links to a number of the best forums out there. Another great resource is SEOmoz, it's a great place for website owners to start.

DP - Number one thing that people don't do - they don't have any sort of targets. Content is king, but a lot of it is knowing what specificcontent is going to be most valuable to them. You can write about two different things that are both interesting, exciting and relevant to your audience, but one is relevant to maybe 10 searches a month, whereas one is relevant to 10,000 searches a month. Having an idea of what pages or blog posts or keywords you're targeting with each will help you tailor the content.

DP - Picking the wrong page titles and/or having a malformed HTML structure. There's a lot of SEO weight on title and header tags, you need to have your page title similar to whatever is in your H1 tag. A lot of site owners out there don't have header tags or have them set-up correctly. Even if they have a good title, the title might not be in the HTML header tag. The title and headers help both search engines and more importantly humans identify the focus of the page.

DP - I think SEO has a bit of a stigma because of old tactics that people used to use. You used to be able to immediately rank for SEO by using tricks like white text on a white background and various other tactics to gain the system. Even just recently Google has released things like Penguin, making it harder and harder to game the system. It changes how SEO agencies function, shifting the focus from link building to strategic content driven approaches. That has driven a proliferation of socially shareable content like infographics.

DP - Personally, I occasionally use Bing, but I tend to go back to Google. I took the test myself and Bing won 3 to 2, but I felt like the stripped down result pages weren't a perfect test.

DP - Bing has been gaining ground, Yahoo!'s results are powered by Microsoft, so Bing and Yahoo! will both show same results. The big two are definitely Google and Bing. You can't ignore Bing when you're tracking rankings, but they are definitely playing second fiddle to Google at this point.

For a long time Google has provided the best search rankings. Whether or not Bing has closed the gap on search, they have an uphill battle. People are used to Google, it's becoming part of the English language. I doubt that anyone outside of Microsoft headquarters has ever said "I don't know the answer, let me go Bing it."

I've been using CloudFlare for over a year now. I had a personal website calledsoccerreviews.com. I built it up to have significant traffic and I was really having server load issues, in addition to having been hacked twice. Because of that, security and scalability was very important to me.

I tried CloudFlare on that site and I now have it on 30 other sites. I have yet to have any of those sites compromised, which has been fantastic.

Once I joined SEO.com, I put us on CloudFlare. One feature I really like about CloudFlare is Rocket Loader. It combines all my javascript files and speeds them up, and they aren't all being downloaded separately, decreasing download time.

As for the impact to SEO, bounce rate plays a very important role in how Google does their rankings - they see that as a human factor in SEO. If someone immediately jumps back to Google, it's obviously not a good human source. A fast site that's always online is sure to help your rankings with lower bounce rates, and having CloudFlare helps to make this possible.