SyntaxFM 播客文字稿

节目信息

SyntaxFM | 整理时间：2026年1月25日
版本: 剪辑版

主持人：Wes Bos & Scott Tolinski

---

节目简介

本期节目深入探讨了让网页应用在移动端体验不如原生应用的诸多原因。主持人们从实际开发经验出发，逐一分析输入框缩放、横向滚动、文本选择、页面加载等常见问题，并提供了具体的解决方案和优化建议。

---

核心话题讨论

话题 1：输入框自动缩放问题

Scott: 这个问题由来已久，至今仍让我在网站上感到困扰。当你点击或轻触输入框准备输入时，浏览器会自动放大该输入框。但当你完成输入并关闭键盘后，浏览器却不会将其还原。结果突然间整个网页处于轻微放大的状态，出现水平和垂直滚动条，内容被截断，体验非常糟糕。

Wes: 十六像素不算太大吗？

Scott: 十六像素是默认值，对吗？正是这个意思。很多人在设计时觉得十六像素在桌面端偏大，因此忽略了这一点。他们把字体大小设成十二或十三像素，这太离谱了。

💡 要点: 只需将所有输入框的字体大小设置为 16px 或更大，浏览器就不会对其进行自动缩放。这是移动端体验优化的基础且重要的一步。

---

话题 2：横向滚动陷阱

Scott: 在开发时我始终认为横向滚动条对我是一种阻碍，因为我存在使用鼠标的用户，但就我个人而言，我已经习惯了所有操作都通过滑动完成，因此我从不希望任何界面出现横向滚动条。

Wes: 这几乎总是意外的水平滚动。当你上下滚动网页时，会不小心向左右滑动。这让我非常烦躁。我的网站也多次出现这种情况，因为这是最令人头疼的调试问题，根本不知道到底是什么原因导致了水平滚动。

Scott: 解决方法是创建一个应用窗口容器，填满整个区域，并对所有内容设置 overflow hidden。

💡 要点: 意外的水平滚动是移动端体验的常见问题，需要通过合理的 CSS 布局和 overflow 控制来避免。确保页面内容不会产生非预期的水平滚动。

---

话题 3：文本选择与缩放功能

Wes: 指针事件的正确使用，包括 none 以及 user-select none。这又是一个观点，对于原生应用来说，它们对可执行操作的限制往往更加严格，甚至到了令人沮丧的地步。你有没有尝试过从 Facebook 的评论中复制文字？根本不可能。

Scott: 当我把这一点提出来时，我立刻想到去检查我的原生应用列表，看是否能通过捏合手势缩放其中任意一个应用的用户界面，结果一个都没有。没有一个可以做到。

Wes: 如果你对一个元素应用了背景色过渡，但实际涉及的元素数量过多，就会导致帧率严重下降。如果只是单个按钮上的背景色过渡，问题不大。但如果有上千个按钮同时应用背景色过渡，帧率就会急剧下降。

💡 思考: 原生应用默认禁用了文本选择和缩放功能，而浏览器环境默认全部开启。开发者需要根据具体场景合理控制这些功能，在可用性和无障碍访问之间找到平衡。

---

话题 4：帧率与性能优化

Wes: 浏览器内置了帧率计，你可以查看帧率，打开开发者工具后进入检查元素界面。此外还有渲染高亮功能，比如会突出显示正在重新渲染的 div 元素。如果你在某个图层的背景中设置了动画，就会发现它闪烁红色，因为该元素更新频率过高。

Scott: 我常说要达到六十帧每秒，这就是目标。你不需要让所有内容都保持六十帧每秒，但应该尽可能追求这个数值。如今我们使用高刷新率屏幕，体验非常流畅。

Wes: 我从马修·佩里那里学到的一点是，他是动画库 Framer Motion 的开发者。过去我曾称 Framer Motion。有件事让我印象深刻，那就是它并不在于帧率越高越好，而在于帧率保持稳定。

💡 要点: 帧率稳定性比单纯的高帧率更重要。稳定的帧率能提供更流畅的视觉体验，避免卡顿和跳跃感。使用开发者工具的帧率计和渲染高亮功能来诊断性能问题。

---

话题 5：页面加载与客户端渲染

Scott: 即使是坚持纯服务器端渲染的网页极客，也未必完全排斥客户端渲染。另一个问题在于，如果未正确设置颜色主题，当处于深色模式并刷新页面时，会出现半秒钟的白色屏幕，这会让体验显得很糟糕。

Wes: 完整页面刷新。这是一个非常简单的概念。目前存在众多框架，这本身并无问题，快速的 HTML 也完全可行。但如果你的页面切换较为复杂，大多数框架都能实现点击链接时无需真正跳转页面，而是通过更新状态来完成页面变化。

Scott: 我认为某种程度上，客户端渲染被误解了，其实它非常出色，是让应用感觉更原生的关键因素之一。

💡 思考: 客户端渲染和服务器端渲染各有优势。关键是避免页面刷新时的闪烁和延迟，提供流畅的页面切换体验。合理使用本地数据缓存和乐观式 UI 更新能显著提升体验。

---

话题 6：视口单位与地址栏问题

Scott: 尤其是在移动设备上，比如 Safari 浏览器，地址栏经常被推到页面底部。那里存在一个奇怪的触摸区域，靠近底部时无法点击，必须注意页面底部的元素布局。之前我们引入了视口单位，当时大家都认为视口单位是解决方案，但实际使用中发现，由于移动浏览器的表现方式，我们需要新的单位。

Wes: 如果使用一百个 vh，而地址栏可见，那么一百个 vh 实际上并不等于完整的视口高度，它会向下挤压，无法真正填满整个视口。因此我们引入了 DVH 单位，我认为它是动态的。

Scott: 当地址栏和相关元素可见，该值就会相应变化。老实说，这很可能是导致卡顿的主要原因之一，不是因为视口单位的偏差，而是因为在滚动过程中地址栏和按钮不断在应用中进出，这种情况在原生应用中不会发生。

💡 要点: 移动浏览器的地址栏和工具栏会影响视口高度计算。使用 dvh（动态视口高度）单位代替传统的 vh 单位，能更好地适应移动浏览器的动态布局。

---

话题 7：加载时间与本地缓存

Wes: Optum Rx 在其网站上禁用了缩放功能，这很好，因为该应用可能有大量老年用户使用，他们可能会不小心用两根手指触屏导致误缩放，因此对此表示肯定。

Scott: 这个网站的重设计糟糕到让我宁愿开车去 CVS 药店取药，也不愿意再把任何数据留在上面了。不管怎样，加载速度慢、加载画面卡顿等问题层出不穷。之所以原生应用在某些方面感觉特别快，部分原因在于采用了本地优先的策略，虽然不一定非得叫本地优先，但核心思想是本地数据缓存。

Wes: 即使你不喜欢离线优先的策略，也请理解至少应该对部分用户界面进行乐观渲染，或者至少显示一个加载指示器，让我知道有事情正在发生。

💡 要点: 本地数据缓存和乐观式 UI 更新是原生应用流畅体验的关键。即使不采用完整的离线策略，也应该为用户提供即时反馈，让操作感觉更流畅。

---

话题 8：真实设备测试的重要性

Scott: 在深入探讨这些内容之前我想强调一点，发现这些问题的最佳方式就是亲自在手机上使用你的应用，用你自己的手机，用你妈妈的手机，用其他人的手机反复测试，因为很多问题本质上都是细节上的疏忽。

Wes: 我经常这么做，这是从本那里学到的。当他体验一个新应用时，有人会说，嘿，你能看看我的应用吗？我通常会打开屏幕录制功能，展示自己首次使用某个应用时的交互过程，同时边操作边自言自语。

Scott: 我现在做的每一样东西都会持续使用，比如我的 Have Path 应用，这是我为自己打造的习惯追踪工具，我每天都在用。虽然有些界面设计我其实很不满意，想要修改，但正是通过持续使用，我才真正理解了它的缺陷所在。

💡 思考: 亲自在真实设备上使用自己的产品是发现问题的关键。观察他人（特别是非技术人员）如何使用你的应用，能揭示出许多在日常开发中被忽视的体验问题。

---

📚 技术术语

• 乐观式 UI (Optimistic UI): 假设操作成功并立即更新界面，若实际失败则回滚。这种策略能让应用感觉更快速响应。
• 本地数据缓存: 将数据存储在设备本地数据库中，减少网络请求，提升响应速度。
• 帧率 (FPS): 每秒帧数，60 FPS 是流畅动画的标准目标。
• dvh 单位: 动态视口高度单位，会根据浏览器地址栏和工具栏的显示状态动态调整。
• 客户端渲染 (CSR): 在浏览器中使用 JavaScript 动态生成页面内容。
• 服务器端渲染 (SSR): 在服务器上生成完整的 HTML 页面后发送给客户端。

---

💬 金句摘录

“原生应用之所以流畅，是因为大量使用了本地数据缓存和乐观式 UI 更新。” —— Scott

“很多人并没有在真实设备上使用过自己的应用，这正是问题所在。” —— Scott

“我宁愿开车去 CVS 药店取药，也不愿意再把任何数据留在那个糟糕的网站上。” —— Scott

“发现问题最好的方式就是亲自在手机上使用你的应用。” —— Scott

---

🤔 思考与启发

本期节目展现了移动端网页应用体验优化的深入思考：

1. 细节决定体验: 移动端体验问题往往不是技术难题，而是细节疏忽。输入框字体大小、横向滚动、触摸区域等看似微小的问题，会显著影响用户体验。
2. 向原生应用学习: 原生应用在流畅度、响应速度、交互一致性方面的优势，值得网页应用借鉴。本地缓存、乐观式 UI、合理的默认设置都是值得学习的策略。
3. 真实测试的重要性: 开发者往往在模拟器或桌面环境中测试，忽略了真实设备上的体验。亲自在手机上使用自己的产品，并观察他人的使用方式，是发现问题的最佳方法。
4. 技术选择的权衡: 客户端渲染 vs 服务器端渲染、是否禁用文本选择和缩放、离线策略的采用程度等，都需要根据具体场景和用户需求进行权衡，没有绝对的对错。

延伸思考: 随着 Progressive Web App (PWA) 技术的发展，网页应用能否真正缩小与原生应用之间的体验差距？Web 标准是否需要引入更多移动端优先的特性？