I2I: Increase amp-script size limit for sandboxed scripts

[zshnr]

Summary

Following on from the work proposed in this I2I from last year #30193 which was implemented in this PR #33643, we propose a looser enforcement of size restrictions for sandboxed amp-scripts.

Design Document

Within amp-script.js :

The code checks for size limit within the layoutCallback function.

We can approach this in one of two ways:

1. If we decide to not impose any size limitations on sandboxed amp-script scripts then we can simply add another condition to the if block inside this function

if (!this.development_ &&
    !this.sandboxed_ &&
    this.service_.sizeLimitExceeded(authorScript.length) { ... }

2. If we decide to impose a higher size limit then we can enhance the sizeLimitExceeded function to use a max size limit based on whether or not the script in question is running in sandboxed mode or not

Motivation

The Permutive SDK enables our customers to target ads in real-time without having to send data back to our servers for processing. It also integrates with other ad-tech solutions to enable exposing cohort membership data to ad-tech partners, such as Google Ad Manager.

To facilitate the way the SDK work and is deployed for our customers, we worked with the AMP team to bring a new mode for amp-script called sandboxed mode, which was implemented here #33643.

This mode explicitly adheres to the AMP principles of ensuring a smooth and performant user experience.

The sandboxed mode allows scripts to run inside a web worker in a cross-domain iframe. The script doesn’t need a csp-hash to be provided either.

Running inside a web worker and not having access to the DOM means that our SDK is able to operate completely in the background, without having any impact on the experience of the end user.

In AMP, our SDK currently supports one partner integration with Google Ad Manager. However, to support the growing needs of the publishers we work with, we are looking to extend our capabilities in AMP to support additional partner integrations. This will enable our integrations to drive the same value for publishers as we do on standard web pages.

Unfortunately, this has meant that we are running up against the 150 kB size limit of amp-script

We understand that this limit is to prevent bloated scripts from adversely impacting user experience on AMP and this is a very valid concern and goal.

Fortunately, with the introduction of the sandboxed mode, we can now have scripts on the page that can run in the background without adversely affecting the experience of the user on the website.

We’re also conscious that this limit applies to all amp-script elements on the page. Given that the sandboxed mode is quite new and not yet properly documented, this might not be an issue that many vendors run into. But as the existence and benefits of this new mode become well known across the AMP ecosystem, we might find vendor scripts that collectively run into this limit.

For these reasons, we propose that sandboxed scripts have a higher limit of 300 kB

We think that this will enable vendors such as ourselves to help publishers enrich experiences for their users without getting in the way of the core user experience on AMP.

Alternative Solutions

1. Decrease features: This is unfeasible for us as a business because there are certain expectations that our customers have with our SDK that we cannot sacrifice on any platform
2. Move processing logic to server side: This would mean sacrificing the advantages of on-device processing, which our publishers are benefitting from in other environments. We believe this is the fastest and most privacy-compliant approach to audience targeting, which is good for publishers and end-users.
3. Remove 3p dependencies from bundle: Bundle currently only relies on 2 3p dependencies.
   1. One of which is barely a few 100 bytes
   2. Other is tree-shaken but is a crucial part of our SDK and is, thus, near impossible to untangle from our code. This only forms 10-15% of our SDK bundle size
   3. The rest of the size is of our proprietary code

Launch Tracker

No response

Notifications

/cc @ampproject/wg-approvers @jridgewell

[jridgewell]

Approved.