Bug 305636 – Google Fonts page loads extremely slowly in WebKit

• Status: NEW
• Component: Text

[Daniel Jalkut]

Created attachment 478042 [details]
Instruments trace of Safari's WebKit process loading the page

Loading the URL: 

https://fonts.google.com/noto/specimen/Noto+Color+Emoji

in Safari takes about 30 seconds on my M4 Max MacBook Pro.

Analysis under Instruments suggests the page's WebKit rendering process spends an inordinate amount of time in OTSVG, presumably handling OpenType-SVG fonts.

I'm attaching two Instruments traces. One of the Safari/WebKit web process, and one of the Brave/Chrome web process, each loading the same page. The Chrome renderer finishes in a fraction of a second.

[Daniel Jalkut]

Created attachment 478043 [details]
Instruments trace of Brave's Chrome process loading the page

[Radar WebKit Bug Importer]

<rdar://problem/168301160>

[Alexey Proskuryakov]

It's spending all the time in CTFontGetBoundingRectsFromGlyphs, executed via Element.offsetWidth() and Element.offsetLeft(). Creating a whole new SVG document each time.

When I tested this on my Mac, I saw an even worse issue after switching from this tab and back, it was hung in the same way, but in normal layout, not any JavaScript program.

[Simon Fraser (smfr)]

It's spending time CoreSVG, not WebKit's SVG code.

[Rod S]

> The Chrome renderer finishes in a fraction of a second.

It might not be using svg for Chrome. For context, Google Fonts will use COLR version 1 (https://learn.microsoft.com/en-us/typography/opentype/spec/colr) instead of using svg (https://learn.microsoft.com/en-us/typography/opentype/spec/svg) if it thinks the browser supports it. COLRv1 should be smaller and faster. Try requesting https://fonts.googleapis.com/css2?family=Noto+Color+Emoji, at the bottom it should tell you the selcted format, for example:

body {
  --google-font-color-notocoloremoji:colrv1;
}

[Daniel Jalkut]

(In reply to Rod S from comment #5)
> It might not be using svg for Chrome. For context, Google Fonts will use
> COLR version 1

Good thought. I did the test from Chrome and did see a colrv1 tag at the bottom as you suggested.

So I guess the question is whether the SVG is inherently slow or if this represents a performance improvement opportunity.