13分钟阅读时间 (2669字)

缓存与否，这是个问题……

十一月

Russell Winter & Eoin Oliver

2021年11月20日星期六

32170次点击

0条评论

随着谷歌网站评级和排名标准的改变，相对较新的“Web Vitals”度量标准引起了人们对各种缓存技术的兴趣，以提高内容交付时间，以追求遥不可及的“全面100%”和令人满意的搜索引擎索引结果。

虽然这值得赞扬，但也给许多人带来了不少困惑、配置错误、性能不佳和挫败感。如果您正在考虑在您的网站上使用最小化或缓存，请确保您首先遵循了最佳的优化方法，包括布局、图像和扩展的使用，否则您可能看不到预期的结果。

什么是缓存？

缓存是在某一时间点生成数据的静态版本，在本例中为Joomla网站或页面，其中包含该时间点的所有内容。这阻止了服务器在每次访问该页面时查询数据库、处理数据或格式化页面；相反，它加载预先格式化的“缓存”版本。其想法是，如果移除了数据库和其他资源查询，则页面加载和格式化时间将大大减少，更快地向访客提供网站内容，并提供更好的用户体验。这听起来像是网站交付的乌托邦，不是吗？

缓存可能带来的不利影响

请注意，最小化和缓存可能存在潜在的不利影响，某些内容可能在一段时间内变得“过时”或“陈旧”。如果您的内容相对静态且不经常更改，或者不是时间敏感的，那么这完全没问题。然而，如果您正在创建包含时间敏感数据或相关内容的项目，例如外汇汇率、贸易、统计数据网站，甚至是电子商务网站，在这些网站上竞争力和最新定价非常重要，那么缓存的选择或如何缓存必须非常仔细地考虑，以避免不一致或不清晰的输出。

根据您选择使用的缓存级别，将决定大数据集或高度相关的内容是否与您的访客同步，并使其有意义。对于更大的数据集或内容，如果您的服务器或托管账户没有足够的资源或处理能力来执行后台的数据缓存活动，也可能会有性能损失。随后，当访客浏览您的网站时，页面加载时间实际上可能会增加，因为访客总是在显示之前等待缓存应用程序构建缓存页面。话虽如此，如果您的网站架构意味着您的访客倾向于在同一个会话中多次访问同一页面，例如中心枢纽或门户类型网站，那么缓存可以产生理想的结果并提高加载时间。

您应该在何时考虑使用缓存？

好吧，让我们从后往前说。缓存并不是配置不当或廉价托管性能的“万能药”（抱歉，您每年2美元的共享托管可能不会从缓存中获得太多好处）。它也不会是快速加载大型或高度图形化页面的最终解决方案（抱歉，您页面上10年的照片收藏，短期缓存可能也不会获得太多好处）。那么，您实际上应该在何时考虑使用缓存呢？如果您的网站及其内容相对静态，我的意思是现有内容不经常更新或修改，或者不经常添加新内容。

这并不是说快速变化或非常动态的网站不受益于缓存，但它们的缓存和CDN（内容分发网络）策略通常会很低，并针对其需求和时间框架进行定制，比普通网站更多，并且更多地针对旧内容缓存，对较新内容有例外。

在某些情况下，简单而有效的压缩或最小化扩展可以通过减轻可用托管资源的压力而产生更好的结果，别忘了对图像尺寸和文件大小进行适当的优化。

此时值得提及“预缓存”和“渐进式网络应用程序”（PWA），这是指当网站专门设计为在请求之前主动下载大多数访客访问的下一个预期页面到设备上。这些技术通常针对移动设备以及访客经常返回的网站，比如检查状态或事件开始。

如何开始缓存

如果您的网站可能被认为是小型或中型，并且您已经明智地投资了良好的托管，实际上您可能不需要比在Joomla中启用SSL和GZip或mod_deflate和mod_expires浏览器缓存更多的东西，以获得良好的用户体验或“核心Web指标”，特别是如果您的网站是Joomla 4。连接压缩、图像密集型网站的懒加载以及浏览器缓存策略，与良好的网站布局和托管相结合，应该提供90年代中期的核心指标。如果您正在寻找额外的微提升，HTML最小化和CSS/JS合并扩展可以在不增加太多资源使用的情况下提高用户体验。

如果您的网站倾向于较大或动态内容数据库查询较大，那么数据库查询缓存和/或OPCode缓存可能比页面缓存扩展是更好的选择，可能仍然使用压缩或最小化实用工具来减少静态资源加载时间。

在您的网站非常大（企业或科学类型的内容）且内容更“数据驱动”，包含大量表格或相关信息的列表可能可搜索或可由访客筛选的情况下，那么像Redis或Memcached这样的选项可能更为合适。使用这些选项需要相当多的数据架构理解，您更有可能运行专用服务器、VPS（虚拟专用服务器）或云虚拟服务器实例，而不是使用共享托管账户。

虽然这两个都被认为是“缓存”应用程序，但它们更像是在内存中的索引数据存储，并且是基于对象的，而不是基于整个页面文件缓存的，因此允许单独的数据对象动态更新，而不会使任何单页面的整个缓存失效。因此，这些是更高级的企业级架构，而不是小到中型网站的实现。

缓存的常见陷阱

Cache-Club的第一条规则是“少即是多”。我的意思是，不要在没有先单独测试的情况下随机混合不同的层或级别的压缩、精简和缓存技术。混合多种技术和方法往往相互干扰并引起竞争。如果按照正确的顺序执行并且在一定程度上了解彼此，缓存技术与压缩和精简技术结合可能是一件好事；否则，压缩或缓存已经压缩或缓存的某些内容实际上可能会增加大小，产生与预期相反的结果。

理解最佳缓存配置比最初看起来要复杂得多，“越多越好”的方法往往导致“越多越糟糕”和“它破坏了我的网站”的结果，不幸的是。

存在许多类型的缓存、品种、级别和层，并非所有都适合所有类型的内容和网站。在许多情况下，“无”实际上可能是最好的答案，并且经常是有限组合，按正确的顺序可以产生期望的“杀手锏”出色结果。

简而言之，对于那些不熟悉服务器、应用程序、PHP或Joomla!性能配置或调优的人来说，这是一个等待爆炸的雷区，更不用说破坏并让你的一天感到沮丧了。

导航缓存雷区

正如书中所说，用大号友好的字体写着，“不要慌张！”...
有一些基本的“该做和不该做的事”可以考虑，以减轻您的压力。

不要“把所有东西都扔出去”（1）来解决问题，您要么会观察到竞争，要么无法确定什么有效，什么无效。（即：不要违反Cache-Club的第一条规则）
不要在提供最大磁盘空间的最低价托管计划上托管，这些通常不是针对性能调优，而是为了使托管商的投资回报最大化。
与您的托管商交谈，看看是否有任何资源限制（PHP memory_limit、MySQL max_user_connections、查询缓存、MemCache、I/O条目/退出（基本上，从磁盘读取和写入）、虚拟或物理硬件限制（RAM/CPU/核心）。
首先单独测试每个缓存或最小化扩展和服务器缓存选项，以获得基线，包括CDN。
记录您的测试，这样您不仅可以跟踪结果，还可以跟踪您可能已经尝试过的组合。
查看大多数页面速度测试网站提供的图表和水落分离图，以查找异常，特别是影响Google的Web Vitals LCP（最大内容渲染）和FCP（首次内容绘制）的异常。
尝试了解导致性能问题的真正原因，并检查所有页面，而不仅仅是您的首页。
在决定是否真的需要启用缓存之前，请先优化您的网站布局、结构和图片，更不用说减少使用不必要的或过度的扩展或大型JavaScript库来实现一个“可爱的”功能了。

如上所述，在大多数情况下，“少即是多”，在不理解为什么网站表现不佳的情况下，将所有东西都扔到一个表现不佳的网站（1）上，不仅会增加维护需求，还可能完全破坏您可能观察到的合理性能。

与所有通用和入门文章一样，我们无法深入具体的应用或扩展配置，只能为您提供进一步研究您自己需求的起点。请记住，并非所有服务器都相同，尤其是共享主机账户，并且根据内容类型、用途和扩展使用，并非所有网站都相同。

您使用缓存及其结果可能会有很大差异。最终，最佳的配置是大小合适且配置良好的服务器和应用程序来满足您的需求，没有任何缓存可以完全克服配置不良或价格低廉的托管环境。以下简要概述了一些可用的不同缓存、压缩和最小化选项。

Joomla GZip
此全局配置选项压缩了Web服务器和浏览器之间的数据流，在大多数情况下，这通常是一个好的选项，除非您的托管服务提供LiteSpeed缓存（LSCache）、Varnish或类似的代理缓存，因为这些服务器实用程序通常会为您处理这些问题。
mod_deflate
如果已安装，此Web服务器模块可以压缩特定资产，并允许您设置较长的缓存时间指令，以影响访问者Web浏览器缓存现有本地副本的时间，或者是否需要从站点重新下载资产。如果默认情况下在主机上未启用，您可以使用.htaccess或web.config文件调用mod_deflate并选择要告诉浏览器缓存哪些资产以及缓存多长时间。与您的Web托管商交谈，以确定您的服务器上是否安装了mod_deflate。
Joomla! 网站和/或页面缓存
Joomla网站缓存通常最适合静态页面，并将在整个网站上均匀应用，Joomla页面缓存插件则更为具体，可以静态缓存单个页面，包括模块和插件数据，因此特别适用于高度静态的网站以及不是动态或随机的模块。
第三方缓存/性能扩展
这些通常以Joomla插件的形式出现，其中大多数都提供压缩/最小化和缓存选项，其中一些提供从最小到最大不同级别的选项。具有更多可用资源的托管账户更能胜任激进的处理，而资源较少的服务器可能难以在可接受的时间内完成压缩或缓存任务，这可能导致高TTFB（第一次字节到达时间）问题。因此，您可能会发现，不太激进的缓存或压缩通常会产生更好的结果。
PHP OPCode/OPCache & MySQL查询缓存
这些是服务器应用程序基于的缓存工具，通常不知道Joomla扩展缓存活动。如果已启用，最好是禁用Joomla或第三方扩展基于的缓存选项，以避免冲突或“双重缓存”活动。最好使用这些功能是针对大量使用基于PHP的处理或频繁但频繁的SQL查询类型的网站。在某些情况下，这些对于电子商务或高度自定义字段使用网站来说可能是好的，可以缓存数据库查询，但不能直接缓存由查询生成的页面。
缓存与代理服务器
这些环境包括LiteSpeed缓存服务器或类似Varnish代理服务器的应用程序。一般来说，让这些应用程序无障碍地处理重负载，因此禁用Joomla GZip，禁用Joomla缓存工具，限制第三方扩展仅用于“最小化”而不是缓存或压缩，删除任何.htaccess GZip或mod_deflate条目，并确保任何mod_expire语句与缓存/代理服务器中配置的时间框架相匹配。
托管虚拟容器和资源管理器
这里可能会有点“混乱”。大多数情况下，虚拟容器和资源管理应用程序（如CloudLinux Manager或MySQL Governor）最好使用默认配置自行运行，并且Joomla压缩选项和第三方最小化和缓存扩展在合理范围内表现最佳。您可能会遇到虚拟环境管理应用程序施加的资源限制，这会限制任何外部缓存功能的有效性，因此这有点像是“绳子有多长？”的练习，您需要在这里进行试验、测试和错误，以找到最佳选项。
内容分发网络
CDN由于其架构的本质可以极大地提高性能。特别是对于国际繁忙的网站，可能不需要纯缓存选项，因为交付机制分布在全世界，但对于本地或纯粹区域性的网站，CDN可能会影响性能或没有任何效果。然而，对于大型网站，GZip、mod_deflate和简单的页面缓存组合也可能极大地提高响应缓慢的服务器（慢TTFB - 第一个字节的传输时间），特别是如果是由大量的SQL查询或大量的组合风格图像引起的。在CDN前面使用额外的代理缓存可能会严重影响“管理员/”性能，这是由于多次缓存和持续的缓存失效，尤其是对于定期添加文章。