Intent to Ship: Blocking the load of cross-site, parser-blocking scripts inserted via document.write in the main frame, for users on 2G.

[Kenji Baheux]

Contact emails

{shivanisha, bmcquade,  jkarlin, kenjibaheux}@chromium.org

Spec

The Spec change is being discussed in this issue.

Summary

This intervention blocks the load of cross-site, parser-blocking scripts inserted into the main document via document.write over 2G connections. To minimize breakage, the intervention issues async requests for blocked resources. The intervention does not trigger on page reload or when the resource is cached.

User benefits from the intervention are impressive: 25% more page loads that complete (i.e. fully parsed) and 38% faster mean time to page load completion - representing an improvement of nearly six seconds. Also, we saw 10% fewer reloads suggesting a decrease in user frustration and by consequence a very low rate of breakage.

Motivation

Historically, third party content such as ads and analytics used document.write to load script resources. Despite widespread support for asynchronous loading, roughly 13% of page loads continue to use document.write in a way that harms performance.

Based on instrumentation in Chrome, we've learned that pages featuring third-party scripts inserted via document.write() are typically twice as slow to load as other pages on 2G.

From a field trial with Chrome stable users, we learned that:

• 7.6% of all page loads on 2G were impacted by the intervention

• 10% more page loads reached first contentful paint (the visual confirmation for the user that the page is effectively loading)

• 25% more page loads reached the fully parsed state.

• 10% fewer reloads suggesting a decrease in user frustration.

• 21% decrease of the mean time for the first contentful paint (over one second faster)

• 38% decrease of the mean time it takes to parse a page (representing an improvement of nearly six seconds).

See this additional analysis for more details and additional insights.

The significant boost in terms of page views and user engagement clearly shows that speed matters. This also suggests that sites experiencing breakage may still benefit overall and would further improve their success metrics by adopting an asynchronous loading pattern.

Interoperability

We’ve discussed this intervention and shared our learnings with other browser vendors via an issue filed in the WICG Interventions github, as well as emails and face to face discussions. We also reached out to many third parties and industry bodies to discuss this intervention. In general, document.write has long been seen as a problematic API and there is a shared desire to find a way out.

Compatibility Risk

Most scripts inserted via document.write are for third party content such as ads and analytics, which lowers the likelihood of breaking the main content of the page as a result of this intervention. To further minimize the risk, the intervention only triggers under specific circumstances and features the following mitigations:

• The intervention does not trigger for same-site scripts (i.e. hosts with matching eTLD+1).

• Asynchronous requests are issued for the resources that were blocked and would then be loaded on subsequent navigations.

• Reload gestures inhibit the intervention.

Debuggability

Beside the usual warning and error messages in DevTools, an Intervention HTTP header is sent to the URL of the relevant resources:

• To warn of the possibility of an intervention (e.g. when the user was not on 2G):

Intervention: <https://www.chromestatus.com/feature/5718547946799104>; level="warning"

• To report an actual intervention:

Intervention: <https://www.chromestatus.com/feature/5718547946799104>

Web authors can look for these headers, in combination with the Referer header, to understand which integration points are at risk or impacted by the intervention.

To simulate the effect of the intervention, we recommend using Chrome canary and enabling chrome://flags/#disallow-doc-written-script-loads which will force the intervention on all connections.

We've also prepared an FAQ and a form to capture additional questions as well as feedback from web developers.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All platforms except WebView. However, the intervention will only trigger on Android and Chrome OS because other platforms do not support the detection of the connection type.

OWP launch tracking bug

crbug.com/640844

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5718547946799104  

[Daniel Cheng]

Will cross-site become official terminology in the spec?

From what nasko@ and I can tell, it looks like the current cross-site definition for blocking scripts doesn't match the term as used elsewhere in Chromium (which also takes port and scheme into account) or similar-origin browsing context [1].

Daniel

[1] https://html.spec.whatwg.org/multipage/browsers.html#groupings-of-browsing-contexts

[Daniel Cheng]

Nasko just pointed out that cross-site (as used elsewhere in Chromium) and similar-origin browsing contexts actually don't take the port number into account, so it's just scheme.

Daniel

[Rick Byers]

This is a tricky intervention because there's some real risk, eg. by breaking ads on some sites.  However after seeing all the hard work, experimentation, analysis and careful thought the team has put into this one, I'm now convinced it's ready to ship.  I have full confidence the team will continue to iterate to strike a healthy balance of pushing the ecosystem to improved user experience while keeping breakage to a minimum.  LGTM1.

For those that are concerned, here's a summary of my reasoning:

1) In some cases there will be a net decrease in real breakage:

This isn't our normal "how much breakage can we tolerate for the benefit we get" because the data shows that sites impacted by this intervention are often already seriously broken by taking so long to load.  We know that on average around one quarter of users will give up waiting for a page to load that takes longer than 4 seconds. Increasing successful page loads for the sites impacted by this intervention by 25% is HUGE.  So we need to keep in mind that we're not necessarily adding net breakage here, but trading one form of breakage (users giving up waiting for a page to load)

2) An intervention is necessary maximize the return on investment for scripts which do follow async loading best practices

It seems there's a "tragedy of the commons" around 3rd party scripts and page load time.  If 9 of the 10 3rd party scripts you use follow best practices and load asynchronously but one doesn't, then the entire experience suffers (including for those 9 well-behaved scripts).  There's not a huge incentive for any one 3rd party script to switch to async loading.  But if we can break just the one script not following performance best practices, then all the other code on the site which is following async loading guidelines will immediately see the benefit.

3) The impact really is huge

Shaving a second of the key loading metric and getting 25% more pages to the loaded state is really a massive improvement in user experience.

4) This intervention has worked hard to adhere to the design guidelines

Predictable: although a heuristic, the rules and results here are very precise.  The team has worked hard to get the word out about this upcoming change including adding console warnings to Chrome 53 and talking specifically with the IAB.

Avoidable: cross-site parser-blocking scripts have been a performance anti-pattern for ages

Transparent: in addition to the typical devtools logging, I'm particularly pleased with the work to send the 'Intervention' header for this - enabling site owners to see exactly where the potential for breakage is, and precisely how often breakage really did occur.  There's no need for this intervention to spawn a wave a fear - it's already been shipping via a 1% trial and in Chrome beta, check your server logs to quantify precisely the extent to which your site has been impacted (chances are it's not much at all).

Justified by data:  We've been talking about doing something like this for a LONG time, but it's taken a lot of work to gather all the data, run all the experiments and make the best tradeoffs we can.  I believe the data now paints a clear picture that this is overall a substantial net win for the web.

5) The loading team is committed to refining this over time

This space is complicated.  I have no doubt we'll make some small mistakes.  But I have full confidence that the team is paying attention to the metrics and feedback and will continue to tweak the tradeoffs to strike the best overall balance we can for the health of the web.

6) The alternative is far worse: ad blocking

The impact of this is definitely tiny compared to the "breakage" from installing an ad blocker, which (especially for 2G users) is growing at an alarming pace.  Taking the long-term view of what's best for the web ecosystem as a whole, it's completely clear to me that the far greater threat is the collapse of the web's business model due to ad blocking.  I'm much more concerned about the future of the web if we fail to have the necessary courage to try high-impact high-reward things like this.  Like any democracy, it's always easier for the web to become paralyzed by criticism and fear and fail to act when action is really important for long-term health.  Although we (the chromium maintainers) are elected by our users and developers (by their choice in browser), like a good politician we mustn't fall prey to the temptation to garner popularity by avoiding all opportunity for criticism, rather stay focused on maximizing the total aggregate good for all our constituents. 

[phfew sorry for the philosophizing, just anticipating the concern]

Kenji, Bryan, Ojan and all - thank you for all your diligence and courage investing in difficult and contentious tradeoffs like this!  Good luck with the launch and all the follow-up work!

Rick

[Dimitri Glazkov]

LGTM2.

[Chris Harrelson]

LGTM3

LGTM2.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Kenji Baheux]

Hi Daniel,

I've followed up on your question about aligning the "same-site" definition to (eTLD+1, scheme). In short: I agree that we should align to what is considered the standard definition.

API owners, thanks for the feedback.

LGTM3

LGTM2.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Joe Medley]

What version should be on the Chrome Status page? 55 is already in beta.

[Kenji Baheux]

55 is the version we've been aiming for.

--

[and...@asteitz.com]

I posted comments yesterday at https://github.com/WICG/interventions/issues/17#issuecomment-269690768.  This (broken) intervention has caused a potential invasion of privacy concern on at least one web site that I use.  It needs to be fixed ASAP.  I have posted my concerns to my Google+ account and my Facebook page.  If I do not hear from someone that this will be fixed post haste I will be forced to broaden the scope of my announcement.  Sorry.

-Andrew

[Bryan McQuade]

Hi Andrew,

Thanks for reaching out. The console warning shows up in cases where the intervention would have triggered on slow connections, even if you are on a fast connection, to help developers to identify cases where users on slow connections would encounter blocking. So the warning is just that: a warning - it doesn't indicate that the intervention actually triggered in your case.

If you see "A Parser-blocking, cross-origin script, ..., is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details." in the console it indicates that the script may be blocked for users on slow connections, but not necessarily that the script was blocked for your connection. We currently only block on 2G so this should not be triggering if you are on a fast connection.

RE: your comment on the interventions issue, if the Humana site is failing to support logout on a fast connection, that's likely due to a bug on their site (or possibly a different Chrome bug) rather than this intervention, as the intervention should be having no effect while on a fast connection.

To force disable the intervention, just to be certain, you can go to chrome://flags/ and choose 'Disabled' for 'Block scripts loaded via document.write'. If you are already on a fast connection this should be a no-op, but it can't hurt to try. If you see different behavior with the intervention disabled (i.e. the 'logout' option starts to work) then please let us know.

[ejcr...@gmail.com]

Hi - this "feature" does not allow me to log in to southwest airlines - I am not on 2G - I am on a 30+ mbps cable modem.  

How or why would I be effected by something supposed to be 2G???

[Bryan McQuade]

Hi,

Thanks for reaching out. The console warning shows up in cases where the intervention would have triggered on slow connections, even if you are on a fast connection, to help developers to identify cases where users on slow connections would encounter blocking. So the warning is just that: a warning - it doesn't indicate that the intervention actually triggered in your case.

If you see "A Parser-blocking, cross-origin script, ..., is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details." in the console it indicates that the script may be blocked for users on slow connections, but not necessarily that the script was blocked for your connection. We currently only block on 2G so this should not be triggering if you are on a fast connection.

Can you provide the full console log and page URL where you are encountering the issue in the associated bug: https://bugs.chromium.org/p/chromium/issues/detail?id=640844 and we can try to help debug further?

Thanks,

Bryan

[Ed Crotty]

https://bugs.chromium.org/p/chromium/issues/detail?id=640844#c22

thanks