Weird Issues on CLS with webfont

[王康文]

Hi 

I am an engineer for a news media website. While recently reviewing CLS issues, I discovered that when using the web font "Noto Sans" (Source Han Sans), specific characters like quotation marks "「」" will cause CLS problems.

A bit difficult to explain, please use the following URL and  tool for testing.  I've attached the URL and saved tracing JSON data for viewing.

Link:  https://udn.com/upf/static/common/cls-bracket.html 

Tools used:
Chrome 134, Performance Tab

Simulation status:
Mobile with iPhone XR size (414*896)

Description of the situation:
The issue occurs when text encounters specific symbols and needs to be wrapped due to width constraints. While managing news content, we found that in certain specific situations, during the rendering process of text with web fonts, when encountering insufficient width, chrome tends to adjust the spacing between characters above and below. This indirectly triggers CLS layout shifting problems.

This issue seems unreasonable because the text itself is dynamic, and we cannot set different properties for different text at each different CSS breakpoint. Please review this issue and advise if there's a better solution.

From the test URL, you can see that the first and second paragraphs contain the same text. The difference is that in the second paragraph, a line break character has been added after the text "視覺智慧," which causes the CLS issue. This issue only occurs on devices with exactly 414px width. Please ensure to use the same device simulation for testing.

[Barry Pollard]

Hi,

Yes fonts can cause noticeable shifts to users, and hence CLS does (and should!) take any such shifts into account when calculating CLS.

There are various techniques to reduce the shifts, though as you've discovered this gets more complicated when it's only one or two glyphs that are the main causes of shifts. I tried a few things and can solve the 414 x 896 case, but then other sizes start to cause problems.

The main CLS seems to be the difference between your "黑體-繁" font and the real font. The other fallbacks do not seem to cause as much CLS. I don't know enough about Japanese fonts but is this font needed? Is it in the right order?

I do note the CLS reported for "黑體-繁" seems very high, compared to the amount of shifts I'm noticing with my eye when I remove that font. That seems strange and it may be worth raising a bug at crbug.com/new for the font experts to explain this.

Thanks,

Barry

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/7183cbfc-cc6f-4a94-b708-d8690ab51482n%40googlegroups.com.

[王康文]

Thanks Barry for fast response on this issues.

Thanks for bringing out fallback font might be the cause of this issues, but from our investigation, I don't think it's a problem with the "黑體-繁" font  (or might be not the direct causes in our current example),  though this is necessary in our fallback font, which is provided for iOS or macOS platforms.

I've attached another example link where I simplified the fallback font, simply locking the fallback Traditional Chinese glyphs to the Microsoft platform, with the same simulation devices as above to check and the problem still exists.

From observations, it's basically caused by simply using web fonts, but for pages with relatively more text, this is a disaster for our engineering team.
I'm also unsure if removing web fonts is necessary to solve the CLS issue.
However, this problem showed a significant upward trend in batches around mid-February, which might be related to adjustments in web vitals metrics on that timeline?

Thanks

[Barry Pollard]

Ah I get different responses when testing it locally in DevTools. Your latest link has very small CLS in that. However when I run it though PageSpeed Insights I do see large CLS. So yes it very much depends on specific screen sizes.

As I said, this does look like a bug to me. There is a large amount of CLS measured by the APIs, but that is not so apparent visually where there's only a small shift. I'm not aware of any changes in February but am not that close to the font stack. Could you raise a bug at crbug.com/new with the examples you have so this can be routed to the font CLS experts?

As far as the feedback here goes, as I said in my first reply, we do measure all shifts, no matter whether it's easy to fix or not. But they should be representative of the shifts actually seen by the eye. And that doesn't look to be the case here. So this is definitely not the intent of the metric and so I'd consider it a bug.

To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/ee8981b2-30df-4469-a106-f7bcf5a15654n%40googlegroups.com.

[王康文]

Thanks Barry for your feedback, 

it was a valuable thought on this issue. I've created an issue on crbug and for those who are interested to track this issue, please follow this link: https://issues.chromium.org/issues/406023319

Thanks
kangwen