1.
现成的 CSS 框架（例如 Bootstrap 或 Foundation）可以提供便捷且一致的方式，使用一系列预配置的样式轻松构建可视化组件。然而，由于可能需要应用额外的 CSS 文件、CSS 选择器或 CSS 覆盖，开箱即用通常会对性能造成影响。
选择 CSS 框架时，需要考虑以下几点：
- 网站的 <head> 标签中是否有其他渲染阻塞样式输出？你最多只需要在 <head> 标签中输出一个 CSS 文件。
- 框架提供的所有 CSS 都压缩了吗？这是必须的。
- 可能需要多少 CSS 覆盖？如果 电话号码 您用多个覆盖来对抗大量默认样式，这不仅会迅速导致 CSS 代码臃肿，还会使将来的管理更加困难。
- 你需要在 HTML 层添加大量选择器吗？HTML 臃肿也是一个重要的性能因素，你应该尽可能避免在 HTML 标记中添加多个重复的 CSS 选择器。
- 能不能把网站上没用到的 CSS 类去掉？几百个没用的 CSS 选择器会严重影响性能。
- 是否可以在页面级别生成并输出仅针对该页面使用的块和组件的 CSS？页面级别不需要的全局 CSS 将占用不必要的带宽和处理能力。
- 是否可以将首屏内容所需的关键 CSS 分离出来，并推迟加载其他所有内容？最小化 <head> 中加载的 CSS 可以提高 FCP、LCP 和速度指数指标的速度。
- 最小化并压缩后的首屏 CSS 文件大小，在服务器上与任何覆盖代码结合使用时，是否在 14KB 以内？14KB 是有效内联关键 CSS 的阈值。
大多数 CSS 框架不太可能满足上述所有 探索与评估 条件。因此，我们不使用 CSS 框架，而是倾向于使用 SASS 和编译好的 CSS 进行更自定义的方法，如下所述。
2. 分离首屏、全局和组件级 CSS
我们的基础主题使用了 SASS 部分代码，这些代码映射到我们底层设计系统所使用的块和组件。这些部分代码经过编译和输出，以便：
- 有一个 CSS 文件处理所有全局折叠内容，其中包括标题元素、导航和英雄单元。
- 各个 CSS 文件在块级别加载，位于 <head> 之外，仅在使用特定各个块的页面上加载
- 其余所有折叠下方的全局 CSS 均由加载于 <head> 外部的单独 CSS 文件处理。这包括页脚导航、全局页脚 CTA 单元以及屏幕外元素（例如汉堡包和下拉导航样式）。
然后应该通过异步加载样式表来延迟折叠下方的 CSS ，否则 <head> 之外的 CSS 仍将被视为渲染阻塞。
通过这种方式按需加载 CSS 可以减少关键链，消除灯塔中的“删除未使用的 CSS”警告，并减少 CPU 执行，因为浏览器需要解析的选择器更少。
当然，CSS 最小化也是必须的，但大多数现代构建过程都会通过删除所有不必要的字符和注释等来自动减少 CSS（和 JS）文件的大小。
4. 通过内联关键 CSS 来移除阻塞渲染的 CSS
如果您已经精简、最小化并分离了 CSS，并且通过附加组件加载了最少或零附加 CSS，那么您可能能够内联任何剩余的折叠 CSS。
内联关键 CSS 是指直接在 HTML
在追求最佳性能的过程中，这一步通常是最难实现的；绝大多数网站和大多数 CMS 平台几乎都会存在一定程度的 CSS 渲染阻塞问题。我们之所以能够做到这一点，完全得益于我们对网站进行了大量定制，而这些定制建立在 WordPress 的开源特性之上，从而支持这些修改。
内联关键 CSS 所带来的差异可以通过WebPageTest中的以下瀑布图来演示，该图模拟了 4g 连接的低端设备。
在第一个瀑布图中，您可以看到 布韦岛商业指南 阻止渲染的 critical.css 文件是第三个请求。这里，所有重要的“开始渲染”和 FCP 垂直绿线出现在 2.3 秒处。