If you want to know the best mince pie to buy in 2018 right now, skip straight to the bottom of this post where we reveal the winner. If you want to understand more about what makes a mince pie great and how we can learn this at Cloudflare’s scale - read on.

With a very short amount of time to get this research out to a discerning and demanding public, we engaged the entire Cloudflare London team to help. Team members diligently went out and purchased mince pies from all over the South East of England for everyone to taste.

On Monday the team assembled for a “Mince Pie Jam”, where we would taste & consistently review each pie:

As we can see from even the most cursory Internet search, there are a lot of questions surrounding mince pies. After some confusion relating to our 2017 edition of the IMDB we should clearly state: modern mince pies do not contain meat. A Mince Pie is “a sweet pie of British origin, filled with a mixture of dried fruits and spices called mincemeat, that is traditionally served during the Christmas season in the English world.” - Wikipedia for Mince Pie

We reviewed the mince pies in terms of its characteristics as well as overall. Each mince pie was given a score of 1 to 10 for each of the following:

• Innovation

• Booziness

• Pastry to Filling Ratio

• Pastry

• Mince

• Overall rating

The top 3 categories there are somewhat objective measurements compared to the more subjective ones below. During analysis, this created some exciting opportunities.

With this combination of 3 subjective & 3 objective metrics and a total of 214 submitted reviews by our team, we had a lot of data. To break this data down Nela quickly settled on the Pearson Correlation Coefficient (PCC).

Wikipedia describes the PCC as follows:

The correlation coefficient ranges from −1 to 1. A value of 1 implies that a linear equation describes the relationship between X and Y perfectly, with all data points lying on a line for which Y increases as X increases. A value of −1 implies that all data points lie on a line for which Y decreases as X increases. A value of 0 implies that there is no linear correlation between the variables.

By setting our X Value as the Overall Rating, we were able to plug in each of the other metrics from our reviews as the Y value, to understand how important each of these characteristics are in producing a high quality result.

2018 Internet Mince pie Database evaluation criteria coefficient. Explore the full dataset

From this data we can conclude that satisfaction with a pie’s mince filling is the most likely criteria for overall pie satisfaction with r=.841, while innovation creates a negative correlation implying that traditional mince pies are favoured, and straying from this will only lead to dissatisfaction. Alcohol content had a minor positive correlation while pastry, pastry to filling ratio, and aesthetic had an average positive correlation.

Along with scores, our reviewers also left tasting notes which gave an insight into how they arrived at their scores. Taking the reviews which scored a mince pie from 1-5 we’re able to see the terms most associated with poorer performing pies:

Pies scoring between 6 and 10 points had the following terms used the most in tasting notes:

Before we get to the final overall rankings, there are a few categories we wanted to mention.

Unsurprisingly, some of the most expensive mince pies come from London’s fanciest Restaurants & Bakeries. The 3 most expensive mince pies did not rank highly enough to feature elsewhere - which goes to show you that money doesn’t necessarily buy you the best mince pie.

A Dickensian-styled thing of beauty, I expected a pie-seller to appear muttering "gawd blimey guv'nor thems good pies". Good bite, alcohol was raw and overly pungent, tasty but I needed a quiet lie down afterwards.

Deeelicious and moist. A little citrus and Christmas on the finish.

In a word, dense. Dense filling, dense pastry. A bit too heavy all round.

Below are the 3 lowest scoring mince pies in 2018. We publish this not to humiliate but in the hope that these bakers will learn & improve for 2019.

The 10 on "experimental" here means ... experiment gone badly wrong. If ratings allowed for complex numbers, this one would score an overall '10i'.

A bit dry and what on earth is all that air doing there?! Get out and put mince in!

BANG average from Aldi. I don't know where Holly Lane is but if I were to guess it would be firmly in the middle of somewhere. Slightly chalky, pasty pastry and sweet uninteresting mince.

Nela’s impressive Pearson Correlation work showed that there is actually a minor negative correlation with mince pies that are highly innovative. During tasting we observed that innovative pies drew people in but they most definitely divided opinion. Here are the 3 most innovative mince pies (as ranked by their innovation score).

Bad.

Interesting but this is not a mince pie.

Absolutely amazing taste however questionable as a mince pie. 😱😱😱😱

Here are 2018’s top mince pies as stringently tested by the Cloudflare mince pie QA engineers:

2018 Internet Mince pie Database Rankings. Explore the full dataset.

I tried it twice. Will probably try to grab another one. Even with 14 others in-between the first and the second sampling, my preference hasn't changed. To me this is the star of the show. Yum!

Tasty filling, with a solid pastry. A great all rounder, if a little sweet with extra filling peel and topped sugar on the pastry.

Iceland are a dark horse here - the mince here elevates the fairly pedestrian pastry - which is pale and a little bit chalky in texture. But that mince - full of complexity - there's a hint of banana in here despite there being no actual bananas. HOW DID THEY DO THIS? DELICIOUS.

Thanks to everyone at Cloudflare who took part in this extensive research. If you’re inspired by some of the questions answered in this blog post, and you like spiced fruit and intense pastry debates then Cloudflare is hiring in London and all over the world.

Happy Holidays!

Black Friday by Per-Olof Forsberg, license: CC BY 2.0

To try and answer this question, we took a look at anonymised samples of HTTP requests crossing our network. First of all, let’s look at total page views from across our global network from the last few weeks and see if we can spot Black Friday and Cyber Monday:

All page views

So this is total page views by day (UTC) from November 19 (a week before Cyber Monday) until Monday December 3. Other than follow-the-sun fluctuations in a repeating daily pattern, each whole day is pretty similar in shape and size compared to the last. Black Friday and Cyber Monday aren’t visible in overall traffic patterns.

We have a very diverse set of customers across 12 million domain names and not all of them are selling products or doing so directly online. To identify those websites that are, I used metadata from the wonderful HTTP Archive project to export a list of domains using Cloudflare that were also running ecommerce software.

Here are the page views for these ecommerce sites over the same time period:

Ecommerce page views

So we can see clearly that our ecommerce customers are seeing a big increase in page views on November 23 and 26. Black Friday and Cyber Monday are most certainly a thing. This year Black Friday was quite a bit busier than Cyber Monday - around 22% busier in terms of page views. If we compare the page views of each day to the week prior, we can see the changes clearly:

% page view change vs previous week

The uplift starts on Wednesday but really kicks in during Thanksgiving with an increase of more than 100% on Black Friday.

So we’ve established that these shopping days are important in terms of visitor activity. More pages are being viewed on these days - but is anyone buying anything?

We’re dealing with trillions of requests across a really large data set of different websites without any specific knowledge of what a purchase transaction would look like for each - so to approximate this I took a crude approach, which is to look for successful checkout interactions in the data. If you imagine a typical ecommerce application makes a purchase with a HTTP request like “POST /store/checkout HTTP/1.1” we can look for requests similar to this to understand the activity.

% of checkout interactions vs prior week

We can see here that Black Friday has an almost 200% increase in checkout interactions compared to the previous Friday.

Using this raw number of checkout interactions to compare with the page views we have something approximating a conversion %. This is not a true conversion figure - calculating a true conversion figure would require data that identifies individuals and detailed action tracking for each website. What we have is the total number of page views (HTTP requests that return HTML successfully) compared to the total number of POST requests to a checkout. This gives us a baseline to compare changes in “conversion” over these big November shopping days:

% of checkout interactions / page views vs prior week

Each bar on this chart represents the % change in checkout interactions as a proportion of page views compared to the same day the previous week. We can see this increased by 45% on Black Friday compared to the Friday before (boring old beige Friday November 16). The following Saturday was booming at 60% - because we’re dealing with time in UTC, a UTC Saturday actually includes Black Friday traffic for some parts of the world, the same can be said of Tuesday which contains overlap from Cyber Monday - we’ll break this down a bit later.

On Cyber Monday, the increase actually beats Black Friday, meaning page views lead to cart interactions 57% more often than the prior Monday (boring old vanilla Monday November 19), albeit from a lower number of transactions.

What we see here is just how much more browsing people do on mobiles today vs desktop, with mobile winning most days:

Page Views by Device Type

When it comes to checkout interactions though, we can see the situation is switched with visitors more likely to interact with the checkout on a desktop overall, but even more so on Black Friday (14% more likely) and Cyber Monday (20% more likely).

Checkout Interaction as % of Page Views

Let’s look at a specific region to understand more, starting with the US:

USA Page Views (PST)

We can see a more normal weekday pattern on the prior Thursday & Friday (15 & 16 Nov) whereby desktop page views eclipse mobile during the daytime while people are at their desks. In the evenings and weekends, mobile takes over. What we see from the 21st onward is evidence of people taking time off work and doing more with their mobile devices. Even on Thanksgiving, there is still a big rise in activity as people start gearing up for Friday’s deals or finding ways to avoid political discussion with relatives at home!

On Cyber Monday, traffic earlier in the day is lower as people return to work, however we are seeing heavy use of desktop devices. As the working day ends, mobile once again dominates. Things begin to settle back into a more regular pattern from Tuesday November 27 onwards.

Let's take a look at checkout interaction over the Black Friday to Cyber Monday weekend by device type.

USA Checkout Interaction % (PST)

Despite all of that mobile browsing activity, desktop devices are more commonly used for checkout actions. People seem to browse more on mobile, committing to buy more often with desktop, it may also just be that mobile users have more distractions both on the device and in the real world and are therefore less likely to complete a purchase. From personal experience, I also think the poor mobile optimisation of some sites’ checkout flows make desktop preferrable - and when customers are incentivised with discounts & deals, they are more likely to switch devices to complete a transaction if they hit an issue.

It might be obvious if you’re reading this from the UK, but despite the fact that Thanksgiving is not a holiday here, retailers have very much picked up the mantle from US retailers and seized the opportunity to drive sales over this weekend.

UK Page Views (UTC)

Page views to ecommerce websites on Cloudflare look very similar in shape to the US on Black Friday. However, mobile is more dominant in the UK, even during working hours. It’s worth noting one big difference here - Cyber Monday in the UK was only 22% up in terms of page views compared to the prior Monday - in the US the increase was more than 4x that.

UK Checkout Interaction as % of Page Views

When it comes to checkout, it also looks like UK visitors to ecommerce sites commit more with their mobile, but desktop is still more likely to lead to more conversion.

Taking Germany as another example, here’s how page views look:

Germany Page Views (CET)

Desktop use during typical working hours is much more pronounced in Germany. Black Friday and Cyber Monday show higher page views than a normal Friday / Monday but the difference is much smaller than regions such as the US & UK.

Black Friday is spreading internationally despite these still being normal working days for the rest of the world. Cyber Monday is also increasing ecommerce activity internationally but tends to be quieter than Black Friday. Overall, mobile browsing eclipses desktop, but those desktop page views tend to lead to checkout more often.

Retailers should continue to invest in making their mobile & desktop ecommerce experiences fast & resilient to seize on these key days.

Photo by SpaceX / Unsplash

We initially launched Rocket Loader as a beta in June 2011, to asynchronously load a website’s JavaScript to dramatically improve the page load time. Since then, hundreds of thousands of our customers have benefited from a one-click option to boost the speed of your content.

With this release, we’ve vastly improved and streamlined Rocket Loader so that it works in conjunction with mobile & desktop browsers to prioritise what matters most when loading a webpage: your content.

To put it very simplistically - load time is a measure of when the browser has finished loading the document (HTML) and all assets referenced by that document.

When you clicked to visit this blog post, did you wait for the spinning wheel on your browser tab to start reading this content? You probably didn’t, and neither do your visitors. We’re conditioned to start consuming content as soon as it appears. However the industry had been focused on the load event timing too much, ignoring user perception & behaviour. Data from Google analytics has shown that 53% of visits are abandoned if a mobile site takes longer than 3 seconds to load. This makes sense if you think about the last time you browsed onto a website in a hurry - if nothing is rendered quickly on screen you’re much more likely to go elsewhere.

Paint timing metrics are a closer approximation of how your users perceive speed. Put simply, paint timing measures when something is displayed on screen, and there are various stages of paint that can be measured & reported which we’ll explain as we go.

One of the ways in which you can learn more about your website’s performance is to use one of the many great synthetic analysis tools out there. The Lighthouse tool in Chrome can run a performance audit on your page simulating a typical mobile device & connection. I ran this on Cloudflare’s homepage to illustrate the way the page loads over time:

The First Meaningful Paint (FMP) takes 4.8 seconds on this mobile device simulation. FMP doesn’t measure the time of the first paint, but it waits for any web fonts to render and for the biggest above-the-fold layout change to happen. The red line drawn at 4.8 seconds shows our FMP in this test. So what can we do to improve?

Most tools will give you suggestions, and Lighthouse calls these opportunities and orders these by their estimated time saving:

Try running a lighthouse audit on your website and see what opportunities you get.

Now is a good time to quantify the spread of JavaScript on the web. Using the excellent HTTP Archive project we can review the make up of the Alexa top 500k websites over the years. Using their data, we can see that the median number of JavaScripts on mobile has increased from 5, at Rocket Loader’s launch in June 2011, increasing nearly four fold to a whopping 19 JavaScripts in May 2018. So most of us have plenty of JavaScript on our websites and there’s a good chance it will be very high on the list of performance opportunities you can seize to improve your visitors’ experience.

Implementing this recommendation would require you to make changes to your origin application’s code to asynchronously load, defer or inline your scripts. In some cases this might not be possible because you don’t control your application’s code or have the expertise to implement these strategies. Rocket Loader to the rescue!

Without Rocket Loader

With Rocket Loader

New Rocket Loader prioritises paint time by locating the JavaScripts inside your HTML page and hiding them from the browser temporarily during the page load. This allows the browser to continue parsing the rest of your HTML and begin discovering other assets such as CSS & images that are required to render your page. Once that has completed, Rocket Loader dynamically inserts the scripts back into the page and so the browser can load these.

This bit is quite labour-intensive, so watch closely:

Let’s run lighthouse again on our homepage now we have Rocket Loader enabled:

So Lighthouse has detected that First Meaningful Paint is just over 1.5 seconds faster in this test - a really impressive improvement delivered from a single click!

To drive this home, the opportunity lighthouse identified is now officially a “passed audit”:

To measure this with real users & devices, last week we ran a simple A/B test on www.cloudflare.com where 50% of page views were optimised using Rocket Loader so we could compare performance with and without it enabled. As shown by the lighthouse audits above, our main website is a great use-case for Rocket Loader because while we do use a lot of JavaScript for some interactive aspects of our pages, most important to our visitors is reading information about Cloudflare’s network, products & features. So in short, content should be prioritised over JavaScript.

To illustrate the changes we observed, below is a graph of the Time To First Contentful Paint (TTFCP) for www.cloudflare.com visits by real users during our test. TTFCP measures the first time something in the Document Object Model (DOM) is painted on the page. For websites that are primarily for consumption of content rather than heavy interactions, this is a closer representation of a user’s perception of your website speed than measuring load time.

With Rocket Loader you can see those orange bars are grouped more to the left (faster) and higher meaning many more of our visitors were getting content on screen in under a second. In fact, the median improvement delivered by Rocket Loader during our www.cloudflare.com test lands at a 0.93 second reduction in Time To First Contentful paint or around a 45% improvement over the baseline. Boom!

So Rocket Loader continues to drive performance improvements on JavaScript heavy websites, but lots has changed under the hood. Here is a summary of the key changes:

• Improves time to first paint speed not just load time

• Now compatible with over 93% of mobile devices[1]

• Tiny! Less than 10% of the size of prior version

• Reduced complexity & better compatibility with your on-site & 3rd party JavaScripts

• Compliant with stricter Content Security Policies (CSP)

We’ve already predicted that by the end of 2018 mobile usage will reach 60%. Additionally as of July 2018 Google will begin using page speed in mobile search ranking. With that in mind providing a fast experience for mobile devices is more important than ever.

Rocket Loader beta was first launched back in 2012 at a time when mobile device usage on the web was around 15%. That version of Rocket Loader intercepted JavaScript on the page, and executed it in a virtual sandbox: a world familiar, but with behavior changed behind the scenes. Unfortunately, the technique we chose to create this virtual sandbox didn't work well on all mobile browsers. That was considered an undesirable but acceptable trade off 6 years ago, but today it’s vital customers can leverage this technique on mobile. Thanks to the reduced complexity of our approach, new Rocket Loader works on over 93%[1:1] of mobile devices in use today. For those devices that are not compatible, we simply deliver the website normally without this optimisation.

New Rocket Loader’s JS weighs in at a lightweight 2.3KB. We did some extensive refactoring during 2017 that reduced the size of the JS required to run Rocket Loader from 47KB to 32KB and saved a staggering 213 terabytes of transfer across the globe. Due to the simplicity of the way New Rocket Loader works rocket-loader.min.js resulting in a JS file that is less than 10% of the size, saving approximately another 417 Terabytes of transfer each year when Rocket Loader does its thing.[2]

New Rocket Loader does not modify the content of your JavaScript, it only changes the time at which it is loaded which means it plays nicely with any Content Security Policy (CSP) you have defined. With Rocket Loader beta, if you wanted to set a CSP that only allowed execution scripts hosted on your domain you would need to disable Rocket Loader as that would also combine & load external JavaScripts through your domain. New Rocket Loader does not use this approach and instead lets the browser load & cache the files normally. As we also enable HTTP/2 for all of our customers, any first party scripts will load over a single TCP connection, and 3rd party scripts are still asynchronously loaded meaning we can optimise their loading without proxying this content. All of this means modifying your CSP to accommodate Rocket Loader is as simple as allowing script-src for https://ajax.cloudflare.com so that Rocket Loader itself can load.

If you already have Rocket Loader enabled as of today your site is using the new version. You can modify your settings at any time by visiting the Speed section of your Cloudflare settings.

If you had Rocket Loader disabled or in Manual mode just click the button in the Speed section to turn Rocket Loader on.

As always achieving good performance typically takes a variety of approaches and Rocket Loader tackles JavaScript specifically. There are some other very simple optimisations you should also ensure are enabled:

• Caching - cache everything you can so content is served directly from any one of our 150+ data centres without waiting for your origin.

• Minify & Compress - Enable minification of your HTML, CSS & JS in your Speed settings to losslessly reduce the total byte size of your web pages and enable Brotli compression so browsers that support this new compression method receive smaller responses.

• Optimise your images - Polish will automatically reduce the size of images on your website with support for highly efficient formats such as WebP. You can also turn on Mirage to optimise images for mobile devices with poor connectivity.

• Use HTTP/2 - You get HTTP/2 support automatically as long as your site is served over HTTPS. Move as much as your content as you can onto your Cloudflare enabled URLs so all of that content can be multiplexed down a single TCP connection.

• Use Argo & Railgun - For dynamic content Argo and Railgun can help optimise the connection & transfer between Cloudflare and your origin server.

1. Rocket Loader utilises a browser API called document.currentScript which is currently supported by 93.7% of mobile devices and growing: https://caniuse.com/#feat=document-currentscript ↩︎ ↩︎

2. Back of the envelope calculations based on 270 million rocket-loader.min.js responses served per week with a 29.7KB saving per serving. ↩︎

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