DEV Community: Damien Jubeau

Core Web Vitals: a new SEO factor focusing on website speed (LCP, FID and CLS)

Damien Jubeau — Tue, 09 Jun 2020 16:02:18 +0000

The Speed Report in the Google Search Console (recently renamed “Core Web Vitals”) is offering two new performance metrics: Cumulative Layout Shift and Largest Contentful Paint additionally to the First Input Delay. Core Web Vitals have also been deployed in tools such as Page Speed Insights or Lighthouse.

Google recently announced a major change to come: the search engine will release a new Page Experience signal for ranking in 2021, based on Core Web Vitals, with detailed objectives to comply with. Let’s discover about Core Web Vitals and the details of the Google’s announcement.

Page Experience: Google’s focus on UX and Speed

Firstly, let’s talk about the timeline: Google’s announcement was published on May 28, 2020. According to Google Webmaster Central Blog, the change won’t be in effect before 2021, and Google will provide a notice at least 6 months before rolling out the signal.

So if your website does not comply yet with the guidelines, the good news is you still have time to optimize your pages.

According to the documentation about the new “page experience”:

Page experience is a set of signals that measure how users perceive the experience of interacting with a web page beyond its pure information value.

HTTPs usage, Mobile Friendly, Interstitials and Safe Browsing were already documented Search signals. The news is more about the introduction of Core Web Vitals.

Core Web Vitals is a set of performance metrics that measure real-world user experience for loading performance (LCP: Largest Contentful Paint), interactivity (FID: First Input Delay), and visual stability of the page (CLS: Cumulative Layout Shift).

Core Web Vitals: LCP, FID and CLS

Largest Contentful Paint (LCP) – Loading performance

The Largest Contentful Paint measures the render time of the largest content element visible (within the viewport, so before the user scrolls).

According to Google guidelines, your web pages should have a LCP under 2.5 seconds, for 75% of your visitors at least (including both desktop and mobile traffic).

You can measure and monitor this metric with Dareboost, read our documentation to know more about Largest Contentful Paint.

First Input Delay (FID) – Interactivity

First Input Delay (FID) is the delay a user experiences when interacting with the page for the first time (example: delay to get a feedback from the page when clicking an element)

According to Google guidelines, your web pages should have a FID under 100ms, for 75% of your visitors at least (including both desktop and mobile traffic).

You can measure and monitor Max Potential FID with Dareboost, read our documentation to know more about Max Potential FID.

Total Blocking Time as an Alternative to FID

By definition, to collect the FID, you need an interaction. So you can’t measure FID without a real user interacting with the page. You can collect the Max Potential FID, that is the maximum theoretical value the FID could have whatever is the moment of the interaction.

Synthetic Monitoring tools like Dareboost are collecting Max Potential FID, but to get your exact FID results, you need to collect them on your audience (Search Console and Chrome UX Reports are a good start).

Max Potential FID is the worst case scenario. Google suggests to use Total Blocking Time (also available on Dareboost) as an alternative to FID.

Cumulative Layout Shift (CLS) – Visual Stability

CLS measures the total sum of all individual layout shifts that occurs during the entire lifespan of the page (including after the user has started to interact with the page), taking into account the size of the concerned area, and the distance of the shift. Expected Layout Shift (shifts following a user interaction by less than 500ms) are not counted.

According to Google guidelines, your web pages should have a CLS under 0.1, for 75% of your visitors at least (including both desktop and mobile traffic).

Cumulative Layout Shift will be available soon on Dareboost. Feel free to get in touch if you are interested by the metric.

Search Console: Core Web Vitals replaced Speed Report

In November 2019, the Speed Report was officially released in the Search Console, offering 2 performance metrics: First Contentful Paint and First Input Delay.

The “Speed Report” of the Search Console, now named “Core Web Vitals”, is based on Chrome UX Report (collecting performance and usage data of real Chrome users).

FCP have been abandoned and replaced by CLS and LCP with the Core Web Vitals report release. Another – and maybe subtler change: FID value is no more the 95th percentile but the 75th one, thus reflecting the guideline to have 75% of the traffic with a FID under 100ms.

Cumulative Layout Shift was collected (with an “experimental” flag) since May 2019 in the Chrome UX Report. Largest ContentFul Paint has been introduced in September 2019.

As we wrote in November 2019:

“These are some strong signs that we may expect some changes in the future from the Speed Report, with probably some metrics added to the current ones (or replacing them?).“

Seems like we were right about this! And we would not be surprised to see other changes before Page Experience release.

Also, we have to point out that FID, LCP and CLS may not be of equal interest in the Page Experience signal. At least, that’s the case from Lighthouse point of view.

At the end of 2019, Lighthouse v6 was already announced and LCP was to be introduced. CLS future usage was also mentioned, but without any precision. Lighthouse v6 is now released and includes CLS. Still, the metric is not a big part of the performance score, only 5% whereas LCP counts as 25%.

Page Experience: a stronger change than the Speed Update

For the first time, Google is not only promoting speed and announcing performance as a ranking signal but also defining precise metrics (First Input Delay, Largest Contentful Paint and Cumulative Layout Shift), detailed targets (FID < 100 ms, LCP < 2.5 seconds and CLS < 0.1) and a context/methodology (measured on Chrome on your real audience, at least 75% of your trafic should have a fast experience, whatever is their context – mobile or desktop).

In the very same announcement, Google also states that Top Stories feature will no longer require AMP :

“When we roll out the page experience ranking update, we will also update the eligibility criteria for the Top Stories experience. AMP will no longer be necessary for stories to be featured in Top Stories on mobile; it will be open to any page. Alongside this change, page experience will become a ranking factor in Top Stories, in addition to the many factors assessed.“

The fact that both topics are announced together is very interesting.

We already wrote about Top Stories being limited to AMP to be symptomatic of Google not having relevant way to asses speed at scale.

“It’s difficult to determine for sure whether a website is slow or fast, because you need to take into account a lot of params. […] Highlighting AMP, Google actually simplifies the equation: websites using it are considered fast, so they are promoted. Then there’s the rest of the world…”

Opening Top Stories to non-AMP page might be meaningful about Google’s confidence on Core Web Vitals.

Contrary to the Speed Update (2018) that has not been a gamechanger, keep in mind that the Page Experience signal and Web Core Vitals defines precise targets and methodology.

According to another piece of Google’s documentation :

“Core Web Vitals [… ] should be measured by all site owners”.

Take your Performance to the Next Level with Dareboost

Search Console Speed Report: everything you need to know

Damien Jubeau — Mon, 25 Nov 2019 12:18:58 +0000

This article was originally seen on Dareboost's blog.

One year after the Speed Update has been released, Google has launched a brand new Speed Report within the Search Console. The Speed Report is using the Chrome UX Report data to highlight the slow pages of your website. Let’s discover how to use the Search Console Speed Report and how to interpret the related performance metrics (FID and FCP). As a conclusion, we’ll focus on speed as a ranking signal and the further changes we might expect within the Speed Report.

Search Console Speed Report, a direct access to Chrome UX Report (CrUX) data for your domain

Accessing your Google Search console, you may have noticed a new item in the menu, the Speed report (within the Enhancements sub-menu):

From the homescreen of the Speed report, you’ll have a quick overview of the evolution of your site speed, segmented by device type (Mobile vs Desktop). To be more specific, the charts are showing the number of pages Google is considering slow, with a “moderate” speed, or fast through time.

You may be surprised by a significantly lower number of URLs here than on your Coverage report. It makes sense, we'll get back to it shortly.
The tool is advertising the data source of the Speed Report: the Chrome UX Report. We have already written about the Chrome UX Report (CrUX) on our blog, as it was already used by Google PageSpeed Insights.

Chrome UX Report (CrUX) is forged from data collected via Chrome, directly from its users browsing the web. So the data from the Speed Report are the performance data from your very own traffic, at least a part of your traffic using Chrome as a web browser.
Unfortunately, that means you need enough Chrome traffic on your web pages to ensure that you have data available in your Speed Report. That may explain the previously mentioned difference in URLs count between the Speed report and the reality of your website.

For small websites, not having enough data in Chrome UX Report for any page, all you will get is a warning message:

Hopefully, you’ll have enough traffic to get some data and you’ll then be able to access a detailed report for both Mobile and Desktop segments.

Once you have selected the report for a given device type, you can note that Google is considering both “Slow” and “Moderate” pages as being an issue. The report is very similar to what you’re already used to with the Mobile Usability report for example.

The tool is giving you the number of URLs that are related to a same issuer (that are not considered fast enough by Google).

When clicking an issue, you’ll be provided with a list of URLs. Each URL is a sample of a group of URLs sharing speed status, metric type, and similar URL type (performance issues in similar pages is probably due to the same underlying problem as stated per the documentation. Still, the grouping mechanism based on URL patterns may not be a good fit depending on your website).

You can access a sample of 20 URLs for a group, but the full list is not available.

Google is focusing on 2 performance metrics to gauge the speed of the page.

First Contentful Paint (FCP) and First Input Delay (FID)

You might already be familiar with these metrics, as Google is already highlighting them in PageSpeed Insights.
In a few words:

First Contentful Paint is the delay before the page starts to render some content (text or image). We have dedicated a previous post to FCP if you want to know more.
First Input Delay is the delay required for the browser to respond a the first user interaction (clicks, taps, or key presses) on the page. When your website is using Javascript, it may result in a janky experience for the user, due to the browser not being able to promptly respond to a user interaction. That’s what the First Input Delay is measuring, for the first click of the user.

For each group of pages, the Aggregate value of the metric is provided.

Aggregate FCP is the time it takes for 75% of the visits to a URL in this group to reach FCP.
Aggregate FID is the time it takes for 95% of the visits to a URL in this group to respond to the first user interaction on that page.

More precisely, it’s the 75th (or 95th) percentile of the metric:

if you have an Aggregate FCP of 1.2 seconds, it means 75% of your visitors experience a FCP faster than 1.2 seconds for the related pages (75th percentile).
if you have an Aggregate FID of 150 milliseconds, it means 95% of your visitors experience FID faster than 150 milliseconds for the related pages.

To allocate a status to a page, Google is using the following thresholds:

	Fast	Moderate	Slow
FCP	<1s	<3s	>=3s
FID	<100ms	<300ms	>=300ms

(from the Speed Report Documentation)

Note that targets are the same for both Mobile and Desktop devices!

If a page has two different status for the two metrics, the most defavorable status takes precedence. An an example, a page with a “Fast” FCP but a “Slow” FID will be considered “Slow”.

Resulting status of the page according to its FCP et FID statuses:

FID \ FCP	Fast	Moderate	Slow
Fast	Fast	Moderate	Slow
Moderate	Moderate	Moderate	Slow
Slow	Slow	Slow	Slow

Please note that you don’t have any information about the distribution of the user experience from an Aggregate metric.

Let’s take again the example of an Aggregate FID of 150 milliseconds (95th percentile). The 2 following distribution charts are compatible with this same Aggregate FID value:

To conclude on the subject of aggregated values, please keep in mind that:

95% of fast sessions are required for FID to get the Fast status, but only 75% for FCP
this selection is totally hiding the results for your visitors with the worst experience (the 5 slowest % for FID, and the 25 slowest % for FCP).
the aggregate says nothing about how the performance results are distributed in the given percentile. You can have a 75th percentile of 10 seconds and 74.9% under 1 second (in theory, the example is a bit extreme!).

Another limitation to be noted when reading those data: it’s collected from your website’s traffic (Chrome only), and your visitors are not equals. You only have 2 segments available, Desktop and Mobile, whereas your visitors are using hundred of devices, different connection types, some have already visited your pages and some are not, their browsing contexts are different (some would experience ads and retargeting, others may block them),etc. Still, all of their performance data are mixed together in the Speed Report.

Thus, some pages that are technically identical can show very different results from the Speed Report perspective, just because they have a different audience (for example, your top blog post having a wide international traffic compared to your other pages. As this audience may include countries with slower infrastructure or devices, the page will probably be shown as slower, meaning the overall experience for this page is slower, even if the page itself is not slower than others).

If you’re familiar with Web Performance, keep in mind that Speed Report has the exact same limitation that the ones you can face using a Real Using Monitoring tools.

Frequently Asked Questions about Speed Report

Why my website doesn’t have Fast pages?

Some could be disappointed by getting Fast results for a page on PageSpeed Insights but having the same Page being tagged as Slow or Moderated in the Speed Report.

Remember that, for page page to be Fast in the Speed Report, you should have 75% of experienced FCP unders 1 second AND 95% of FID under 100 milliseconds.
You have to meet both conditions, whatever the typology of your traffic is.

As you can see from this PageSpeed Insights report, testing https://www.google.com shows they do not meet the criteria either, even if the bars are mostly green:

How can I check the status of a specific URL?

You can’t, except being lucky and the URL being used as a sample for a group. As per the documentation of the tool: “The report is not designed find the status of a specific URL”. However, you can use PageSpeed Insights to do so.

How can I know if I’m fast enough for my market?

Check your competition.
Speed Report is using data from CrUX to give you insights about your slow web pages.
You can access your competition data as well by using PageSpeed Insight (or BigQuery if you’re not afraid to compose your queries https://web.dev/chrome-ux-report-bigquery/).

Dareboost is offering a dedicated tool to compare your website with your competitors.

I’ve optimized my website, why is the Speed Report not showing the improvements?

The new Search console is generally providing very fresh data. It’s a bit different for the Speed Report, as the performance data as extracted from a one-month rolling period of time (not totally confirmed).

Monitoring your website performance to facilitate your reporting and to make sure you’re alerted when there is a slowdown is our job at Dareboost, discover our monitoring features.

Why does the Speed Report show URLs from my subdomains?

Select carefully the “property” from the Search Console you want to get the data for. For example, using a “domain” property, you’ll also get the data for the subdomains sharing the same origin (ie: selecting “dareboost.com” property, we would get “blog.dareboost.com” as well as “www.dareboost.com” related data.

Slow pages in the Speed Report, a red flag for your ranking?

Knowing about the Speed Update like we do, you’re probably very interested in the new Search Console Speed Report. A new step from Google to highlight Speed as a ranking factor or to prepare a strengthening of the factor? Still the definition of what would be a Speed ranking factor is still opaque.

According to John Mueller and Martin Splitt’s video, Site Speed: What SEOs Need to Know Google is both using Lab’s Data (synthetic monitoring) and a data source “similar to the Chrome User Experience report data”, and is not focusing on a particular threshold, just roughly categorizing pages...

Here’s the transcription of this part the video:

Basically we are categorizing pages more or less as like really good and pretty bad. So there's not really like a threshold in between it's just like we are more or less roughly categorizing the speed experience for users.
And how are we actually doing that ? where do we get the data from ?
We mostly get data from two places on the one hand we try to calculate a theoretical speed of a page using lab data, and then we also use real field data from users who've actually tried to use those pages. And that field data is similar to the Chrome User Experience report data
So we are having like hypothetical data and practical data so we don't really have a threshold to give away but basically the recommendation I would say is just make sites fast for users.

Screenshot from the Speed Report documentationSo definitely, keeping an eye on your Speed Report sounds like a good idea.

Among the other news from Google this month, an announcement about Chrome: Moving towards a faster web. You may have read some titles in the SEO news Brace Yourself: Chrome Is About to Shame Slow Websites with a Dedicated Loading Screen! Reading the article article carefully, we don’t see more than a declaration of intent to dig about this idea.

Let’s discover in the next months if the Chrome Team will conduct such an experiment and hopefully communicate about how they asses that a page load is usually slow (in a given context?)

New Metrics and features to be expected in the Speed Report

During their talk “Speed tooling evolutions: 2019 and beyond” at Chrome Dev Summit 2019, Paul Irish and Elizabeth Sweeny from the Google Chrome Web Platform explained that some new metrics will gain focus : Largest Contentful Paint (LCP) , Total Blocking Time (TBT), and Cumulative Layout Shift (CLS).

Lighthouse version 6 (to be released on January 2020) will use LCP and TBT metrics to compute its new Performance score. CLS has been mentioned to be also used is the future.

If you’re as curious as we are and explore the CrUX data using Bigquery, you’ll note that cumulative_layout_shift is collected (with an “experimental” flag) since May 2019. Largest ContentFul Paint has been introduced in September.

This are some strong signs that we may expect some changes in the future from the Speed Report, with probably some metrics added to the current ones (or replacing them?).

We guess that the Speed Report will progressively be improved with some additional features to explore data by connection type or by country - as already offered by TestMySite, etc. to allow a better understanding of Web Performance in different contexts.

Take your Performance to the Next Level with Dareboost

At Dareboost, we provide comprehensive tools to manage easily and efficiently Web Performance. Discover Dareboost features.

Lighthouse: a powerful tool included in Chrome and DevTools

Damien Jubeau — Mon, 30 Jul 2018 11:51:16 +0000

This article was originally seen on Dareboost's blog.

Released in 2016 as a Chrome extension, Lighthouse is now also available directly in Chrome DevTools, via the "Audits" tab. Lighthouse is a great resource for developers interested in web performance and quality.

Lighthouse, a quick overview

Auditing a web page with Lighthouse is very simple if you are familiar with the Chrome DevTools. Browse to the page with Chrome, open DevTools (Ctrl+Shift+i or ⌥+⌘+i depending on your system) and then go to the "Audits" section.

Clicking "Perform an audit" will then allow you to configure the level of the audit according to your interests (Performance, SEO, Accessibility, etc.).

You will be able to see the page loading and reloading, and after a while, a new window will display your audit report.

If your version of Chrome is less than 69 (the current version at the time of writing this article is 67), this manipulation will trigger Lighthouse 2. You can use the Lighthouse extension available on the Chrome Store to test with Lighthouse 3. During this test, we used the extension. What follows, therefore, refers to Lighthouse 3.

NB: During our test using Lighthouse 3.0.0-beta.0, the screenshots were not fitting the expected viewport, probably affecting the Speed Index computation.

When Lighthouse has completed the evaluation of your page, you’re provided with an audit report, that begins by several scores (as many scores as categories chosen during the audit configuration).

The Performance Score is computed from your speed test results, comparing your website speed against others. Getting a 100 score means that the tested webpage is faster than 98% or more of web pages. A score of 50 means the page is faster than 75% of the web. [Source]

Other scores are depending on the compliance of the page against related best practices (you may note a "Best Practices" category: the name is kind of misleading as other categories are also offering some best practices, "Miscellaneous" may have been a better fit).

In our example, a question mark is displayed instead of a score. You can get this behavior when some related tests have not been conducted properly and are marked as "Error!".

After the scores overview, you’ll find the performance results for 6 metrics, and tooltips are available for a quick explanation:

First ContentFul Paint: First contentful paint marks the time at which the first text/image is painted.
First Meaningful Paint: First Meaningful Paint measures when the primary content of a page is visible.
Speed Index: Speed Index shows how quickly the contents of a page are visibly populated.
First CPU Idle: First CPU Idle marks the first time at which the page's main thread is quiet enough to handle input.
Time to Interactive: Interactive marks the time at which the page is fully interactive.
Estimated Input Latency: the score above is an estimate of how long your app takes to respond to user input, in milliseconds, during the busiest 5s window of page load. If your latency is higher than 50 ms, users may perceive your app as laggy.

Please note than some of those metrics are still at a very early stage. For example, as stated in its initial specification: First Meaningful Paint [..] matches user-perceived first meaningful paint in 77% of 198 pages. Collected metrics have significantly changed between Lighthouse V2 and V3. We will detail this in our next article. Still, if you’re eager to know, you can check the update announcement.

In the report, you’ll next find a filmstrip: step by step images of the page loading. That’s particularly useful to make sure the page has loaded as expected. For example, during our benchmark, we got a report with discrepancies. We have been able to confirm something went wrong thanks to the filmstrip:

Unfortunately, we were not able to find out more about what went wrong. One may regret the lack of details when using Lighthouse for complex work. Without an access to the page load waterfall, you cannot figure out more deeply what happened here.

After the performance overview, you’ll be provided with the best practices for each category. Most of the tips are very technical and not extensively detailed in the report itself, but you’ll find very valuable resources under the "Learn more" links.

What makes Lighthouse a great audit tool is also the number of automated controls: about a hundred. Lighthouse also highlights some "Additional items to manually check" that will be precious reminders (for instance in the accessibility category "The page has a logical tab order").

Note that some best practices are duplicated within several categories, for example, the control related to mixed content is present in the "Progressive Web App" category as well as in "Best Practices".

With Great Power Comes Great Responsibilities

Lighthouse is definitely a great resource, for both performance metrics and quality controls it can provide, always on hand as it’s available directly in Chrome.
This last advantage may also be your worst enemy!
When conducting the performance test from your desktop computer, you’re relying on a lot of parameters from your local environment and it can be difficult to get stable enough results:

Internet connection: are you sure you don’t have any background application consuming some bandwidth? If you’re sharing the connection with others, are you sure nobody is paraziting your tests? If your Internet Service Provider offering a connection stable enough?
CPU: are you sure your other computer usages are not affecting your running test?
Chrome extensions: as pointed out by Aymen Loukil they can deeply affect your results. Be particularly careful about extensions related to ad blocking!
User state: are you sure that your Lighouse test is starting with a clean state? What about your cookies, the state of your Local Storage, the open sockets (you can check on chrome://net-internals/#sockets), etc.
Lighthouse version: Lighthouse may have been updated since your last report, have you checked the changelog? Beware that the extension is auto-updating by default, and the version available through DevTools will be updated when updating Chrome.

The first two points are handled by the latest Lighthouse version (3.0), and a new mode "Simulate throttling for performance audits (faster)". Rather than relying on Chrome DevTools for traffic shaping, Lighthouse is now using a new internal auditing engine: Lantern. It aims to reduce performance metrics variability without losing too much accuracy. The approach is very interesting. For further details a public overview as well as a detailed analysis are available. Let’s see in the future how reliable it can be at scale!
Whatever the Lighthouse version you’re using, keep in mind the impact of your local environment and conditions.

Dareboost, as a synthetic monitoring solution is particularly aware of these stakes. For every single test on Dareboost, we’re creating a new clean Chrome user profile and opening a new Chrome instance. Each of our test regions are using the exact same infrastructure and network conditions. We do not parallelize tests on our virtual machines to avoid any interdependencies or bottlenecks.

If you’re not convinced yet that a dedicated environment is required to run your performance tests, we have run a small experiment.

We have conducted 3 Lighthouse audits on Apache.org from our office (fiber connection - average ping value to Apache.org is 40ms). Here are the median values of Lighthouse results:

Performance Score	First Contentful Paint	Speed Index	Time to Interactive
85	1690	1730	5380

Same exercise, but throtthling our connection to add 500ms latency (using tc Unix command):

Performance Score	First Contentful Paint	Speed Index	Time to Interactive
67	2780	3880	7320

We’re getting a 21% variation on Performance Score while the Speed Index has more than doubled with the second context. And we’re getting those results using Lantern mode (emulated Lighthouse throttling) that actually aims to mitigate local network variability.

Your own network latency is hopefully not varying this much. But keep in mind that the latency is only one of a lot of variable parameters in your local environment!

For temporary needs, Dareboost offers a free version to benefit from a stable and reliable environment, with up to 5 performance test per month. Give it a try!

When using Lighthouse, if you wish to compare several reports, keep in mind the volatility of your context and related bias!

Some extra Pro tips

Lighthouse is an Open Source project available on a Github repository. You can dig into the code to know more and the bug tracker will be handful.
The tool is also executable with a command-line interface.
You can explore Lighthouse results at the scale of the web by using HTTP Archive collecting data on thousands of pages.
If you’re using Lighthouse v2 (throttled connection rather than the Lantern emulation), keep in mind you’re using Chrome DevTools traffic shaping ability. Latency is injected at HTTP level, unlike Dareboost or WebPageTest that inject it at TCP level. As a result, Chrome DevTools is not adding latency during TCP connection neither SSL handshakes.

To conclude, Lighthouse is a useful and promising tool. Like the two other Google tools previously tested, it could give clues about Google’s strategy with the Speed Update.

Load time is out!

Damien Jubeau — Fri, 24 Nov 2017 15:41:33 +0000

This article was originally seen on Dareboost's blog.

Web agencies and their customers, managers and technical teams, are discussing and debating about load time without always understanding each others.
Whereas websites loading speed is an undeniable and strategic matter that every person involved within a web project should consider, relevant and consistent indicators for web performance have to be selected first. You can only improve what you measure and this measurement has to be reliable.

“Load time” just don’t exist!

That controversial titling highlights a reality: load time is an general concept, often used without designating one precise indicator! As a matter of facts, several tools talk about load time whereas their definition may greatly vary from one to another:

The average Page Load Time provided by Google Analytics (available through Behavior > Site Speed menu) actually measures the time until the onload event is fired.
Pingdom also coins a “load time” which is equivalent to the onload event firing. But, this indicator is used as a Fully Loaded Time within their waterfall, causing some rendering issues. To figure it out, we had to check the downloadable HAR file.
Test My Site (Think with Google) in fact provides a Speed index measure. Something you can discover via a tooltip. As we’ll see later, using Speed Index is a good thing. But naming it “load time” is misleading. At last, this tool gives very few information about the testing context (which location? What kind of 3G connection?).

One more example with Alexa’s tool, giving the current definition:

The load time of an individual page is how long it takes for the DOM – the structure of the page – to be loaded. This time doesn’t include the time to load all images and stylesheets, for example. Alexa.com

By excluding the images (more than 50% of the total weight of the web pages nowadays according to HTTP Archive) and also stylesheets (whose loading is blocking the visual rendering), Alexa is very far from measuring user’s experience!

Even if we should question the value of such an indicator, we have to acknowledge the transparency of the tool, giving a definition for the provided indicator.

Nevertheless, as a lot of tools do, Alexa fails while giving no information about measuring context: with a robot or a real browser? What kind of connection? From which location? All of these parameters are critical ones though, as they strongly impact the measured values. Without any of these information, we can’t rely on them as they may lack of constancy over time!

You’d rather use tools that clearly mention their testing methodology (which metrics are gathered and how they are measured). Doing so, you will avoid bias, misinterpretations and groundless debates.

Time until the end of loading

You will also find a load time indicator on Dareboost. Yes, you read it! Still, we are not schizophrenic. Indeed, we measure the Fully Loaded time (one indicator you may find on some other tools).

A few words about our measuring methodology: Dareboost requests the web page and then listens to the network activity. Our web browser (Chrome) waits for a significant interruption of the network traffic before considering the web page to be fully loaded. Do not hesitate to browse our documentation for more details: Web Performance Testing > Load time / Fully loaded

Fully Loaded Time and User Experience

Can we consider, though, the fully loaded time as a relevant indicator to evaluate user experience related to a webpage’s performance? One single example will be enough to blow this hypothesis away… So let’s compare the web performances of 2 very well-known SEO news websites: Searchenginejournal.com and Searchengineland.com. Have a look at the video replay of their homepage loading…

Which one seems the fastest to you? Check the video replay

No dramatical gape between these 2 browsing experiences, but you may find Searchengineland.com a bit faster, as its rendering starts sooner and the main images display too.
For a more detailed analysis, you can also take a look at the filmstrip within the comparison report provided by our testing tool:

This confirms the narrow victory (in matter of speed) of searchengineland.com: indeed, at 1,5s, it gets 85% completed while Searchenginjournal.com only reaches 40%.
For the most curious of you, let me point out that the current test has been operated via Dareboost.com, simulating a Seattle-based user of Google Chrome desktop browser and a Cable connection with a 10Mbps downstream bandwidth (28ms latency).

Let’s get back to fully loaded time values from the very-same test and check what they tell us … The results are quite different! 3,95 seconds for Searchenginejournal.com against 8,75 seconds for Searchengineland.com!
So, according to the fully loaded time analysis, we would conclude that Searchengineland.com is more than twice slower than Searchenginejournal.com. That is an inconsistent conclusion regarding the video replay analysis !

Then why did Search Engine Land get such a higher fully loaded time compared to its competitor? Because this indicator takes into account all of the HTTP requests and responses that are triggered all along the web page’s loading, including the deferred ones and even those that don’t impact the page rendering nor interactivity (for example: retargeting technologies).

In other words, the fully loaded time absolutely does not transcribe rendering speed for users but is no more than a technical loading delay.

Days after days, web pages get more and more complex, no longer limited to few lines of HTML code… Always enriched with more media, more features and external resources, and also a growth of asynchronous behaviours or progressive techniques to get a smoother browsing experience.
Nowadays, the fully loaded time has completely lost its relevancy about website speed as perceived by the end-user. And its only remaining interest is purely technical.

Speed Index, an indicator about UX!

If we no longer can rely on the time until the end of loading to evaluate our web pages speed, what other metric to trust then? For a few years now, a new range of indicators has emerged, based on video analysis. A testing base that is directly focused on the user experience related to the web page rendering!

Dareboost, among others, provides 3 major indicators based on this kind of analysis:

Those 3 indicators are all focused on the above-the-fold part of the page (visible without having to scroll)! Start Render, Visually Complete and Speed Index are complementary, but if you’d have to choose a single one, you should go for the Speed Index. It synthesizes the whole complexity and progressiveness of the web page rendering, as perceived by a visitor, in one single value.

Even if the Speed Index is computed from a smart mathematical formula (read this article for further information about our 3 indicators based on video analysis), it is quite easy to use: the lower it is, the fastest your web page displays.

So let’s check that with our previous comparison between Search Engine Land and Search Engine Journal:

1396 for Searchengineland.com; 1613 for Searchenginejournal.com… With the Speed Index , we do catch up the speed gap that we’ve observed empirically by watching the page’s loading video !

Nevertheless, the “load time” issues and limitations described through this post have to teach us one important thing: performance of a website can hardly be measured with a single indicator! If Speed Index can be considered today as the most “synthetic”, it may not be relevant in all cases!

As an example, Speed Index may be tampered by animations. This could affect the indicator’s consistency or make it irrelevant to transcribe the rendering speed.

Once again though, as a complete tool to manage your web performance in all cases, Dareboost allows to handle those kind of issues! Our advanced testing parameters offer a special feature to deactivate the animations of your web pages. A feature (still experimental) that will allow to deal with most of the cases by disabling CSS3 animations or Carrousels for example.

Conclusion

To successfully manage your website performance, you first have to adopt a reliable and rigorous measuring tool – as Dareboost of course! Then, identify and use a combination of several performance indicators, meeting your objectives. If you would have to keep a single one, It should be the Speed Index!

A few other metrics are emerging and are very promising, even if some would still need to gain in robustness. For example, First Meaningful Paint could become an excellent complement to Start Render, allowing to only consider the rendering of content with a significant interest…

Secure your cookies to the next level with SameSite attribute

Damien Jubeau — Sat, 01 Jul 2017 17:46:02 +0000

After reading our last article about how to secure your cookies, you may (should?) already be using Secure and HttpOnly flags. As a reminder, â€˜Secure’ allows to prevent a cookie to be sent on a non-secure web page, whereas â€˜HttpOnly’ prevents any client-side usage of a given cookie.
It is now time to take your website security to the next level with one more attribute for your cookies! Let’s talk about SameSite instruction, allowing to prevent Cross-Site Request Forgery (CSRF) attacks and Cross-Site Script Inclusion (XSSI).

SameSite attribute, to manage when a cookie should or should not be sent

The main concept behind Same-Site is similar to HTTPOnly and Secure features: getting control over the cookie behaviour, more precisely, defining when the cookie should not be sent.
There are two policies for SameSite attribute, defined by its values (case-insensitive): Strict (default) and Lax.

Strict policy for Same-Site Cookie

The defined cookie will only be sent if the request is originating from the same site.

_Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict_

Lax policy for Same-Site Cookie

Lax mode is adding one exception for the cookie to be sent if we’re not in a Same-Site context: the defined cookie will also be sent for requests using a safe method (GET method for most) for top-level navigation (basically something resulting in the URL changing in the web browser address bar).
The Strict mode would prevent any session cookie to be sent for a website reached by following an external link (from an email, from search engines results, etc.), resulting for a user not being logged in. (if we were using Strict Same-Site on dareboost.com, by clicking this link, you would not be detected as logged in, whether you were connected or not).
The behaviour can be confusing for the final user, so you would prefer using the Lax mode.

_Set-Cookie: SID=31d4d96e407aad42; SameSite=Lax_

WARNING: Strict being the default mode, any typo writing the Lax value would result in Strict behaviour.

Cross-Site Request Forgery, the initial problem

As defined by the OWASP, Cross-Site Request Forgery (CSRF) is an attack that forces an end-user to execute unwanted actions within a web application they're currently authenticated.
Let’s consider a predictable URL such as this one (that we can assume will provoke the user’s email to be updated):
https://myapp.com/updateUserEmail?newEmail=myemail@example.com

An attacker succeeding in having this request executed by an user being logged in, but with the attacker email as a param, would get access to the user’s account.
Social Engineering is often used to trick end-users and get them to trigger similar requests, for example by including an image having this URL as an SRC attribute. (by the way, most of the mail clients are now blocking images by default to limit CSRF attacks).
So far, preventing Cross-Site Request Forgery attacks was achieved by checking the Referer header and CSRF tokens (a token provided by the server to the web browser, and that will be sent by the browser within the protected request. If the request does not embed a valid token, it will be rejected).
Using a Same-Site Cookie (with Strict mode) would prevent CSRF attacks, except - as pointed out by the spec - if the attacker is combining its attack with an XSS one (do not forget to use CSP!).

Same-Site Support

There are other limitations for Same-Site to be Bullet proof against CSRF attacks, and the first one would be the current status of Same-Site support by web browsers.

Even if Firefox have shown clear signs of supporting Same-Site, Chrome and Opera are for now the only browsers dealing with the new instruction. A web browser that is not supporting the attribute will simply ignore it, you don’t have to worry of any compatibility issue.

Great feature, but not bullet proof

As a conclusion, Same-Site is definitively something you should consider if your website offers sensitive actions to your users, or if you have significant traffic. You have to note that Same-Site, also allows to mitigate XSSI (Cross-site script inclusion) and Timing attacks as stated by the spec.
Keep in mind that it’s just an extra layer of security: it can’t be your only site's defense against those attacks. And that’s explicitly detailed in the spec:

“Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are idempotent, etc) to mitigate the risk more fully.”

This article was originally seen on Dareboost's blog.

Content Performance Policy, an alternative to AMP?

Damien Jubeau — Thu, 22 Jun 2017 12:55:09 +0000

This article was originally seen on Dareboost's blog.

There is nothing really new about the Content Performance Policy since August 2016. Still, given the last months' discussions and statements about AMP, eg Kill Google AMP before it KILLS the web, I think Content Performance Policy deserves some attention!

You may already know about Content Security Policy. It’s a great feature to add more security to your website, particularly to protect your visitors from the effects of an XSS attack.
The idea behind CSP is to allow website owners to offer a security policy that will next be applied by the web browser. For instance, it allows to whitelist explicitly some JavaScript files, or to ensure the use of HTTPs to request each resource within the page.
Tim Kaldec and Yoav Weiss borrowed the CSP general concept to apply it to web performance topic, proposing a new HTTP header (Content Performance Policy), allowing to declare precisely the compliance level of a given page with some web performance best practices. Then, the user agent would be responsible to ensure the effectiveness of the announced best practices.
It’s kind of a SLA emitted by the website to the web browsers, and that the user agent will guarantee even if it means broking its own default behaviour.
Example: my website is announcing to the user agent (via no-blocking-font directive) that the page content can be displayed without having to wait a font file to be downloaded. If it’s not true (so the directive would be inaccurate), the user agent should bypass its default behaviour, and Â start anyway to display the textual content before downloading the font file.
Within this article, I aim to bring some context about the motivations behind Content Performance Policy (through a summary of the Tim Kaldec's article), to speak about the spec proposal of course (even if it’s very early stage), and at least to focus on the current limitations we could face with Content Performance Policy.
Indeed, within the Dareboost team, we work to provide a diagnostic tool as reliable as possible to check compliance with performance best practices (among others), so our point of view is not really the classical one.

Why a Content Performance Policy ?

We did not address this topic on this blog yet, but if you’re following us on Twitter (if not, it’s time to do so!), you surely know about it: Google recently shifted the lines with the Accelerated Mobile Pages Project.
It’s a framework to build mobile web pages, focused on speed and user experience. Google pushes things forwards, highlighting websites using this technologies in the search results since a couples of days.
Tim Kaldec had great words about it: AMP is a great technology, so is the project. But Google promote ONE technology, Â whereas AMP is not at all the only solution to build a fast experience, it’s just one way among others to do so.
Tim continues his analysis, mentioning that Google has actually done this to facilitate its own work.
I did raise this matter a few months ago, within this article about the Red Slow Label: it’s difficult to determine for sure whether a website is slow or fast, because you need to take into account a lot of params.
Besides, neither the Red Slow Label nor the Slow to Load have reached the SERP. Highlighting AMP, Google actually simplifies the equation: websites using it are considered fast, so they are promoted. Then there’s the rest of the world…
Here’s a Tim’s quote I find particularly clever about this:

So when we look at what AMP offers that you cannot offer yourself already, it’s not a high-performing site–we’re fully capable of doing that already. It’s this verification.

Personally, I’m still very impressed by what Google achieved, by such an adoption of the technology, and it has certainly contribute to wider the field of people caring of web performance. But perhaps for bad reasons?

Liquid error: internal

Tim Kaldec and Yoav Weiss worked to find a solution bringing a similar verification potential,Â allowing to promote fast websites with a good user experience, without creating a dependency to a particular technology. Because we need to preserve the web in its openness and its diversity.
That’s how Content Performance Policy was born!Â (event if it seems that AMP team was already on a similar matter)
As used framework or whatever technology would not be the guarantee of good performance anymore like AMP is, that should be the user agent role.Â A website is announcing what are the best practices it's complying with. If the site then broke its promise, the browser would have to enforce them.

Content Performance Policy, a good solution?

Let’s summarize:

Google enforced web performance to numerous website owners that are dependant of organic trafic, therefore required to adopt AMP in order to benefit from the promotion of this technology in the search results
Content Performance Policy do not go against the idea to promote speed, it even probably recognizes the benefit of the positive pressure that search engines can bring. However CPP idea is to offer an alternative to an AMP only world. Â
AMP was a deal between Google and websites, whereas Content Performance Policy add user agent vendors to the team, as user agents would vouch for websites’ promises

Of course, within the Dareboost team, we’re very enthusiastic to discover such great ideas! We 100% agree with the approach and the need of something else than AMP.

Google penalizing slow websites has always been a matter for us, with a lot of questions raised. We automated the detection of a lot of web performance issues, going further that most of tools. We also benchmarked big samples of websites to know more about performance.
That’s why we also wished to bring our opinion through this article, even if we're more used to speak about finalized recommendations. Â

Stakeholders interdependencies

The first difficulty that may be interesting to focus on is probably the narrow relation between 3 parties to see CPP to be adopted: search engines, user agent vendors and website owners.
Without incentive from search engine, CPP would probably stay a web performance world thing, an interesting tool but not helping into pushing speed at a new level as AMP seems to achieve.
Without web browsers implementations, CPP would not be a verification signal at all, as nothing would enforce websites to comply with their promises.
Without a wide adoption from website owners it would result as penalizing a lot of fast websites not using the mechanism. Â

Speed or nothing?

Reading the list of directives (on 25th feburary), we can assume that understanding Content Performance Policy requires some advanced knowledge about various topics.
It sounds like it may hold up the adoption process. Not only you have to understand what it is about, but also what are the stakes and especially what a directive violation would result in.
Using CPP also implies an important maintenance effort. Today, a mistake is slowing down Â your website. You can detect the slowdown, for instance using a web performance monitoring tool like Dareboost ;). Using CPP, a mistake may mean your website won’t work anymore! (example: my website promise is to load less than 800ko. If an heavy image is added for instance via a CMS - and so directly in production outside of my staging workflow - web browsers will block data to avoid an overflow in order to keep my website complying with its promise. What if the block content is an essential JS or a CSS?)
Some of the CPP obstacles are similar to the ones we have with Content Security Policy adoption. If you provide A/B Testing or Tag Manager solutions to your team, you expose yourself to broke the promises at any time in production. And that might result in broking your website, as the browser job is to vouch for the promise.
It’s very interesting to be able to constraint third-party contents. Nevertheless, for performance matters I think it something you have to do sooner, when choosing your services. Using CPP to do so, the risk to see some third-party content broking at any time due to an update is high.
Yoav answer :

“I'm not sure how it would look like, but we plan to have mechanisms that will limit the impact to certain hosts.” Â Proposal has since been updated

Finding a common reference basis

Last but not least, how can we establish the degree of importance for each directive? How to be sure we have enough directives in the list to reasonably affirm that a page is fast enough? Even we succeed, establish thresholds (resource-limit, max-internal-blocking-size) will be hard. Avoiding more complexity is absolutely required to hope website owners adoption. So it would imply a common basis for thresholds, for all the players using CPP as a verification mechanism (browsers, adblockers, search engines, etc).
As pointed out by Yoav, this matter would be taken into account (see github issue).
As reminded by the AMP team, we don’t have to forget that things that are slow today might not be slow tomorrow, so this basis should be able to evolve.
The approach remains great, and it’s really nice to see people coming with this kind of amazing ideas.
I think CPP needs to offer more control for each directives, to be able to make a promise including or excluding some resources (in order to prevent breaking anything vital if a promise would come to be broken)
IMO, it might be nice to make a clear separation between promises enforced by user agents that have no major consequences (ex: no-auto-play, no-blocking-font), those that can be risky, and those that can’t reasonably be enforced by browsers (ex : max-internal-blocking-size).

Maybe it's time to give CPP a new start? feel free to contribute to the proposal.

Secure your Cookies (Secure and HttpOnly flags)

Damien Jubeau — Mon, 20 Mar 2017 16:20:56 +0000

Cookies are omnipresent all over the web as they let publishers store data directly on the user's web browser. Especially used to identify the user session allowing the web server to recognize him all along his browsing, cookies usually contain sensitive data. You have to properly protect them.

The Set-Cookie HTTP header

As a reminder, a cookie is usually created on the web browser following the server response, in order to store a status, that will be transmitted over the next requests. To do this, the web server uses a Set-Cookie header in an HTTP response. Here is the syntax of such a header:

_Set-Cookie: =[; =] [; expires=][; domain=] [; path=][; secure][; HttpOnly]_

The cookie is identified by a name, associated to a value. A lifetime and/or an expiration date can be set. Note that if both attributes are set then the lifetime value (max-age) will prevail.

The web server can also define a path and a domain to be used for the cookie. These domain and path attributes allow to restrain its range… or extend it (by allowing its usage on any subdomain for example). As a consequence, one of the first best practice about Cookies security consists in handling properly their range.

The last 2 attributes, secure and HttpOnly are specifically dealing with security. Please note that they don't accept a value. Their presence only will imply the browser behavior towards the cookie.

Forbid to use a cookie user-side thanks to HttpOnly

A cookie can be placed and used by a web server, but also directly on the web browser via Javascript.

In an XSS breach case, an attacker could inject some Javascript, and potentially access to the cookies that, as a reminder, often contain sensitive information. First of all, it is obviously better to prevent the XSS breaches. Then you can avoid those weaknesses to be exploited by defining a Content Security Policy.

The “HttpOnly” flag blocks the cookies usage via Javascript: if an attacker succeeds in injecting some javascript despite all your precautions, he won't be able to access the cookies anyway. That will significantly limit the attack range.

Forbid to use a cookie without HTTPs thanks to the Secure flag

We regularly recommend it on this blog: your website should use HTTPs.

If you have already adopted this protocol and applied our previous advice, you may think that your cookies are protected as they are transmitted through a secure communication and as they can't be reached in Javascript. Unfortunately, a noticeable issue remains. What if a user comes to your website via HTTP, simply because he's typing your URL without mentioning “https://”?

This could also happen if your web page contains mixed content. Setting an HSTS (HTTP Strict Transport Security) header, that will enforce HTTPS usage for all the upcoming visits, will limit the risks related to the first scenario. But all the browsers do not support this header… Still, the first visit remains an issue. About the second scenario, the Content Security Policy can prevent from any mixed content risk with browsers that support “Upgrade Insecure Requests” policy.

Actually, only the secure attribute will let you forbid a cookie to be ever transmitted via simple HTTP. The interest of this flag is clearly mentioned in the RFC HTTP State Management Mechanism:

_Servers that require a higher level of security SHOULD use the Cookie and Set-Cookie headers only over a secure channel. When using cookies over a secure channel, servers SHOULD set the Secure attribute (see [Section 4.1.2.5](https://tools.ietf.org/html/rfc6265#section-4.1.2.5)) for every cookie. If a server does not set the Secure attribute, the protection provided by the secure channel will be largely moot._

Obviously, keep in mind that a cookie using this secure flag won't be sent in any case on the HTTP version of your website. So be careful if your website still has got both HTTPS and HTTP areas.

As a conclusion, feel free to give a try to Dareboost web page analysis tool. It will let you ensure that all of your cookies are secured, by checking if HttpOnly and secure are properly used:

Web Performance & Security: how to master Third Party Content impacts

Damien Jubeau — Thu, 16 Mar 2017 18:28:18 +0000

Why do we need to look after third parties?

Third Party content are assets on which you basically don’t have much control, as they are provided and hosted by a third-party.

Social networks widgets, advertising and tracking scripts or web fonts providers are some widespread third-parties you’re used to deal with.

Whatever they are free or not, these providers allow websites owners and developers to enrich web pages and web usages. Frequently, but not always, some features we just can’t provide by ourselves (even if technically feasible, the related cost might be blocking).

Third-Party assets are more and more used on our websites (take a look at the evolution of the average number of domains used by a web page) and we do not pay due attention to this topic. Here’s some evidence:

In 2012, thousands of websites have faced major slowdowns… due to Facebook’s “Like widget (Forbes’s article)
More recently, you may remind about Typekit’s font serving outage (related to Amazon S3 outage), here again with thousands of websites affected (Post Mortem on Typekit’s blog)
A lighter and funnier example might be DailyMotion broadcasting a job offer last year within the developer consoles of web browsers. The job offer has been broadcasted a few days long on all websites using their widgets! (The message that was displayed within your console while browsing any website using a DailyMotion embed video widget)

If you don’t pay attention, a third-party can affect your website in many ways, as far as making it unavailable for your visitors!

Still, you’re probably not the only stakeholder when it comes to use or not a third-party. However, you definitively have to go further than just reading and following the provider’s documentation.
I like to consider third-party content as parasites. Friendly ones, with - most of the time - good intentions. But parasites anyway, and a growing infection may take down your whole website.

Through this post, I aim to share my vision and experience about third-party content, but most of all to bring you some best practices and tool to mitigate the risks related to third-party content integration.

Speed and third-party content, a complicated story.

Within this first part, we’ll focus on web performance and third party content effects on speed.
This is an important topic for several reasons. Let’s start with the basics. First of all, we have to note that an external asset is loaded from another domain name than the one used for your website. It means that the web browser has to trigger a DNS resolution and next to establish a new TCP connection.

At this early stage, we have to question the third-party server location: if the provider does not use a CDN (Content Delivery Network), it might result in a high latency over the network (as latency is related to the nature of the network, but also the distance between the server and the web browser).

If your website targets a particular country, you may not be familiar with this issue, as you’re probably hosting your website in this very same country. Using a third-party provider without a CDN might result in loading an asset hosted halfway around the world.

But that’s not all. If the request is benefiting from a security layer thanks to HTTPs (and it should) you’ll have to add an extra delay, as HTTPs usage implies additional exchanges to establish the secured connection.

Finally, you’ll be dependant on the server response time and upstream bandwidth of the third-party provider.

Some website speed test tools (give a try to ours, Dareboost!) might help you to understand the impact of third-party content on your website performance. For example, here’s a comparison report of cnn.com both with and without their third-party content. Guess which version is faster?

As stated in introduction, you don’t have control over the performance of third party providers. You could still establish an SLA (Service Level Agreement), but most of the time we can’t - except if running a major website with big money.
Third party content can be a great way to enrich a website, but they come with important impacts. That’s why you have to limit as much as possible this kind of dependencies.

You don’t have to load the whole framework of a social network to display a simple share button. Implementing your own is easy. Imagine your own implementation, and even if in some some ways it is more limited, it will definitively be a win at the end.

Obviously, this example is a trivial one, and there may be some third-party content you just can’t do without. Then you’ll need to be very cautious in your integration.

Exclude third party from critical render path

Displaying a web page requires a lot of operations from the browser: receiving the HTML source code, fetching some assets, building the DOM, CSS tree.
Some of these operations are blocking, meaning they need to terminate before allowing any display. A well-known example is Javascript called synchronously within the <head> of a web page.

Performance optimization best practices are often focusing on the critical rendering path, in other words on elements and operations impactful for the above the fold part of the page.

Given the different delays added by the use of third party content, it’s really important to avoid using any of them within your critical rendering path. You should be in search of absolute control of the early display of the page.

Both Facebook and Typekits examples discussed earlier illustrate perfectly what are the stakes of having third party content blocking your critical rendering path. Dependencies that slow down your page loading in the best case scenario. At worst, it might result in website unavailability if they were to fail.

A dependency failure resulting in such a breakdown is so called a Single Point of Failure. A notion that front-end developers might not be so familiar with.

“A single point of failure (SPOF) is a part of a system that, if it fails, will stop the entire system from working.”
Wikipedia

At this stage, most of the time I can hear some people telling me: “Yeah, ok, my website has some SPOFs. But that’s Google Fonts. I mean GOOGLE. I can trust them for 100% uptime or whatever big players they are confident about. Short answer: they’re wrong. Pick-up the argument you like the most: There’s no bullet-proof big player. Our introduction was about Facebook and Typekit (related to Amazon S3 failure), right? It will happen one day.
A SPOF is not triggered only in case of failure of the third-party! A firewall or a network error/congestion might also result in a requested file not having a response!
When your website is not loading, from the visitors perspective, it is your fault. Not Google’s one. Real people don’t have any idea of what’s required to display your page! You can trust them, but you alone will face the consequences.

I may sound a little bit alarmist here. SPOF is a risk, and you should consider it in terms of probability of occurrence and related income loss against cost to be fixed. It’s your personal blog? You can totally trust Google and keep going with your SPOF!

Of course, if you’re using a third-party, that’s because it achieves something for your needs. Having a third-party to fail will then result in a missing feature. Most of the time, your website can - and should - work without this feature. If you’re doing business online for real, you need to eliminate SPOFs by all means!

Unfortunately, a blocking behaviour might be required by some third-party services. For example, some A/B Testing solutions specifically advise to use a blocking integration. Indeed, they wish to avoid flickering (the original page should not be shown before execution of the A/B testing edits). Yes, it’s nothing less than slowing down the page rendering, but on purpose.

Anyway, you can still avoid that being a SPOF.

A blocking javascript file, when being too slow to load, will be aborted by the browser. However, the default timeout policies of web browsers are not a good fit for non critical resources (you would rather miss some A/B Test sessions than having some customers waiting 30 seconds for a page to render). Default timeouts vary from a couple seconds to... minutes (there’s a great post from Steve Souders if you want to know more about it).

Knowing that, you should take control over the default timeout policy if you need a blocking third-party asset. Consider the feature value for you and your user, configure the appropriate timeout, and you can even add a fallback!

Check this post from Typekit, that have updated their docs since the 2015’s breakdown.

Last point about 3rd parties and speed: Tag Managers. You probably have integrated Google Tag Manager on some of your projects, allowing to centralize third-party calls, and bringing a whole new level of autonomy for non tech people to add new services… Good news is GTM is loaded asynchronously by default and same goes for subsequent tags.

“With great power comes great responsibility”

Tag Managers often answer needs of people without a technical culture, and who won’t be vigilant about the impacts of such injected content. Risks for load time, but also for security as we will discover later. Offering a Tag Manager means giving power to its users, and your job is probably to let them know about the implications, or to set up a validation workflow.

Quality Audit for your 3rd parties

As previously stated, most of the cases we just can’t discuss an SLA with the provider. Anyway, there’s probably available alternatives on the market for what you need, and you should probably add quality and performance as factors considered to choose a provider.

I remind having considered a click2chat Saas provider for our own website. While quickly checking the loaded assets, I saw an image file that was about 250KB. Optimizing this icon would have resulted in a 100x lighter file to be loaded.

The chat was loaded asynchronously, so not a big deal. But still, a slow image to be loaded for low bandwidth connections. And more important: it was pointing out that image optimization was not a part of their workflow. Image could as well have been 2MB.

Performance Budget is a very interesting method to make sure your website remains fast. It can be a great way to make sure to keep control over third-party and their evolutions through time thanks to website monitoring.

To audit the quality of a third-party, Simon Hearne has done a great work for you with a checklist you can use to make sure you’re considering all major impacts.
When finding problems or any potential optimization, feel free to get in touch with the provider. Having an editor to fix it will probably benefit thousands of websites! Knowing how the provider is dealing with your demand will also be a great insight.

Mitigate the risks related to 3rd parties

Adding a third-party to a web page implies a high level of trust for the provider, as you’re losing some control. Applying previous recommendations, you made sure that the provider is qualitative, and that a failure won’t result in your website being unreachable.

Still, the third-party have gained control over your page! You can’t blindly trust him. Even if the provider has the best intentions, it can still do mistakes, or even be hacked. Let’s speak about security.

First of all: HTTPs is a requirement. If your website is using the secure version of the protocol, you just can’t have 3rd parties working over HTTP (that would be Mixed Content, something web browsers are blocking automatically).

You need to go further regarding the security, by adding restrictions to 3rd party content scope. For example, you can use the sandbox attribute over iframes. It will allow you to restrict the actions available from an iframe (for example, forbid Javascript usage).

Another - very powerful - tool: Content Security Policy. By using a simple HTTP header in your server's response, you can explicitly define content and behaviours you trust within your page. Whatever is the element not being allowed, the browser won’t execute/request it. Assuming of course that the web browser supports CSP.

If your website is vulnerable to some Cross-Site Scripting (XSS), defining a Content Security Policy won’t solve the vulnerability. Nevertheless, it will protect your users against the effects of an XSS attack.

Example: By using a form within your page, an attacker succeeds in injecting a javascript file in your page, let’s call it malicious.js. The script tag requesting malicious.js is indeed in your page. However web browsers won’t actually request the file, instead they will throw an error, as this request violates your Content Security Policy directives. XSS vulnerability has been exploited, but without having effects on your visitors.

That’s a good way to make sure your third-parties do not allow themselves to do more than they should with your pages. And if a provider was to be hacked, you would have mitigates the risks for your own traffic.

Last but not least, protect your cookies! A third-party injecting Javascript within your document can access the cookies related to your domain through Javascript! Setting cookies with an HttpOnly flag, you’ll forbid any client-side usage!

Your turn!

Third-parties usage grows. Pay attention to the related risks and limit as much as possible their number. Audit those you need, and choose wisely among offered alternatives.

Keep in mind they are parasites, and they will evolves: add as much constraints as possible and monitor them!

This post was originally seen on our blog about website speed and quality.