Chrome's NOSCRIPT Intervention
As you would expect, then, there’s been a lot of ensuing conversation. However, all the articles I had read were speculating on what the intervention would look like, not what it does. It took a little digging through Blink issues, but I eventually figured out how to reliably fire up the NOSCRIPT preview so that I could test it out.
What exactly does it do?
Taking it for a test drive
To test the intervention, you’ll need to toggle a few flags to make sure you can see the NOSCRIPT preview. Once it’s enabled by default on Android, which presumably will happen in Chrome 69, this won’t be necessary.
To toggle the flags, open Chrome on your Android device and navigate to
#enable-noscript-previews must each be enabled.
#enable-optimization-hints should be disabled (we’ll come back to that later). You’ll also need to set the
#force-effective-connection-type flag to ‘2G’ or slower.
When does it kick in?
The intervention kicks in when two criteria are met (it’s a bit more complicated than that, but we’ll get to that in a minute):
- The effective network connection type is 2G or slower
- The Data Saver proxy is enabled
If you want to see the intervention in action, you’ll need to make sure Data Saver is running (Chrome > Settings > Data Saver).
In real use, Chrome will use the Network Information API to determine if the effective connection type (ECT) is 2G or slower and, if it is, use the NOSCRIPT intervention. For testing purposes, you can force Chrome to always view the ECT as a 2G network using the
#force-effective-connection-type flag I mentioned earlier.
On the surface, the decision to apply the intervention seems straightforward. If the network is slow and the user has made the decision to get let Chrome help them out in those situations, you’ll get the NOSCRIPT intervention. The reality is it’s a little more complex than that.
For one, there is a whitelist and blacklist that can opt domains in or out of this optimization. It appears that there are lists on the browser side as well as on the user side. I’m not clear on all the ways those lists can be populated, but it does look like if the user opts out of the same host often enough, the host will be added to the preview blacklist. There is also a short period (about 5 seconds from the looks of it) where Chrome will decide not to use the intervention from any site if a user has recently opted out.
Another wrinkle is that the NOSCRIPT intervention is far from the only option Data Saver has to reduce page bloat. There are other optimizations, and even other previews (like the LOFI preview which will load image placeholders instead of actual images). Again, I’m not 100% certain about the logic they’re using to determine when a given preview is the correct option, but it does appear there’s some thought applied here: they’re not just applying the NOSCRIPT intervention to every page that comes along.
That’s where the
#enable-optimization-hints flag I mentioned earlier comes in. Enabled by default, this flag enables Chrome to use “hints” to determine when and where certain optimizations should apply. Right now, to apply the NOSCRIPT intervention with optimization hints enabled, the request must be whitelisted. I suspect they may get more aggressive with the optimization after they’ve had it running like this for awhile. In the meantime, to consistently see it in effect, we need to disable those hints.
So yes, it does kick in on 2G networks with Data Saver enabled, but as you can see, there are more variables at play.
It works on HTTPS too
Before testing, I made the (mistaken) assumption that since the NOSCRIPT preview intervention was tied to Data Saver, it wouldn’t apply to HTTPS sites. Data Saver, like most proxy browsers and services, tends to leave HTTPS alone. But it looks like I was wrong: the NOSCRIPT intervention appears to work on both HTTP and HTTPS sites.
I guess it makes sense. The reason Data Saver (and other proxy services and browsers) leave HTTPS alone is that applying any transformations to the content would require that they essentially act as a man-in-the-middle.
How do developers know the intervention has been applied?
When the intervention kicks in, all requests will have an
intervention header applied to them, like so:
The presence of the header is enough to indicate that the browser applied some sort of intervention, and the URL in the header will point to more information about the specific intervention applied.
There’s one notable exception: the main document does not appear to get the
intervention header currently. Honestly, this may just be a bug as it’s not clear to me why the header wouldn’t be applied to the main document.
All requests (including the main document) will also have the
save-data header set to
on, but you shouldn’t rely on that as an indication of an intervention. The
save-data header will be applied whenever the proxy is enabled (or, really, any proxy service or browser that supports the header), regardless of whether the browser applied any interventions.
If you’re actively testing, you can also fire up
chrome://interventions-internals/ in Chrome on your device and follow the logs to confirm when the NOSCRIPT intervention has been applied.
What does this mean for users?
For users, the intervention can be very effective for certain sites. I loaded up 10 different sites with the NOSCRIPT intervention enabled and disabled to see the difference.
|URL||NOSCRIPT Weight (KB)||Original Weight (KB)||Change in Weight|
<noscript> element. Unfortunately for visitors to both sites, several fallback images are massive—ranging from 1.6MB to 9.9MB.
When the optimization works, which is more often than not, it works very well. The minimal improvement was a 24% reduction in data usage, and the remaining sites shed between 74-98% of their bytes.
What does this mean for site owners?
The BBC site is a good example. Below you can see the mobile site (left) and the NOSCRIPT preview (right). There is very little difference. The branding is retained, and the content is readable.
Contrast that with the Engadget site, which displays nothing whatsoever in the NOSCRIPT preview:
Or AliExpress which does have some navigation displayed (kind of), but no branding:
You can, technically, opt-out of the intervention altogether by setting
Cache-control: no-transform on your main request. The
no-transform value tells proxy services not to modify any requests or resources and the intervention respects that: applying it ensures no one will ever see a NOSCRIPT preview for your site.
But use this with extreme caution. I’ve always been incredibly uneasy about using the
no-transform value to opt out of proxies. Users are choosing those proxy services or browsers intentionally. They’re opting into these sort of optimizations and interventions and it feels a bit uncomfortable to me when developers overrule those decisions.
If you are going to opt-out using the
no-transform value, then at least make sure you’re making ample use of the
save-data header to reduce weight wherever you can: eliminating web fonts, serving low-quality images, etc.
This is a good thing
Long story short, the NOSCRIPT intervention looks like a really great feature for users. More often than not it provides significant reduction in data usage, not to mention the reduction in CPU time—no small thing for the many, many people running affordable, low-powered devices.
The Chrome folks, as you would expect, aren’t being haphazard with the intervention either. In fact, by (at least initially) relying on a whitelist, they’re being pretty conservative with it. It’s just one of many tricks in their bag to provide a more performant experience and they appear to be treading carefully when it comes to applying it.