Web Fonts Working Group Teleconference -- 17 Aug 2020

<Vlad> scribenick: Garret

myles: this is updated numbers from the new data set.
... shape of the data is the same as previous one.
... different data set and set of fonts.
... 30% english 30% vietnamese 11% japanese and a bunch of latin scripts.
... here are the new and updated numbers
... little bit of disclaimer, this is based on a 1% sampling.
... in an email I sent last night the patch subset method was failing on some of the fonts.
... so the 10% sample didn't run.
... gathered data on a .1% and 1% and the numbers where nearly identical.
... left is all, middle is CJK, and right Chinese
... range request optimal pretends the font has been perfectly optimized
... everything happens to be downloaded in one range rquest
... suboptimal range request is a similar idea. All glyphs are next to each other but not ncessarily. The difference between the bars is the addition of an extra round trip. Wanted to understand how fast we could go.
... the real range request is better than the two optimal ones
... turns out the glyphs you need are scattered. What ends up happening is that when you download two glyphs and get extra glyphs in between it ends up being cheaper.
... turns out the middle glyphs are a poor mans prediction for glyphs needed for the next page.
... was cheaper to grab nearby glyphs oppurtunistically.
... this implies that prediction is beneficial.
... for range request it would be helpful, but not as helpful since it's already doing poor mans prediction.
... range request better then patch subset.
... for 3G range request is worse than patch subset.
...
... made a graph of all network configurations.
... for slowest connections range request is best.
... for middle connections patch subset is better.
... for JP range request does pretty much the same as patch subset.
... for 3G similar story patch subset does really well, range request in the middle.
... same for chinese.
... for 3G patch subset does very well, range request in the middle.
... now bytes, hear patch subset does well. Range request is in the middle. Did include different measurements for idfferent network configs. Since range request is now sensitive to network config.
... so range request bars different between the top and bottom graphs.
... CJK and Chinese are similar.
... last one which is total time. For every page load you run the time taken for font loading and sum it up.
... cost function benefits many small loads. Whole font is better than patch subset since it does one rtt to the server.
... and one rtt is pretty expensive.
... so whole font competes reasonably with the rest.
... range request does better.
... for 3G patch subset does better then whole font, but by less.
... for CJK the bars are all somewhat close together now. Same for 3G.
... same deal for chinese.
... that's all the data I have gathered.
... probably close to the final numbers
... let me talk about what we do next
... some places where patch subset is better.
... places where range request is in the middle but is not as good as patch subset.
... need to consider the non-performance aspects.
... patch subset requires a server and large compilation.
... both the open type and ttf spec recommend table orderings. Biggest table at the end.
... which means that for many fonts glyph table will already be at the end.
... same for CFF.
... there's a bunch of fonts that are already optimized, so the website using them they don't have to do anything.
... so it seems natural for a website to just enabled streaming.
... to be fair patch subset does better in most situations.
... what we've shown is that the patch subset method will gather necessary characters and reply with those.
... so there are some common and uncommon characters.
... the uncommon characters can't be sorted well.
... so pulling the exact chars plus the common set works well.
... you do get better results when you sort these files.
... so this leads down to a natural path. simpe things simple, complex things possible.
... big font companies can serve with a patch subset approach. However for the non big font companies it's much easier to just drop a font into your existing infrastucture.
... this leads me to think about co-existence. There is two methods that could be used by websites via opt-in.
... I think that opt-in will be needed since loading will be so different.
... which may break websites. This is true for both methods.
... so opt-in mechanisms.
... two possible ways. Adding a new descriptor into the font face rule. Ignored for old, new browsers would recognize.
... or another way. A JS api that interacts with font loading api.
... a callback the browser would call when the set of chars changes. Would deliver a mapping of fonts to characters. JS would issue it's own request and apply the binary diff and then use the CSS font loading api to deliver to the browser.
... not yet ready to discuss which is the best.
... both of these options are reasonable. Make sense for big font companies.
... serving a JS library is not unreasonable. Could be integrated with a service worker. So multiple things could re-use the library.
... for range request I don't think JS is appropriate. Since this method is best suited for every website. Asking all sites to include JS is a different value prop.
... so there's only one method of opt-in, the new descriptor in the font-face rule.
... if we used font-face descriptor for both. The behaviour of adding the descriptor will change the font loading timeline. Many fonts will already support range request and many servers already support range request.
... so if we're using a descriptor to enable streaming it doesn't need to specify which method.
... the browser could choose which method to use.
... servers already support these things.
... streaming is a function of the resource requests.
... the overall summary sometimes range request is better, usually patch subset is better. Both are better then unicode range and almost always better then whole font.
... should move to simplethings simple, complex possible

vlad: one comment wish for near future discussion
... hear you saying things in favour of do all approaches.
... in the past I expressed concerns with any approaches that give too many options.
... sometimes two options is one too many.
... in practice users who are not as well informed as experts are faced with a choice, they forgo to make the choice at all.
... when it comes to standardization, would be ideal to avoid having users having to make choices.

myles: I agree, but I think this is a case where the two approaches are different enough. It's a problem where one size does not fit all. The patch subset method are better enough then the range request method that I can't honestly say that range request should be used.
... but can't make the inverse argument either.
... because thats a solution where many websites can't use that technology.
... you're right we shouldhave on solution, but I don't think either method is good enough that we should recommend one over the other.

ned: we're in agreemtn what a perfect world would be, but I think in this case the dual approach is wy to go. Not everyone has the resources to provision a special server.
... need to recognize the people using services are not technologically inclined. So having a fallback solution to the alternate approach which doesn't require configuring.
... we don't want people running comparisons on which they should do. People will see the opt-in flag.
... even if someone sets the flag and the font is prepared or configured correctly, they won't get nothing.
... flag allows an improvment to the current situation withouth negative consequences if it doesn't work out.
... I agree that there's a small burden in making a choice.
... but for the flexibility of the web its good to have something less reliant on a service.

jason: do we have any sense yet. If we want to support patch subset?
... via an apache module
... like the fallback model, if you're signalling that you'd like it to stream.
... I think that the reason I wanted to call those things out. If I'm understanding the data correctly. You were showing on the slowest connection patch/subset had the higher cost.

myles: the word cost is not correct, I think you're looking at time. The total time was higher, but not the cost metric.
... the cost metric benefits many small loads.

jason: on the slowest network connections patch subset will feel better most of the time. We're doing a ton of analysis that's valuable, but the ultimate test is what does it feel like for users.
... my hope is that what we're angling towards.
... if that's something that can be reasonably done with a module. You have to add that, but other services will eventually add it.
... in real world use this will be a game changer for slowest connections. Want to make sure that the most you have to do is add a line to your @font-face and things will get better.

myles: packaging as a module is reasonable.
... still code running in the server.

vlad: couple of points, it could be standardized in a way the user needs to be a choice an opt-in. The method used is not user specified but defined by the infrastructure.
... second important aspect is the ultimate goal is to improve user experience.

garret: cost function is designed as a proxy of user experience.

vlad: What I mean is the first page render time.

ned: best first page load doesn't involve webfonts.
... there's a reason we don't see huge webfont takeup in asia since those fonts are really big and there's already good fonts on device.

jason: that's a fair point. Anybody who speaks about web performance is going to agree in a european context.
... in selling this to browsers in the general public. We want to show in any case and any language what does it look like. The current options for CJK is to use a service that is doing a subset for you or do nothing at all.
... we want to show this is a way to do better and outperform existing services.
... that first render is a good way to show that.

ned: thanks for clarifying. I think either approach will accrue benefits over current approaches.
... jason has identified a good example of the sales pitch of how this can be benficial.

vlad: what jason outlined is the environment where all the authors have to do is update font-face. and then based on what modules/servers are avialble. I like that since the user then doesn't need to worry about things.
... more complex implementation in browsers will be harder to sell, so we'll want some good hard data showing that.

myles: I believe that's what my data shows.

vlad: I think that what's missing is the page load times.

garret: I think what you're looking for is the distribution of per page load times vs. the total.

jason: I think the totals are underselling the difference.

<Vlad> +1 to what Jason just said!

jason: I've been accumulating a couple of really good case studys of variable fonts vs static
... replaced 8 static fonts with one and render times came done.
... we're planning on doing something even more significant.
... I think that will be a significant attention getting detail.

- DRAFT -

Web Fonts Working Group Teleconference

17 Aug 2020

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output