优化Web字体而不改变渲染效果

让这个网站的网页字体加载更快，但不改变任何外观。尽可能缩小字体字节数，保持渲染完全一致，并用前后像素差异来证明。除非我批准，否则任何视觉变化都视为回归。如果某项优化会改变渲染，告诉我它节省了什么、改变了什么，并默认保持网站外观不变。保持当前的加载行为：不要改动font-display或回退字体。不要向构建流程添加字体处理；写一个我手动运行的脚本，提交其输出，并注明何时需要重新运行。首先测量当前状态：每个字体文件的大小、字形数量、可变轴、OpenType特性和提示信息，以及每个页面的字体字节数和每个页面预加载的内容。然后找出网站实际使用的内容，检查内联组件样式以及样式表：内容中出现了哪些字符，每种字体需要哪些轴值和字重（包括一次性覆盖和斜体中的粗体），启用了哪些OpenType特性，以及CSS副作用如`hyphens: auto`使用U+2010连字符。将每个字体裁剪到该范围。保留使用的字符以及Latin-1和Latin Extended-A，如果今天就是这样渲染的，将CJK留给系统字体。将可变轴限制在使用范围内，并且只有在没有覆盖的情况下才将轴固定为一个值。删除未使用的OpenType特性和提示信息。将每个字体拆分为两个文件。一个包含ASCII和大多数页面使用的标点（弯引号、破折号、省略号）的小核心文件会被预加载。一个位于`unicode-range`之后的扩展文件，仅在页面需要其字符之一时下载。每个文件的`unicode-range`应仅列出其实际包含的字符。注意几件事。核心文件和扩展文件之间生成的回退字体面会在真实字体之前绘制扩展字符。在OFL下具有保留字体名称的字体在子集化后必须在内部重命名。检查生成的文件，因为字体工具存在怪癖。在宣布完成之前，从相同内容构建基线，并在包含代码、斜体、重音字符、具有自身字体设置的组件以及CJK的页面上进行前后像素差异比较。解释每个可见差异：内容变化、需要修复的回归，或无害的子像素舍入。重新测量每页字节数，并确认扩展文件仅在需要的地方加载。完成后，告诉我每个字体和每个页面优化前后的字节数、像素差异结果、任何偏离我要求的地方及其代价，以及如何重新运行脚本。以后，可能值得将核心字体嵌入全局样式表，并在空闲后预缓存扩展文件。