Intervention deep dive: start the 3s timeout for font-display: block when page load is starting

[Kenji Baheux]

Forking to discuss an intervention idea that came out of "bail out early from web fonts if we know that we'll hit the 3s timeout" (recommend reading for context).

tl;dr: I tried to walk through what the proposal would mean. My conclusion: this seems overly complex to grasp for a developer and IUC, this is targeting the future (font-display: block) = unknown. Shall we just wait to learn how it will be used and the performance implications before considering any intervention?

===============

Kinuko:

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

Bryan:

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

Ojan:

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

===============

I think that the rationale behind this intervention is that with some efforts, one can achieve the same rate of "text displayed with a web font" while minimizing the impact on page load by virtue of offsetting the timeout. Let's walk this through.

My interpretation

"when the page load is started"

A reasonable interpretation is probably: "as soon as the document owner has the opportunity to do something":

• on first bytes received (because one could use HTTP link rel=preload)
• on first bytes from body received (because one could use <link rel=preload> in head)

"3s timeout"

I imagine that in practice this would mean "3s OR ready to paint associated text, whichever comes last.

Afterall, there is no point in timing out if we are not ready to paint the associated text.

"if font-display: block is specified"

This pegs the UA into a mode that potentially limits its ability to optimize the user experience.

If one cares so much about a given font to the point where it can negatively impact the user experience, it seems fair to hold that person to higher standards when it comes to mitigate the downsides.

"Higher standards"

• use of Link rel=preload (HTTP or element) to kick the font request asap.
  
• reasonably small size => implies WOFF2 and subsetting

Perhaps, a simpler(?) alternative idea would be to use these signals to determine if it would be righteous to intervene:

• You are not even trying => intervene (3s timeout from page load start).
• You are doing your best, keep the existing 3s timeout.
  

Is this reasonable?

1. HTTP link rel=preload headers implies the ability to configure the server which might be tricky at times.
2. <link rel=preload> elements seems relatively reasonable.
3. expecting WOFF2 also seems reasonable (e.g. tooling is available, major font services all support it).
4. this assumes that 3s of network when the page load is starting is roughly equivalent to 3s of network after all render blocking assets have been dealt with (the point at which the UA decides which web fonts it will need). I'm not sure this is a fair assumption.
5. cons: losing the opportunity of doing dynamic subsetting (e.g. dynamic selection via unicode-range or dynamic subset generation via JS)

Edge cases

1. What about font-display: block fonts that are added/discovered later? Seems obviously wrong to base their timeouts around page load start.
• Exception to the rule?
2. Fonts in cross origin iframes: should have their own state.

Re: Ojan's comment "If we did this, maybe we don't need to do anything special for 2g/3g"

Originally, I think Kinuko's suggestion was explicitly targeting the font-display: block fonts that might impact Loading.

So we would still need the bailout early intervention for the other cases (no font-display specified, edge case #1...).

Expanding this to all web fonts would probably lead to bad outcomes (i.e. "preload all the fonts to get a chance to see them!" which will surely include unused fonts)

Conclusion

Overall, this feels complex (cf. edge case #1)?

Given that this is targeting the future font-display: block fonts, shall we just wait on learning how it will be used and its performance implications?

Thoughts?

[Dru Knox]

I think we may be looking at this in the wrong order. It's not that we want to ship font-display, then start intervening. A central piece of interventions is how they create a feedback loop that pushes the developer/ecosystem towards a better, more sustainable solution. In this case, that solution is using these font-display properties.

I think the process should be something like this: we start intervening now because 40% of font loads are timing out in EM and that's 3s we could get back for the user quickly and tactically. In the meantime, we use our coming reporting infrastructure to feedback to sites that their web fonts are being intervened, along with how to make them better. Eventually, we offer these font-display options as the escape hatch: if you don't want your fonts to be intervened, you can make sure they're well compressed, preloaded, and then set them to block. The goal, as it should be for most interventions, is that our intervening slowly fades into the light as the ecosystem improves.

Thoughts?

--
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/df88e440-d641-40a5-81e1-cc61c1f17346%40chromium.org.

--

-Dru

[Ilya Grigorik]

+1 to Dru's comments. 

My only quibble would be to start the interventions once font-display is available, not before. This way we have a clean story for developers: your site was causing users a lot of pain, hence the intervention and you should consider adding font-display: X to fix this.

Practically speaking though.. We still have some plumbing to do to get the intervention delivery stuff in place, so this all may be moot -- as in, we'll have font-display before said intervention?

ig

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

[Kenji Baheux]

On Thu, Oct 8, 2015, 6:31 AM Ilya Grigorik <igri...@google.com> wrote:

Practically speaking though.. We still have some plumbing to do to get the intervention delivery stuff in place, so this all may be moot -- as in, we'll have font-display before said intervention?

I think there is a spectrum of interventions. The bailing out intervention probably doesn't need to block on the intervention delivery stuff while the intervention on document.write (tbd) sounds much scarier and would probably benefits from a good intervention infra.

 

ig

On Wed, Oct 7, 2015 at 9:44 AM, 'Dru Knox' via intervention-dev <interven...@chromium.org> wrote:

Eventually, we offer these font-display options as the escape hatch: if you don't want your fonts to be intervened, you can make sure they're well compressed, preloaded, and then set them to block. The goal, as it should be for most interventions, is that our intervening slowly fades into the light as the ecosystem improves.

Thoughts?

Yes, that's basically one of the insight I noted while walking through the original idea:

Perhaps, a simpler(?) alternative idea would be to use these signals to determine if it would be righteous to intervene:

You are not even trying => intervene (3s timeout from page load start).

In other words, you ask for font-display: block but don't try hard enough (poor compression, no preloading), we should still intervene if the user experience can be made noticeably better.

 

You are doing your best, keep the existing 3s timeout.*

In other words, you ask for font-display: block and are doing the right things (good compression, preloading), we'll honour font-display: block because the user experience will be roughly as good as it gets.

* the spec specifies a timeout even in the block case, with 3s as a recommended value.

In fact, if we blindly honoured font-display: block we would be back to square one (loophole). 

That being said, I don't think we need to block anything on this particular intervention:

 1. ship font-display

 2. ship the bail out intervention

 3. [priority tbd] address the font-display: block loophole.

On Tue, Oct 6, 2015 at 11:59 PM Kenji Baheux <kenji...@chromium.org> wrote:

Forking to discuss an intervention idea that came out of "bail out early from web fonts if we know that we'll hit the 3s timeout" (recommend reading for context).

tl;dr: I tried to walk through what the proposal would mean. My conclusion: this seems overly complex to grasp for a developer and IUC, this is targeting the future (font-display: block) = unknown. Shall we just wait to learn how it will be used and the performance implications before considering any intervention?

===============

Kinuko:

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

Bryan:

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

Ojan:

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

===============

I think that the rationale behind this intervention is that with some efforts, one can achieve the same rate of "text displayed with a web font" while minimizing the impact on page load by virtue of offsetting the timeout. Let's walk this through.

My interpretation

"when the page load is started"

A reasonable interpretation is probably: "as soon as the document owner has the opportunity to do something":

on first bytes received (because one could use HTTP link rel=preload)on first bytes from body received (because one could use <link rel=preload> in head)

"3s timeout"

I imagine that in practice this would mean "3s OR ready to paint associated text, whichever comes last.

Afterall, there is no point in timing out if we are not ready to paint the associated text.

"if font-display: block is specified"

This pegs the UA into a mode that potentially limits its ability to optimize the user experience.

If one cares so much about a given font to the point where it can negatively impact the user experience, it seems fair to hold that person to higher standards when it comes to mitigate the downsides.

"Higher standards"

use of Link rel=preload (HTTP or element) to kick the font request asap.
reasonably small size => implies WOFF2 and subsetting

Perhaps, a simpler(?) alternative idea would be to use these signals to determine if it would be righteous to intervene:

You are not even trying => intervene (3s timeout from page load start).You are doing your best, keep the existing 3s timeout.

Is this reasonable?

HTTP link rel=preload headers implies the ability to configure the server which might be tricky at times.<link rel=preload> elements seems relatively reasonable.expecting WOFF2 also seems reasonable (e.g. tooling is available, major font services all support it).this assumes that 3s of network when the page load is starting is roughly equivalent to 3s of network after all render blocking assets have been dealt with (the point at which the UA decides which web fonts it will need). I'm not sure this is a fair assumption.cons: losing the opportunity of doing dynamic subsetting (e.g. dynamic selection via unicode-range or dynamic subset generation via JS)

Edge cases

What about font-display: block fonts that are added/discovered later? Seems obviously wrong to base their timeouts around page load start.Exception to the rule?Fonts in cross origin iframes: should have their own state.

[Takashi Toyoshima]

Hi, let me dig up the thread.

Kenji implied the three steps to ship the web font loading intervention. 

 1. ship font-display

 2. ship the bail out intervention

 3. [priority tbd] address the font-display: block loophole.

Now, ksamoaoto@ landed changes for font-display, the step 1 (crbug.com/530015), and I want to drive the step 2.

Basically, my suggestion does not violate the spec, but it would be worth having discussion here.

Design doc: https://docs.google.com/document/d/12yQa0eMhGPO-DDhLb8FCg8ss-MTt8JkTFgEJyoM_4uQ/edit?usp=sharing

This contains some feature plans like using cache information or something, but for now I'd focus on the first step, just using network information, e.g. connection type, and NQE results.

Also here is a link to a preliminary survey on font loading per each cellular network type. The design doc also includes the link, but it would be interesting for developers who ain't familiar to Web Fonts. 

https://docs.google.com/document/d/1f2tcvW72A9haFkCNsVhKgi1iteNrCRHYA7Y_uIautl4/edit

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

--

Takashi Toyoshima
Software Engineer, Google

[Kinuko Yasuda]

(+loading-dev@)

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