让 dev.to 变得异常快速

2025-05-24

让 dev.to 变得异常快速

每当有人赞叹这个网站的加载速度之快时,我都会心一笑,因为这绝非偶然。我们为此付出了很多努力。这种提升通常很容易被忽视,但如果你的读者是开发者,他们就更有可能注意到并欣赏它。我以前写过这方面的文章,但值得重新审视,因为这些理念总是在不断发展。

从一开始,我们的想法就是,如果我们能让所有东西都变得极快,那么以后其他所有用户体验方面的考量都会变得容易得多。对我来说,网页性能是用户体验最重要的考量。没有人愿意把时间浪费在空白屏幕上。无论多么细微的改进,用户都会希望回到一个不会在空白屏幕上浪费时间的网站。

但速度并非免费。为了确保性能,项目必须有一套合理的约束条件。早期关注性能有助于规划网站架构,使其符合确保出色渲染速度的约束条件。未来的决策不太可能需要权衡性能,因为性能考量是整个网站架构的核心。

大多数 Web 性能问题都归结于理解瓶颈所在。由此出发,我们需要确定可以做出哪些权衡来消除瓶颈。对于关注点不同的人,沟通权衡确实非常困难。我认为这个项目的成功很大程度上是因为我对自上而下的问题及其实现方法有着相当深入的理解。如果一开始就向设计师解释为什么我们不能总是在页面上添加自定义内容,或者让设计师解释他们为什么需要自定义内容,那将会非常困难。

设计约束

我们可以了解哪些应用程序信息来决定架构决策?对于dev.to来说,我认为这是一个读取操作非常繁重的应用程序,因此有很大机会进行大量缓存。这是一个机会,可以尽量简化功能,最大限度地利用最重要的功能:内容消费。了解可用的基础设施工具也至关重要。不要围绕没有人提供合理服务的基础设施来构建项目。

从根本上讲,最大化 Web 性能的关键在于缓存和降低延迟。此应用程序包含一系列博客文章。每当更新文章或发表评论等时,都会有大量的动态读写操作。但大多数用户行为是访问网站、阅读或浏览内容,然后离开。为了更好地服务于这种行为,我们充分利用了边缘缓存。这意味着,如果您从纽约访问此网站,您将直接获得来自纽约的静态、经过 gzip 压缩的 HTML 页面。如果您从伦敦访问,您将获得伦敦版本的缓存页面。如果您从尼日利亚访问,您将获得西班牙版本,因为在这种情况下,西班牙是最近的节点。这比一个网站从犹他州或其他地区提供所有内容的体验要好得多。

如果无法提供完全静态的内容,同样的原则也适用于基于区域的数据复制。随着我们网站功能集的不断增长,我很高兴能够在这方面扩展我们的功能,但对于单人运营来说,以简单的方式实现最佳性能至关重要。我们使用 Fastly 来满足我们的 CDN 边缘缓存需求。我们非常喜欢他们的服务。坦白说,Fastly 现在是我们的赞助商,但我们之所以选择成为赞助商,是因为我们热爱他们,而不是他们支持我们。

初始页面请求

典型的请求首先会返回一个完全缓存、预 gzip 压缩的 HTML 页面,该页面由最近的 Fastly 节点(如果有)提供。其他“动态”信息(例如您点赞的评论等)会通过第二个轻量级请求访问应用数据库并返回相关信息。这些数据本身已被缓存,但其缓存键基于特定的用户会话,因此我们目前无法从边缘服务器返回这些信息。我们计划在客户端存储更多此类数据,这样就不必频繁地从源服务器获取数据,但目前尚未实现。

消除渲染阻塞样式和脚本

页面交付后,下一个重要细节就是尽快渲染。在我看来,很多网站,即使是通过 CDN 从边缘提供完全静态内容的网站,也常常在这方面存在不足。提升渲染时间的关键在于消除所有阻塞渲染的延迟。这意味着无需外部 CSS 请求、无需自定义字体,也无需同步 JavaScript。

是的,所有与初始渲染相关的 CSS 都包含在一个<style>标签中,页面结构的任何部分都不依赖于任何 JavaScript 执行。这确保了即使用户访问网站时缓存完全清空,他们仍然可以几乎即时地看到网站的所有内容。网站的所有样式逻辑都按照惯例组织到样式表中,并使用 SCSS 以方便使用和保持简洁,但相关的 CSS 会在运行时打印到页面上,并且所有内容当然都会在后续请求中缓存。

图片会自动进行压缩优化,并根据浏览器选择最高效的格式(Chrome 为 webp,Safari 为 jpeg 等)。这是 Cloudinary 提供的服务。Cloudinary 还尽可能充分利用了 HTTP2,因此我们无需考虑这一点。

大型封面图片的背景颜色设置为与图片近似的颜色,因此图片加载时过渡效果更佳。我尝试过在页面内嵌一张分辨率很低、模糊的图片,但这本身会增加页面重量,并增加渲染引擎的运行时间。未来可能会有其他解决方案。

我很期待尝试一下这个比较新的原生<picture>元素,它应该能帮助我们提供更小的图片。不过,我们还没有用过它。

底线

网页性能是用户体验最重要的考量因素。当用户点击本网站的链接时,我不希望他们在页面加载过程中习惯性地跳转到其他标签页。我希望他们能够自信地在移动设备上点击,并期待获得极快的页面加载速度,即使网络状况不佳。试想一下,在网络上访问一个包含大量外部 CSS 和自定义字体的页面,你肯定会遇到麻烦。我希望我们遍布全球的读者,无论他们的设备、网络状况如何,以及他们与我们主要区域的距离如何,都能享受到同样快如闪电的页面请求速度。我希望在我们网站上发布博客文章的开发者能够相信,我们正在不断改进用户体验中的重要环节。

希望以上内容对您有所帮助。欢迎提问或在下方留言。

文章来源:https://dev.to/ben/making-devto-insanely-fast
PREV
我的一些写作原则
NEXT
只在工作时编写代码是完全没问题的,不要让任何人告诉你不是这样。