Intent to Ship: Deprecate module size limit for WebAssembly.Module()

[Andreas Haas]

Contact emails

ah...@google.com

Explainer

None

Specification

None

Summary

There exists a limit on the size of a module that can be compiled with `new WebAssembly.Module()` on the main thread. This limit is 4KB, and it was introduced when WebAssembly modules got compiled eagerly with an optimizing compiler, which could block the main thread for many seconds and even minutes. In the meantime V8 launched lazy compilation for WebAssembly modules, and the execution time of `new WebAssembly.Module()` is below 1 second even for the biggest modules we see, even on the weakest devices we measured. Therefore it is time to remove this limit.

Blink component

Blink>JavaScript>WebAssembly

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Strongly positive We received repeated bug reports because of this limit. Especially for tests synchronous compilation with `new WebAssembly.Module()` is useful, but the size limit prevents bigger tests from using synchronous compilation.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

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

Yes

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

114

Shipping on Android

114

Shipping on WebView

114

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5080569152536576

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

--

Andreas Haas

Software Engineer

ah...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Daniel Bratell]

LGTM1

This doesn't show up in our chromestatus UI. Have you sent if for "shipping" there? If no further comments arrive, it may be that it has fallen off our radar because of that.

/Daniel

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTve0zdDNeCDXvG%3D73-zVy8Fps_9eFErWfOocSfxbzOxGHQ%40mail.gmail.com.

[Yoav Weiss]

Is it interoperably tested by other means? I'm not super familiar with WASM testing..

 

[Andreas Haas]

Hi Yoav,

I'm not sure what you mean. At the moment this 4KB limit exists in Chrome, but it does not exist in Safari or Firefox. I tested this locally on my Macbook. I don't know if there exists another test at the moment which passes on Safari and Firefox but fails on Chrome, and would pass on Chrome after we remove the limit.

Cheers, Andreas

[Alex Russell]

"Below 1 second" for something that can block the main thread is not particularly heartening. Can you please provide the histogram data you're seeing to justify this? Would you be happy to raise the cap to a larger (but still fixed) size based on a baseline device config instead?, e.g.:

https://infrequently.org/2022/12/performance-baseline-2023/

Best,

Alex

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTve0zdDNeCDXvG%3D73-zVy8Fps_9eFErWfOocSfxbzOxGHQ%40mail.gmail.com.

[Andreas Haas]

Hi Alex,

Here are the performance numbers that I collected: https://docs.google.com/document/d/1hOGwCurQmPF_GZdflsJno286sJXgfoLeOGaUhZuMzCQ/edit?usp=sharing

I think the question is more, how can we justify such a limit? I mean, I agree, it is not a good experience if the main thread is blocked for 1 second, but we have to consider the scenario in which this is happening. The main thread is blocked for one second after a WebAssembly module was downloaded which is tens of megabytes big.

Additionally, in the current environment it is not likely that you end up serving a big WebAssembly module to the user with synchronous compilation by accident. WebAssembly modules are typically generated by compilers which also generate the JS glue code around it. These compilers produce glue code that uses asynchronous compilation or even streaming compilation. Therefore a developer would have to make an effort to even serve a big WebAssembly module with synchronous compilation.

There are scenarios where developers make this effort, and I don't think we should prevent developers when they make this conscious decision. One such scenario is tests. It is much easier to write and run tests with synchronous compilation. We run nearly all our WebAssembly tests in V8 with synchronous compilation. We also got bug reports repeatedly where developers struggle with their tests because of the 4KB limit.

So overall I think the limit was justified in the beginning, but now with lazy compilation and baseline compilation this justification is gone. I don't think this limit makes the web a better place anymore, it just makes the life of developers difficult in specific niche situations.

Cheers, Andreas

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTve0zdDNeCDXvG%3D73-zVy8Fps_9eFErWfOocSfxbzOxGHQ%40mail.gmail.com.

--

Andreas Haas

Software Engineer

ah...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Ian Kilpatrick]

Out of curiosity - 

What is performance like on a low tier Android phone (I see only a Pixel 7 tested above)?

What is the performance of your benchmark on other browsers - across device classes? (Even if they don't have this limit - this intent will mean that it'll be interoperable to use the sync method - potentially causing compat problems for the other browsers).

Ian

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvcq5b4gz6U3SYBjPkU1jCZtaPnNZr9tDsD8fZxG7w8Hvg%40mail.gmail.com.

[Andreas Haas]

Hi Ian,

Here is the benchmark: x20.corp.google.com/users/ah/ahaas/index.html

You need corp access for it, and I didn't have access to low tier Android phones with corp access.

Safari also compiles lazily, so their compile times are similar to ours. Firefox compiles modules eagerly, and therefore takes longer. I don't really have the devices or the setup to do the measurements on other browsers. I measured the performance of Firefox on my workstation, where the compilation of the 80MB module takes slightly less than 1.6 seconds. This is about 60% slower than Chrome with eager compilation. I tried Chrome with eager compilation on the atlas Chromebook. Compilation of the 80MB module takes 2.8 seconds there.

Cheers, Andreas

[Philip Jägenstedt]

Hey Andreas,

Do you know what the limits of other browsers are? If testing a 1 GB module is too slow to be reliable (sometimes timing out) then perhaps there's a large-ish module you can test with that still exceeds the current limits?

Note that you could also add a manual test in WPT for the real limit (1 GB) and run it at least once manually to ensure it works the same in all browsers.

Best regards,

Philip

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvfdj1exWfsUYs4RjbSc7WOTTpNyb1aXCA0R3uPQzCci6w%40mail.gmail.com.

[Andreas Haas]

Hi Philip, Yoav,

I added a test to the wasm spec tests now, see https://github.com/WebAssembly/spec/pull/1642. It creates modules of size 1GB and 1GB+1 and checks that compilation passes or fails, respectively. The modules consist of a single custom section, so that minimal processing time and module creation time should be introduced.

As far as I know, the other browsers never had a special limit on the module size, other than the spec'ed 1GB limit. I confirmed that now with Firefox.

Cheers, Andreas

[Yoav Weiss]

LGTM2

Thanks for testing this! :)

[Alex Russell]

Thanks for the document, Andreas.

The numbers in it are still hugely concerning, and I'm a -1 until and unless we have data from P75-P90 Androids and Windows devices. Our telemetry from Edge shows that nearly half of users are on slow, spinning rust and 2-4 core devices, and the only system in your test list that reflects something in this range is the N2840 in the HP Chromebook 13 G1.

Motivations in the document regarding testing are not compelling. Folks doing testing can provide flags to the browser (which you could expose to raise the limit without an Intent).

Would you be willing to accept a higher cap? Your document suggests that ~10MiB (unzipped) might be reasonable, but would want to see data from low-end Android before going even that far.

Thanks.

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvcq5b4gz6U3SYBjPkU1jCZtaPnNZr9tDsD8fZxG7w8Hvg%40mail.gmail.com.

--

Andreas Haas

Software Engineer

ah...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvfdj1exWfsUYs4RjbSc7WOTTpNyb1aXCA0R3uPQzCci6w%40mail.gmail.com.

[Andreas Haas]

Hi Alex,

I will try to organize a low-end device to do the measurements you are asking for. Could you please describe how the results would guide your decision on this issue?

I would also ask you to clarify your concerns. What are the scenarios you have in mind, and what are the improvements a user would get from this limit?

When I think of concrete scenarios, then I end up either with the scenario being unlikely, or that the limit would not make a big difference for the user experience:

* Unlikely, because it is hard to end up with a big WebAssembly module that you compile synchronously. You don't write WebAssembly modules by hand, you generate them with a compiler like Emscripten. The compiler typically does not only generate the WebAssembly module for you, it also generates the code for you that downloads and compiles the WebAssembly module. A scenario where the limit may matter is that the compiler decides to use synchronous compilation instead of asynchronous compilation. However, why would the compiler do that?

    * Because synchronous compilation provides benefits? What would these benefits be? The WebAssembly module already gets downloaded asynchronously, so continuing with synchronous compilation has no advantage to asynchronous compilation.

    * By accident, because the compiler writer does not know better? I think it's unlikely that a compiler writer would choose to use synchronous compilation by accident, and that this compiler is then used to produce a WebAssembly module with 10s of MB, and that the resulting WebAssembly module is then used in any reasonable webpage.

* The limit would not make a difference for the following reason: On the website you cite above the average network bandwidth is 9Mbps. Even compressed the 80MB module in my measurements would take 10s of seconds to download. Does blocking the main thread of less than 1 second really matter to the user after they waited many times as long for the download?

As I wrote before, I understand why this limit was introduced originally. However, these reasons don't exist anymore, and all that remains is a spec violation, see https://webassembly.github.io/spec/js-api/index.html#limits. Even a limit of 10MB is still a spec violation, and as I wrote before, I don't see any justification for that.

Cheers, Andreas

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvcq5b4gz6U3SYBjPkU1jCZtaPnNZr9tDsD8fZxG7w8Hvg%40mail.gmail.com.

--

Andreas Haas

Software Engineer

ah...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvfdj1exWfsUYs4RjbSc7WOTTpNyb1aXCA0R3uPQzCci6w%40mail.gmail.com.

--

Andreas Haas

Software Engineer

ah...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[K. Moon]

I don't have any authority here, but my two cents: Given there's a synchronous and an asynchronous API already, why not let the page author decide the right trade-off for themselves? I know in general we'd like to discourage authors from blocking the renderer main thread, but there already seem to be plenty of incentives not to do that already, and the well-lit paths don't encourage large synchronous compilations. It'd be different if this somehow required blocking the browser main thread, of course.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvc6QoyFWYAhsCh9eSvOvpu0JpgEPSn2UuKLZRNOKsyAGg%40mail.gmail.com.

[Alex Russell]

  Hey Andreas,

First, I deeply appreciate your willingness to do the work to get us data.

I'm generally interested in understanding the potential for modules to create main-thread jank. If we accept the CWV INP threshold of ~200ms, would like to make sure that for the vast majority of users (P90? P95?) don't hit synchronous operations longer than that. So the question about sizing is relative to that goal.

Put differently, if we raise the limit to XMB vs. YMB, and developers begin to develop to that new threshold, how much jank can this introduce?

As for "does blocking the main thread for 1s really matter?", all I can tell you is that this project has worked diligently for more than a decade to try to eliminate sources of main-thread jank. It would be surprising if we relaxed that goal for this specific feature.

Best,

Alex

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvcq5b4gz6U3SYBjPkU1jCZtaPnNZr9tDsD8fZxG7w8Hvg%40mail.gmail.com.

--

Andreas Haas

Software Engineer

ah...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

--
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.

[Andy Wingo]

Hi,

Just a note about use-cases:

On Fri 21 Apr 2023 13:47, "'Andreas Haas' via blink-dev" <blin...@chromium.org> writes:

> * You don't write WebAssembly modules by hand, you generate them with
> a compiler like Emscripten.

The WebAssembly module itself may well generate, compile, and
instantiate a module -- a form of JIT code generation. See
https://wingolog.org/archives/2022/08/18/just-in-time-code-generation-within-webassembly
for a longer discussion. Probably at some point there will be a
WebAssembly proposal to address this use case.

Sometimes synchronous compilation can be useful for the JIT use case,
for example so you can embed pointers to linear memory in the generated
module and be sure they are still valid by the time the generated module
runs. Of course, generally you would still want to design for
asynchronous compilation to avoid blocking the main loop, but in
development at least it's nice that synchronous instantiation is
possible.

Regards,

Andy

[Andreas Haas]

Hi Alex,

Here are the performance measurements you requested on some Android phones I found.

size		Nokia 1	Pixel	Pixel 2	Pixel 3	Pixel 7
713	B	4.57ms	2.96ms	1.46ms	0.47ms	0.22ms
25.92	KB	5.54ms	3.79ms	1.44ms	1.77ms	0.98ms
35.12	KB	86.39ms	46.52ms	16.32ms	13.17ms	8.70ms
249.84	KB	13.99ms	7.53ms	3.17ms	3.27ms	2.16ms
294.95	KB	14.70ms	8.02ms	3.86ms	3.23ms	2.34ms
378.2	KB	18.61ms	10.56ms	7.06ms	4.83ms	4.48ms
768.98	KB	78.11ms	38.79ms	28.45ms	18.43ms	5.70ms
1.26	MB	45.29ms	22.59ms	18.35ms	7.20ms	5.20ms
2.89	MB	89.30ms	35.56ms	32.37ms	13.77ms	11.06ms
3.28	MB	215.52ms	83.29ms	84.42ms	32.57ms	21.96ms
6.65	MB	127.58ms	59.96ms	42.95ms	22.00ms	16.34ms
8.9	MB	398.86ms	218.55ms	114.45ms	49.70ms	42.54ms
10.08	MB	535.84ms	281.89ms	144.76ms	65.43ms	53.22ms
13.56	MB	327.44ms	136.32ms	87.69ms	51.83ms	44.26ms
19.12	MB	504.83ms	232.17ms	133.18ms	88.73ms	75.36ms
34.54	MB	1541.58ms	910.30ms	423.14ms	261.57ms	275.40ms
60.37	MB	OOM	609.99ms	307.16ms	219.67ms	183.00ms
63.77	MB	1491.76ms	735.30ms	360.98ms	214.80ms	168.56ms
64.08	MB	1473.18ms	727.87ms	350.73ms	251.27ms	180.56ms
67.41	MB	1499.28ms	809.60ms	380.74ms	298.00ms	228.82ms
83.26	MB	OOM	708.36ms	384.34ms	272.90ms

As far as I understand the discussion here there are worries that if we remove this limit, then the user experience will regress, especially on low-end devices.

On the other hand, my goal with this proposal is to improve the developer experience.

Additionally I want to mention that this limit on synchronous WebAssembly compilation is an inconsistency in the web platform, and a violation of the WebAssembly standard which recommends a maximum WebAssembly module size of 1GB. In principle we should implement the standard, and if we don't agree with the standard, then we should work on changing the standard and not ignore it.

Back to user experience vs developer experience. I think for both sides this limit does not make a big difference. Developers will use asynchronous compilation anyways because that's what to-WebAssembly compilers generate automatically. Also, typically a WebAssembly module has to be downloaded first, and with the `WebAssembly.compileStreaming()` API there exists a tool that allows you to download and compile a WebAssembly module at the same time. So in the typical scenario where you first download a WebAssembly module and then you compile it, synchronous WebAssembly compilation does not provide any benefits to the developer, and it is also not the default. So developers would only decide consciously in special situations to use synchronous compilation.

So which scenarios would cause a bad user experience?

A bad user experience would be if the main thread is blocked repeatedly for longer amounts of time, or at bad moments in time like during an animation. 

Now, WebAssembly module compilation takes time because new code gets provided to the web page. However, there is only so much code you want to load in your web page, especially code in modules that are bigger than 1MB. So the chance that the main thread gets blocked repeatedly for longer amounts of time is low.

So what about jank during animations? If we look at JavaScript, then JavaScript code gets typically loaded in one big script, or in many small scripts. The big script gets loaded during the startup of a web page, small scripts may get loaded over time. For WebAssembly it is the same so far, and will probably stay the same: big modules get loaded during the startup of a web page, only smaller modules would get loaded later. During page startup, users are used to waiting a bit for the page to start up, to load data from the server and to execute initialization code. Jank introduced by synchronous WebAssembly compilation would only be a small part during startup. Note that downloading the big WebAssembly module takes typically much longer than compiling it.

To sum up, jank introduced by synchronous WebAssembly compilation would either happen during page startup where it's dominated by other delays like the much longer module download. Small modules may also get compiled later, but then the introduced jank would be small because the module is small.

Then, how does the limit make the developer experience bad?

First, as mentioned above, the limit is an inconsistency in the web platform and a violation of the WebAssembly standard. Inconsistencies in the web platform are known as big developer pain points, and the bug reports we got about this limit show the same.

Second, there are special scenarios where synchronous compilation has advantages. I already mentioned testing, where the order in which you compile and execute tests is important. Saying that developers should just set special browser flags to disable the limit sounds arrogant to me. You want to test your code in an as realistic context as possible, as all special configurations of the testing setup may lead to missed bugs.

But there are also other situations, especially for experimental projects where synchronous compilation could make things easier, like the JIT compiler that Andy Wingo mentioned.

There is also the situation where you would like to add a custom section to your WebAssembly module which supports debugging. One example would be a name section that can be loaded by DevTools. This custom section would not change the compile time at all because custom sections get ignored by the WebAssembly engine. For the developer this custom section can be very valuable, but also very big. It would be a big developer pain point if the developer has a module which is far below the limit in release mode, but with the debugging information in the custom section the module would be bigger than the limit, and they would not be able anymore to run their web page, at least not in Blink.

To sum up, the web developers only notice the limit in very specific scenarios, but when they do, the limit is surprising and a big developer pain point.

So overall I don't think this limit matters for most users or developers, but in the cases where it matters it is much more painful for the developer than for the user.

To answer to your email specifically:

I don't think that the CWV INP threshold is a good guideline here, because, as I mentioned above, the main-thread jank caused by WebAssembly compilation is likely to happen when it matters less, and when it's dominated by other delays like the module download.

Cheers, Andreas

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

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

To view this discussion on the web visit https: