利用 theme.json 和按块样式构建更高性能的主题
随着每个主要的 WordPress 更新，主题作者都能获得新的工具，这些工具可以减少他们的开发工作量，并可能提高其主题的性能。最近几个版本中的大多数改进都来自 theme.json 的更新。
theme.json 文件添加了额外的设置和样式，可以替代自定义 CSS 的需求。这些样式是内联的，并根据需要输出。 主要的 WordPress 更新通过 JSON 格式不断为主题作者带来更多控制权。
区块系统表现出色的另一个领域是其加载按块样式的功能。当 WordPress 在前端特定视图中检测到特定区块时，它会将该区块的 CSS 内联到网站的 <head> 元素中。 它对第三方区块和核心区块都这样做。
总而言之，这是一个非常高效的系统。并且，当整个网站都由区块构成时（例如区块主题），WordPress 通常可以有效地仅内联任何给定前端视图所需的 CSS 片段。
内联所有 CSS 的潜在缺点是您会失去浏览器缓存的好处。然而，考虑到过去十年许多 WordPress 主题的样式表体积不断膨胀，区块系统很可能比传统的经典主题平均效率更高。但系统的效率取决于其最薄弱的环节。这很大程度上要求主题作者承担起责任，充分利用可用的工具。
为了帮助鼓励最佳实践，让我们讨论一下确保主题高性能的两个主要工具：theme.json 和按块样式。
利用 theme.json 样式
在现代构建 WordPress 主题要求开发者重新思考他们过去依赖的方法。它要求他们在一个某种程度上超出他们控制范围的基础上“全力以赴”，依靠 WordPress 来完成大部分繁重的工作。
主题的主要角色与以往基本相同。它是设计，是粉刷房屋墙壁的涂料。然而，底层架构都是建立在一个标准系统之上的。
这带来了一些优势，例如允许所有扩展——插件和主题——都能从相同的性能相关功能中受益。
过去，主题设计的入口是 style.css，但现在情况已不再如此。主题作者通过样式表创建的许多（并非全部）内容已被纳入 theme.json。对于那些习惯编写 CSS 的人来说，这可能有点令人不快。这是可以理解的。然而，走出舒适区有时可能意味着步入一个充满可能性的崭新而奇妙的世界。
JSON 的使用是允许 WordPress、主题和用户进行通信、共同构建网站的框架的一部分。WordPress 提供界面以及默认设置和样式。主题使用 theme.json 来覆盖默认值。用户可以通过界面进行自己的自定义，这本质上是存储在数据库中的自定义 JSON。
因为这一切都存在于这个标准框架内，这意味着 WordPress 新版本中的每一项性能改进都会渗透到整个生态系统中。
这些好处需要主题作者的认同。为了充分利用现代 WordPress，开发人员必须使用 theme.json 来配置尽可能多的网站视觉外观，然后再转向基于样式表的解决方案。它是区块主题开发的基础，但经典主题作者也可以利用它。
主题手册中的 theme.json 页面是开始学习如何使用 theme.json 的最佳场所。并且，区块编辑器手册中的实时参考维护着设置和样式的最新参考。特别是，主题作者在寻求自定义 CSS 之前，应始终检查是否有可用的样式选项。
放置在 theme.json 中的每个自定义 CSS 规则也受益于区块使用的相同上下文内联样式系统。
按块样式
theme.json 不是万能药，不能解决主题作者试图解决的每一个问题。它是一个应该尽可能充分利用的工具。并非所有选项目前都可以通过 JSON 访问，有时使用样式表是有意义的。然而，长期目标是尽可能少地使用自定义 CSS。
传统上，每当主题作者想要添加一点设计风格（或者，实际上就是任何 CSS）时，他们会将代码添加到主题的 style.css 文件中。在 WordPress 早期，主题拥有未压缩、未精简的样式表，大小在 10 kb 以下是很常见的。那时的网络速度较慢，网站也更简单。随着网站复杂性的增加，样式表的体积也随之增长。
以下是经典时代最后三个默认主题及其 style.css 文件大小：
- Twenty Twenty-One: 158 kb
- Twenty Twenty: 125 kb
- Twenty Nineteen: 228 kb
与许多第三方主题相比，这三者的设计都相对简单。网站及其样式表日益增长的复杂性是区块系统试图解决的问题。
虽然未来的 WordPress 默认主题可能会主要依赖 theme.json 来满足其设计需求，但外部世界的开发人员通常会发现他们需要使用 style.css 来进行尚无法通过 theme.json 实现的自定义。
这就是 wp_enqueue_block_style() 的用武之地。它允许主题作者利用 WordPress 和区块插件免费获得的相同内联样式系统。此函数允许主题作者为单个区块拆分他们的样式表，这些样式表仅在需要时才作为内联样式添加。
让我们看一个实际例子。假设您有一些需要应用到核心 Group 块的自定义 CSS。假设您的文件位于主题的 assets/blocks/core-group.css 文件中，请在主题的 functions.php 文件中使用以下代码来将其加入队列：
add_action( 'init', 'themeslug_enqueue_block_styles' );
function themeslug_enqueue_block_styles() {
wp_enqueue_block_style( 'core/group', array(
'handle' => 'themeslug-block-group',
'src' => get_theme_file_uri( "assets/blocks/core-group.css" ),
'path' => get_theme_file_path( "assets/blocks/core-group.css" )
) );
}与相关的 wp_enqueue_* 函数不同，您必须提供 CSS 文件的文件路径以及 URL 路径。这是因为 WordPress 需要获取文件内容并将其打印在 <head> 元素内。
上面的例子过于简单了。主题作者很可能需要加载多个文件，为每个样式表重写相同的代码将变成管理噩梦。
当为多个区块加入样式时，请使用数组并循环遍历它们。以下代码片段假设您拥有核心 Button、Heading 和 Paragraph 块的样式表：
add_action( 'init', 'themeslug_enqueue_block_styles' );
function themeslug_enqueue_block_styles() {
// 为每种样式添加区块名称（带命名空间）。
$blocks = array(
'core/button',
'core/heading',
'core/paragraph'
);
// 循环遍历每个区块并加入其样式。
foreach ( $blocks as $block ) {
// 将斜杠替换为连字符以生成文件名。
$slug = str_replace( '/', '-', $block );
wp_enqueue_block_style( $block, array(
'handle' => "themeslug-block-{$slug}",
'src' => get_theme_file_uri( "assets/blocks/{$slug}.css" ),
'path' => get_theme_file_path( "assets/blocks/{$slug}.css" )
) );
}
}您甚至可以更进一步，使用 PHP 的 glob() 函数自动生成文件数组。然而，上述代码的目标是让您了解其工作机制。
对于那些对文件名的 core- 前缀和需要调用 str_replace() 感到疑惑的人，这是有充分理由的。这样设置是因为它还假设您可能希望支持具有类似 pluginslug/blockslug 区块名和类似 pluginslug-blockslug.css 文件名的第三方插件。如果您只计划在主题中支持核心区块，您可以随时简化代码。
对于许多区块主题来说，除了添加包含主题名称和其他详细信息的文件头信息外，可能根本不需要 style.css 文件。当页面上的每个元素都是区块时，几乎不需要其他东西。当然存在超出此范围的情况，但大多数主题 CSS 的大部分可以通过 theme.json 和按块样式来处理。