Intervention proposal: bail out early on web fonts if we know that we'll hit the font timeout

[Kenji Baheux]

Slow web font? Lemme intervene!

Blink temporarily gives up on a web font if it takes more than 3 seconds to download.

On 2G connections, Blink bails out on more than 40% of the web fonts requests (Android all types of connections: ~5%).

Assuming that we can predict such an outcome, it would be a better user experience if we fallback immediately.

In essence, we want to trigger CSS font-display: optional for users on slow connections if the web author didn’t specify any particular behavior.

Alternatively, CSS font-display: swap if font-adjust has been specified or if we can swap without impacting the user experience.

Tentatively filed as crbug.com/515343 (pending agreement on the proposal and availability of CSS font-display)

CSS font-display: see intent to implement.

[Dimitri Glazkov]

I think we should try this. What is our way to communicate this back to the developer?

:DG<

--
You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/c0827b42-3463-47cc-be5a-b17e0470cc90%40chromium.org.

[Dru Knox]

If the developer specified the font-display property, do we want to consider overriding it if it's blocking the page for a long time?

@Dimitri - We could potentially put something in a header that essentially says "slow connection, font-display will be set to optional". Alternatively, we could have some common reporting infrastructure for all interventions. Chrome could bundle all the interventions that trigger and send them to the site owner.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CADh5Ky0DiqTY2suBTZk_-9y5pmH1DdtyNdvtWCPMiu0Y1Ow%2Bcg%40mail.gmail.com.

[Ilya Grigorik]

On Friday, September 11, 2015 at 1:32:23 PM UTC-7, Dru wrote:

@Dimitri - We could potentially put something in a header that essentially says "slow connection, font-display will be set to optional". Alternatively, we could have some common reporting infrastructure for all interventions. Chrome could bundle all the interventions that trigger and send them to the site owner.

We might not have enough information upfront to know which interventions we might want to trigger. A trivial example is a user on a relatively fast connection that then gets blocked on a slow request (e.g. overloaded server, routing issues in the network, etc) for a critical asset. 

- If we know certain constraints ahead of time (budget, slow connection, etc), we should communicate that upfront to allow the server to do its best

- We should trigger interventions based on as-it-happens feedback (e.g. the page is ready to render after X seconds but we're blocked on a font that's yet to be dispatched.. bail), and then notify the origin that the intervention mode was triggered

On the subject of reporting infrastructure.. Do we have any existing sketches for this? We already have multiple overlapping but slightly different reporting implementations (CSP, Domain Reliability / NEL, Key Pinning), which I'd love to collapse into a single well-defined mechanism.

ig

[Dimitri Glazkov]

On Mon, Sep 14, 2015 at 11:29 AM, Ilya Grigorik <igri...@google.com> wrote:

On Friday, September 11, 2015 at 1:32:23 PM UTC-7, Dru wrote:

@Dimitri - We could potentially put something in a header that essentially says "slow connection, font-display will be set to optional". Alternatively, we could have some common reporting infrastructure for all interventions. Chrome could bundle all the interventions that trigger and send them to the site owner.

We might not have enough information upfront to know which interventions we might want to trigger. A trivial example is a user on a relatively fast connection that then gets blocked on a slow request (e.g. overloaded server, routing issues in the network, etc) for a critical asset. 

- If we know certain constraints ahead of time (budget, slow connection, etc), we should communicate that upfront to allow the server to do its best

- We should trigger interventions based on as-it-happens feedback (e.g. the page is ready to render after X seconds but we're blocked on a font that's yet to be dispatched.. bail), and then notify the origin that the intervention mode was triggered

Agreed. For the moment, I would like for us to focus on ahead-of-time interventions.

 

On the subject of reporting infrastructure.. Do we have any existing sketches for this? We already have multiple overlapping but slightly different reporting implementations (CSP, Domain Reliability / NEL, Key Pinning), which I'd love to collapse into a single well-defined mechanism.

+1! Would love ideas here.

:DG<

[Ilya Grigorik]

On Mon, Sep 14, 2015 at 12:15 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

On the subject of reporting infrastructure.. Do we have any existing sketches for this? We already have multiple overlapping but slightly different reporting implementations (CSP, Domain Reliability / NEL, Key Pinning), which I'd love to collapse into a single well-defined mechanism.

+1! Would love ideas here.

Hmm, ok.. let put together a doc :)

[Dru Knox]

+Jared Duke is also thinking about the design considerations for these kind of communal intervention infrastructures.

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CADXXVKps96LFfowyHpjf9JG2oR%2B%2BMcZ--wbdTES7uMXRno8h7g%40mail.gmail.com.

[Jared Duke]

Absolutely, assuming the needs and uses overlap sufficiently here, it'd be nice to avoid creating yet another reporting framework. Ilya let's set aside some time to chat offline about what the reporting system might look like. I'll put something on your calendar.

[Kenji Baheux]

If it works, I would like to be in that meeting too. I have some requirements for other ideas :)

[Ilya Grigorik]

On Wed, Sep 16, 2015 at 9:01 PM, Kenji Baheux <kenji...@chromium.org> wrote:

If it works, I would like to be in that meeting too. I have some requirements for other ideas :)

Added you to the invite. If anyone else wants to join, lmk. Tentatively: 22nd @ 3PM PST.

[Dru Knox]

I'd like to be included to keep up with any developments.

[Ilya Grigorik]

On Thu, Sep 17, 2015 at 2:44 PM, Dru Knox <dk...@chromium.org> wrote:

I'd like to be included to keep up with any developments.

Added.

[ja...@freshtilledsoil.com]

I'd like to keep up with this as well. I've long been in favor of displaying the fallback fonts right away and leveraging some kind of loading class to style the fallback fonts to avoid reflow. That has aways required using the web font loader but the actually styling of the fallbacks is very straightforward. Having font-display available in CSS would be fantastic; I'd love to see the default be 'fallback' and really encourage designers and devs to get it right with styling the fallbacks as well.

Jason

[Bryan McQuade]

+1 really looking forward to seeing both font-display and the related intervention move forward.

Some thoughts RE: Dru's question: "If the developer specified the font-display property, do we want to consider overriding it if it's blocking the page for a long time?":

* the longest time that a font can block is recommended to be 3 seconds, for font-display: block (if I understand the spec correctly)

* if we can predict that the user is likely to hit that timeout (as Kenji notes 40% of 2G users hit the 3s timeout), we should consider falling back immediately rather than making the user wait

In other words, for the intervention, we might want to have a similar policy for both font-display: auto and font-display: block: if we can predict that the user will hit the block timeout based on their current network characteristics, we fall back immediately rather than waiting.

WDYT?

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/05b6c852-e316-4ae0-bd19-6d98194e3c16%40chromium.org.

[Ilya Grigorik]

On Wed, Sep 30, 2015 at 6:23 PM, Bryan McQuade <bmcq...@chromium.org> wrote:

In other words, for the intervention, we might want to have a similar policy for both font-display: auto and font-display: block: if we can predict that the user will hit the block timeout based on their current network characteristics, we fall back immediately rather than waiting.

WDYT?

Sounds reasonable. I'm assuming the estimate would be driven by NQE, based on RTT and other signals?

[Bryan McQuade]

Yeah, using NQE estimated RTT is my thinking as well.

[Kinuko Yasuda]

Hi,

(Just catching up with this thread, wasn't really following this list!)

If we're discussing this regularly I'd like to be included too, though I may not be able to attend regularly.

Reg: performing intervention when font-display is actually specified:

I don't feel really sure about falling back immediately if a site specifies font-display: block, because the policy seems pretty intentional and explicit that the site wants to wait as reasonably long time as possible until the target font is downloaded.  I was assuming that supporting font-display options was for providing (one of the) ways for site owners to stop/control user agent intervention, but things discussed here doesn't seem it's not necessarily be true.  (Having said that I could also understand just waiting for hitting timeout feels a bit wasting)

Some random thoughts on this particular intervention:

- If font-display: block is specified I'd expect UA waits at least for some secs before showing fallback font. For this one I like the idea of waiting for 3 secs but not from when the font load is started but from when the page load is started (so that if user already waited for long s/he doesn't need to wait further), way: fall back sooner on slow network but not on fast network.

- If the font is in disk cache we probably wouldn't want to fall back immediately even if we're on slow network because it could lead to very short swap period, or UA may choose not to use the font even if it's on local disk. On the other hand if we're on really slow network we may want to completely avoid dispatching font loading request, but only if they're not on local cache.  It feels it might be useful if we could use some knowledge about cache status (in addition to NQE etc) for making loading decisions.  (For implementation I'm wondering if using something like bloomfilter could help)

--

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

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

[Bryan McQuade]

Thanks Kinuko. Not applying the intervention when a non-default font-display is specified SGTM. I do want to keep that option on the table longer term, but I agree that it's unclear if that's the right thing, so let's defer that aspect for now. Landing font-display and then applying the intervention when font-display is not 'auto' sounds good to me.

+1 to not waiting more than 3s from page load rather than 3s from font load.

Agree with avoiding fallback when the font is in disk cache.

[Ojan Vafai]

On Fri, Oct 2, 2015 at 6:10 AM Bryan McQuade <bmcq...@chromium.org> wrote:

Thanks Kinuko. Not applying the intervention when a non-default font-display is specified SGTM. I do want to keep that option on the table longer term, but I agree that it's unclear if that's the right thing, so let's defer that aspect for now. Landing font-display and then applying the intervention when font-display is not 'auto' sounds good to me.

+1 to not waiting more than 3s from page load rather than 3s from font load.

If we did this, maybe we don't need to do anything special for 2g/3g?

 

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