Webfont dividida em vários arquivos deixa o layout de texto lento; veja como resolver

O problema vem de como o cn-font-split (versão 7.4.3, com as configurações padrão, rodando na Noto Sans SC) corta a fonte. Ele gera 293 arquivos, e os 95 caracteres do latim básico (U+20 a U+7E) caem em dois deles. O menor guarda 11 caracteres, entre eles o i e o j. Resultado: uma palavra como "injection" troca de arquivo cinco vezes em nove letras.

O custo está no shaping. Segundo o autor, que leu o código do Chromium (harfbuzz_shaper.cc), o shaper trabalha uma fonte por vez e joga o que não consegue desenhar numa fila para a próxima. Cada arquivo da fonte dividida conta como uma fonte própria. No teste com 40 parágrafos em inglês, no Chrome com CPU 4x mais lenta, dois arquivos custaram cerca de 1,5 vez o tempo de um, e três arquivos cerca de o dobro. O WebKit mostra o mesmo padrão. Nas páginas em árabe, a webfont tinha só o espaço, então espaços vinham dela e letras de uma fonte de sistema. No macOS, mesmo sem a webfont, o sans-serif entregou Helvetica para espaços e Geeza Pro para letras.

Há também a ordem das regras @font-face. A especificação CSS Fonts manda checar primeiro a última regra definida quando os unicode-range se sobrepõem. A primeira correção do autor, com um arquivo latino limpo declarado antes, deixou o layout várias vezes mais lento. Mover a regra para o fim resolveu. Ele não isolou a causa no site real, e ressalva que não tem dados de campo de INP nem testou em celular de verdade.

Para quem opera sites com fonte CJK fatiada, a leitura é que o INP ruim pode não vir de JavaScript, e sim de layout. Vale auditar o CSS gerado pelo fatiador antes de culpar o código da aplicação. O risco é maior em sites multilíngues, onde a fonte de um script vaza para outro.