写在前面：这不是一篇新闻，而是一些基于事件和数据所引发的想法，欢迎讨论。

5 月初，Google 在开发者大会 I/O上讲了很多东西，我们只说三个：AI Overviews、AI Mode，以及 Gemini。

你会发现，这三个产品/功能是并存的。并且，它们分别代表了 Google 作为 web 时代的搜索巨头，在 AI 时代转型的过程中，尝试的三种不同路线：

• AI Overviews：传统 web 产品，向后兼容
• AI Mode：web 搜索向 AI 过渡的中间态
• Gemini：纯粹的 AI 产品

大公司还是大公司，一个 AI 搜索做了三种不同形态，且并驾齐驱。大厂「养蛊」还得看 Google。熟悉 Google 的朋友应该能够预想到，未来几年内会发生的事情：Gemini 将取代前两者，甚至取代 Google 搜索。

就算不取代，以 Gemini/ChatGPT/DeepSeek 为代表的生成式 AI 产品，也已经在杀死传统搜索了。

全球共有约 56 亿网民，Google 搜索市占率 90%+，约合用户量 50 亿左右；而 Google 自己透露目前全球有 15 亿人使用 AI Overviews——倒不一定这 15 亿人从此都不会访问搜索结果链接了，但至少他们当中会有相当大的比例不再点击链接。

人们直接使用 AI 产品的整理归纳能力来完成任务，需求完全在 AI 产品内部解决，不需要再访问第三方网站。

Cloudflare 公司 CEO 马修·普林斯最近接受美国政府质询时指出：在今天，75% 的搜索查询无需离开 Google 即可得到回答。

我们正在目睹 AI 爆发的副作用：AI 瓦解了传统互联网的核心商业模式，扼杀互联网通过搜索引擎获得的流量。

Google 它不断推进 Gemini、AI Mode 和 AI Overviews，一边将生成式 AI 产品提升至顶级入口，一边用（非主观的）流量补贴/惩罚策略来绑架内容平台：在 I/O 之后接受采访时，CEO 桑达尔·皮柴透露，如果内容平台同意让 AI Overviews 的爬虫抓取，将会得到更高的流量。

彭博社做了一些采访，发现很多网站的流量因为 AI 受到严重冲击，不得不调整内容发行策略，更有甚者只能关门大吉。

分析机构 SimilarWeb 数据显示，AI 产品严重降低了基于网页分发内容的平台所获得的流量，首当其冲的有时尚、旅游、手工、家居、美食、生活方式等领域。

一些内容平台已经感受到流量的大幅下滑，做出了不同的应对。

• 实力雄厚的新闻机构已经提前布局，包括新闻集团、美联社、施普林格等在内的新闻巨头，已经和 OpenAI 达成授权合作；
• 一些新闻机构则发起抵制，纽约时报集团起诉了 OpenAI 以及背后的微软，指责其非法使用时报内容开发产品并与自己竞争。

这些合作与诉讼的具体细节尚不为外人所道，但新闻巨头的动机很直截了当：内容提供商的流量正在越来越多被 AI 蚕食。没有流量就没有广告/会员收入，内容提供商也无力抵抗，所以 AI 产品公司必须给内容源头分成。

市场营销公司 Seer Interactive 做了一些关于 AI 汇总功能对网站点击率冲击的研究，发现 AI Overviews 对搜索结果页点击率的降低效果达到 70%，对网站主投放的付费广告的点击率则直接砍半。

硅谷知名投资机构 a16z 也做了一组报告，援引 SimilarWeb 数据，发现 LLM 产品对 YouTube、Quora、Reddit、媒体、电商、金融等网站的流量引导比例普遍低于 5%。

显然，AI 产品/AI 总结功能对传统互联网核心商业模式的打击是巨大的。

究其根本：

• 内容平台提供内容，搜索引擎获得数据；
• 搜索引擎提供流量，内容平台获得收入；
• 内容平台投放广告，搜索引擎获得收入

——这一互联网时代价值交换的体系，已经被 AI 彻底打破。

情况只会更加严重：市调机构 Gartner 认为，到 2026 年搜索引擎的流量将会暴跌 25%。

SimilarWeb 数据显示 2025 年 3-4 月各大主流网站和搜索引擎流量暴跌，只有ChatGPT.com 逆势增长。

最近很火的 AI 浏览器项目 Dia，其创始人 Josh Miller 前不久专门写过一篇文章，讲公司为什么从传统浏览器转型 AI 浏览器，顺便也讲述了他对互联网的几个观察。

其中之一：生成式 AI 将取代网页，成为新的交互界面。

传统浏览器的任务是加载网页。但现在，网页（包括 app、文章、文件等各种形式）正在越来越多变成 AI 聊天界面的「工具调用」(tool calls)。 AI 聊天产品已经很像浏览器了：它们能搜索、阅读、生成、做出反应。它们和 API、LLM、数据库交互。人们每天使用这些 AI 产品好几个小时。如果你还看不到这一点，给还在上学的亲戚打个电话就知道了。自然语言界面抽离了旧有的计算模式的乏味，将会成为新的标准。

Miller 的观察早已灵验：国内外有很多传统互联网企业，包括本地生活、导航、在线旅游、效率办公等领域，都已经主动拥抱变化，开发了 MCP 能力，让用户在使用 agent 的时候仍然可以调用它们的服务。企业可以在 AI 产品调用其 MCP/API 时收费，从而维持收入。

但内容是完全不同的商业模式。互联网上绝大多数的内容都是公开免费的，但很多人往往忽视了一点：这些内容之所以免费，是因为得到了广告或付费墙收入的补贴，这些收入只有直接链接访问才能够产生。

而 AI 产品抓取这些内容并生成用户需要的答案，整个过程就此为止。在今天，这些 AI 巨头和创业公司们往往一门心思发展自己，却没有为内容的来源网站主或创作者提供分成的计划——即便少数 AI 产品在交付物里提供了资料链接，大部分用户也不会点击访问。

在可预见的未来，互联网内容的生成将进入一种「不可持续」的状态。现在大批 AI 公司已经在用大模型生成的内容进行再次训练了。长此以往，互联网公域将充斥着大量由 AI 生成的低质量、虚假、与现实不符甚至毫无关联的内容。

我在之前的一篇评论文章里就提到过这种情况将会出现。APPSO 之前关于 AI 生成音乐的报道，也从另一个侧面展示了 AI 生成内容充斥网络后的吊诡情境。

种种迹象似乎预示，AI 产品工具的大流行如果不加控制，如果 AI 新时代的利益分配机制不尽快出现——传统互联网将会被杀死，届时没有人会成为赢家，即便是 AI 公司。

所以，AI 公司构建新利益分配机制的进展怎么样？

目前来看，这方面的工作还很「初级」。前文提到的 OpenAI 和内容提供商签订协议（具体金额和计费机制细节未知），除此之外并没有太多新进展。

a16z 上个月发表了一篇文章，试图描绘一个新的图景：从 SEO（搜索引擎优化）转移到 GEO（生成引擎优化）。

顺应这个趋势出现了一些新的创业公司，例如 Profound、Daydream 等。它们帮助客户和网站主分析特定关键词（例如品牌）在 AI 生成回复当中的表现——简而言之，就是「策略性」地帮助客户提高在 AI 生成总结答案中的曝光度。

但截至目前，业界在这方面的尝试仍然尚浅。核心痛点仍然存在：即便内容创作者面向 LLM 的逻辑优化自己的内容，在 AI 产品里获得了曝光，点击率仍然是个大问题。没有流量，所谓的「生成引擎优化」恐怕只是个美好的梦。

最后，这跟普通人有关系吗？乍一看似乎没有，毕竟大部分人都认为世界的变化从来不为普通人的意志驱动。

但实际上，这个情况和每个人都有千丝万缕的关联。

传统互联网从来不是完美的，但它仍然是迄今为止一切人类创造的精华宝库。互联网的黄金年代造就了如今最优秀的商业公司，推动着技术的进步；它也凝聚了无数人无偿/低偿向世界分享的知识：以博客、维基百科、YouTube、贴吧们为介质。每一个人都从这些公司的产品，以及这些互联网平台承载的信息中获益。

一切都是生意，互联网信息其实是一个市场。如果内容创作者无法获得价值，他们就不会创作原创内容。经济激励的缺位，势必导致在线内容平台的萎靡，导致互联网信息市场里公开免费有价值的内容出现短缺。这将会限制人们获取真实信息、新闻、观点的能力，威胁每一个人的知情权。

如果 AI 巨头杀死了传统互联网，成为了新的技术霸权，决定人们能否获得、获得怎样的信息，进而构建新的认知霸权——我们准备好迎接那样的世界，承担相应的后果了吗？

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

Although taken for granted now, Apple didn’t release the first version of Safari until January 2003. Before that was a succession of interesting experiments to try. Those started with Netscape Navigator in 1994, which lasted until 2007, although by then it was little used on Macs.

Netscape is seen here in 2000, following my successful purchase of downloadable versions of Conflict Catcher and Suitcase from Casady & Greene’s online store.

Two years later, and I’m browsing Amazon’s listing of my never-published book that was slated for 31 March the following year. I’m so glad I never pre-ordered it.

Netscape had been at the front of browser development, leading with on-the-fly page display, cookies and JavaScript. But in 1996, it was challenged by Microsoft’s Internet Explorer, and Apple’s more innovative Cyberdog. The latter was sadly abandoned the following year, leaving the way clear for Apple to replace the bundled Netscape with Internet Exploder, as it quickly became nicknamed.

This is Microsoft Internet Explorer in 2001, providing the front end to Mac OS X Server through Webmin.

Cookie settings in Explorer were highly detailed in 2005.

Many of us abandoned Internet Explorer for alternatives such as Camino. That had originated within Netscape as Chimera in 2002, based on its Gecko layout engine, with a native Mac OS X front end. The following year it was rebranded as Camino, and amazingly lasted until 2012.

There were other competitors, such as Omni Group’s OmniWeb, which had been developed for NeXTSTEP since 1995, then moved to Mac OS X until 2012.

This is OmniWeb in 2007, showing the different browsers it could identify itself as, including a single version of Safari 1.0.

In January 2003, Apple launched the first beta-release of its own browser, Safari, and bundled it in Mac OS X 10.3 Panther when it was released that October. Since then Safari has been a regular fixture in successive versions of Mac OS X, OS X, and macOS. For several years, it was the only browser on iOS and iPadOS.

This is Safari 1 showing the front page for Apple’s developer site in 2004, complete with the offer to download Xcode version 1.5 with dead code stripping as a new feature. That year, Mozilla Firefox was released as an alternative, and has continued to support Macs ever since.

Mac OS X 10.4 Tiger came with Safari as the only bundled browser when it was released in April 2005, although it took Safari 2.0.4 in early 2006 before it was stable.

Page loading was slow in 2005, when Apple’s front page took a total of over 16 seconds to load fully, but that only used 6.8 MB of memory. By contrast, today Apple’s front page only takes a couple of seconds but requires over 200 MB.

There were times when the only way ahead with these early versions of Safari was to completely reset it, emptying its cache, and even removing all passwords and AutoFill text. This is Safari 2 in 2006.

Prominent among the plugins in 2006 was the dreaded Shockwave Flash, which had only recently been taken over by Adobe when it acquired Macromedia the previous year. Details of plugins are here being displayed on an internal web page within Safari 2.

Safari 3, bundled in Mac OS X 10.5 Leopard in October 2007, brought the claim that it was then the fastest browser, but it was troubled by bugs and security problems at first.

Safari 3 had already grown extensive preferences, covering the use of plugins, Java, JavaScript and cookies, seen here in 2007.

Its successor, Safari 4, followed in the summer of 2009, ready for Mac OS X 10.6 Snow Leopard, with further performance improvements, particularly in its JavaScript engine.

By 2009, Safari 4 was able to warn the user if it was about to visit a site blacklisted by the Google Safe Browsing Service. At least when that service was available. That year also saw Preview and Beta releases of Google Chrome, now Safari’s most serious competitor on Apple’s hardware.

Safari 5 was released a year later, in 2010, and was bundled in Mac OS X 10.7 Lion in 2011. This brought Reader mode and opened the door to third-party extensions.

Safari’s hidden Debug menu provided a collection of tools for web developers, and more recently has become the even more extensive Develop menu.

By the release of macOS 10.12 Sierra in 2016, Safari had reached version 10.

By 2016, close control over Adobe Flash Player had become critical, as a result of its frequent exploits, although it remained highly popular with content developers before Adobe finally killed it at the end of 2020.

Since 2021, with the release of macOS 12 Monterey, Safari 15 and its successors have been able to perform on-the-fly translation, as demonstrated here.

Safari is now the bundled browser in macOS, iOS, iPadOS and visionOS, and this year is set to leap in version number from 18 to 26 with the arrival of Tahoe and its sister OSes. It has been a long and sometimes troubled journey over those 22 years, and despite strong competition from Google Chrome and Chromium-based browsers, it remains the browser of first choice for a great many using Apple’s hardware products. I hope my screenshots have brought back more happy memories than traumatic moments.

Reference

Wikipedia.

最近听说部门里面的产品或本地化运营对 Web 前端相关的内容比较感兴趣，正好我有相关的实践经验，所以在公司做了一个 Web 前端相关的分享会。分享内容包含：

1. 使用 Devtools：介绍 Chrome 浏览器内的模拟、编辑和审查工具；
2. 网页和部署：介绍 HTML, CSS, JavaScript, React，以及网站的部署和托管；
3. 网页性能指标：介绍网页性能常用指标和测量工具；
4. 资源分享：分享浏览器插件、网站和课程推荐。

与以往不同的是，这次分享会中加入了互动环节。我做了一个代码 Playground，尝试帮助观众了解 React，以及 React Props 的概念，并留了两个小任务，给观众尝试去实践对 React 项目进行编码。

完整的分享内容内容请继续浏览本文。

使用 Devtools

这个章节主要介绍 Chrome Devtools 一些可能不为人知的功能，来帮助我们提高日常工作中的效率和解决一些问题。先介绍 Devtool 里面「模拟」相关的功能。

模拟设备和屏幕尺寸

在 Devtool 里打开设备工具栏，在这里除了能够自由调整网页宽高，还能够模拟各种主流设备的屏幕。

甚至还能读取到网页里面的断点样式，提供快捷切换各种断点的方式。

需要注意的是，这里模拟的设备是会带上 UA 的，所以如果想在电脑里调试一些做了移动端特化处理的网站（比如访问主域名时，判断到是手机设备，则会跳到移动端的专门网站），是需要用到这个功能的。

模拟伪类

Devtools 还可以帮助我们排查各种交互状态下的样式问题，最常用的是，比如说我们想仔细排查某个元素的悬停和按下状态的样式，则可以在选中元素之后，勾选对应的伪类选项。

模拟媒体

在渲染面板（需要手动开启，浏览器默认是没有打开这个面板的）能够模拟部分系统设置，比如亮暗模式、打印模式、高对比度和减少动态效果等。

与之对应地，可以扩展一个概念叫做 CSS 的媒体查询，CSS 还可以探测到很多用户设备的属性或者设置，比如设备指针精度、视窗比例、当前是否全屏模式、设备方向等…

能探测的内容很多，但实际能用起来的可能只有寥寥数个，最全面的信息可以取 MDN 上查看。

编辑网页文字样式

Devtools 还提供了一个新的字体编辑器，能够让我们实时更改网页中的字体家族、字体大小、字重等属性。

编辑网页内容

我们在 Devtools 控制台里面执行代码document.designMode = 'on' 后，就可以实时在本地修改网页文字内容了，就跟平常打字一样。很适合用在测试文案长度的场景。最后也会分享一个浏览器插件，能够对网页做更多的编辑。

审查 React 组件

最后介绍一个审查 React 组件的方法，有时候我们想看某个元素是不是用的组件库，或者这个组件包含了什么属性之类的，可以下载 React Developer Tools，然后点选网页中的任意元素，进行审查。

网页和部署

接下来我介绍一下网页构成和网站部署相关的内容。

通常来说，HTML, CSS, JavaScript 是构成网站的三个要素。其中：

• HTML 用来用于定义网页的结构和内容，可以用来创建网站的各个部分，比如标题、段落、图片、链接等。
• CSS 用来定义网页的样式和布局，这个可能会是咱们设计师比较熟悉的部分，我们能够利用 CSS 来定义 HTML 元素的各种样式，控制它们的布局和位置。
• JavaScript 用来实现各种功能逻辑和操作交互。比如响应点击事件、动态修改网页内容，根据条件执行动画效果或展示特定内容等。

CSS 预处理器

上述的三种语言，都有各自对应的语法规则。而 CSS 预处理器，则改进了原有的 CSS 语法，使我们能使用更复杂的逻辑语法，比如使用变量、代码嵌套和继承等。

简单来说，CSS 预处理器能让我们写样式代码的过程更顺畅，使代码有更良好的可读性和扩展性，帮助我们更好地维护代码。

举个简单的例子，比如原本的 CSS 语法中要求我们给每一个元素写样式时，必须以花括号开始和结尾，而且每一条样式规则直接都要以分号隔开，而 Stylus 则能够让我们跳出这个限制。直接用换行和缩进来代替。

CSS 框架

另一个值得一提的概念是 CSS 框架。CSS 框架则提供了一套预设样式，比如颜色板、字体梯度，布局和断点设定等；以及一些常用组件，如导航栏、对话框和页脚等。

简单来说，就是提供了一批开箱即用的样式，便于开发者快速启动项目，同时也会保留高度自定义的空间，用于支持各种各样的需求。通常 CSS 框架都会包含使用某个 CSS 预处理器，甚至内置了一些图标库，主打一个 “开箱即用”。

这里稍微介绍一下一个 CSS 框架：Tailwind CSS。是一个高度定制化的 CSS 框架，通过大量的预定义类名，使开发人员快速构建和设计网页界面。

与其他 CSS 框架相比，有一个显著的特点是 Tailwind CSS 本身不会包装一个组件出来，比如按钮、输入框的样式，没有预设好的。取而代之的是，Tailwind CSS 将各种原子级的 CSS 类名包装起来，比如：

• 设置左右两边的 Padding，用 px-[...] 类名来实现；
• 设置一个元素为块级元素， 用block 类名来实现…

如果想要在 TailwindCSS 中，使用打包好的组件，达到开箱即用的效果，可以通过各种官方/非官方的模版或组件生态来进行。比如：

• Tailwind UI：官方模版库（收费）；
• Headless UI：官方组件库；
• Daisy UI：第三方组件库。

React

接下来介绍另一个概念：React。这是一个用于构建 Web 和原生交互界面的库（是的，它能够用来做 App，不仅仅是网页）。而且引入了 JSX 语法，将 HTML 和 JS 结合起来，以一种更直观和易于理解的方式描述界面的结构和内容。

React 有一点和我们的设计稿很像，就是它的组件思维。在构建用户界面时，React 主张先把内容分解成一个个可以复用的组件（把具体的交互、功能逻辑写在组件里面）。然后在页面中将各个组件连接起来，使数据流经它们。

下图引用了官网中的一个例子，其中：

1. 完整的应用，可以理解为由多个组件拼接成的完成网页；
2. 搜索组件，用来获取用户输入；
3. 数据列表，会根据用户搜索来过滤和展示内容；
4. 每个列表的表头；
5. 表格内每条数据。

现在我们用一个具体例子来简单介绍下 React 的组件。

在上图中，展示了一个页面页面 App.jsx 包含了 Profile、Gallery 和 FAQ 组件，以及 Profile.jsx 组件的代码。右侧是输出页面，展示了三个组件拼接而成的页面效果示意图，其中 Profile 组件模块里展示的内容，是和 Profile.jsx 文件内代码一一对应的。

上述的组件只是将一个模块包装起来，使其能够被其他地方复用。但组件内容是固定的。接下来会为大家展示如何向组件传递 Props，实现上文提到的一句话 “使数据流经他们” 。

在上图中，我们先将一些 Props 传递给组件 Profile（比如这里传递了图片的地址、人物姓名和描述），然后在 Profile 组件内接收这些 Props，并在组件代码内使用这些数据。

现在，我们就做出了一个可以复用的组件了，可以根据不同的内容来展示相关的人物信息。

大家有没有觉得这种做法有点熟悉？是的，在 Figma 中，我们的组件里面也有类似的做法。Figma 组件同样同样传递字符串、布尔和组件等内容。

实际上 React 组件可以传递的参数不仅仅只是上面例子中的字符串和布尔值，还能传递数值、函数、对象、Node 类型甚至另一个组件等。

我做了一个简单的 Playground，提前封装好了一个 Profile 组件，会传递一些字符串、布尔值（是否展示网站标签）以及数值（圆角大小），帮助大家更好地理解。

🛝 Playground

我做了一个 🛝 Playground ，大家可以在里面看到这个组件的具体的情况，实际看一遍代码可能会帮助理解 React 的组建和 Props 概念。

同时我也写了两个小任务给到大家去尝试，大家可以在上面的编辑器中自由尝试。

发布网站

到了这里，相信大家对构建一个网站已经有了初步的认识，接下来我为大家介绍下如何将构建好的网站发布的互联网当中，能够真正地被世界各地的人们浏览。

方法一：部署到服务器

这是比较传统的方法，先将项目相关的文件放进服务器里面（比如阿里云 ECS，或轻量服务器等）。然后在服务器内安装 NGINX，索引到项目文件夹，定义好首页、端口、404 等场景，最后将域名解析到服务器 IP。之后我们的网站就能在互联网上被人们访问了。

方法二：托管到服务商

这种是相对省心的方法，将我们项目所在的 GitHub 仓库，链接到服务商的托管服务当中。等于是由服务商来帮我们部署、发布项目，不用自己来配置服务器的各种内容了。下图列举了几种常见的网站托管服务商，分别是：Vercel，Github Pages 和 Netlify。

以 Vercel 来举例，除了能够托管网站之外，对每一次发布进行管理，甚至能够是对不同代码分支进行独立发布，还能收集网站访问数据等。

网页性能

接下来为大家介绍网页性能相关的内容。通常一个网站性能好不好，我们能够在体验时主观地感受到，比如打开时很慢、滚动时卡顿，或者点击按钮后很久才响应等等。但如果要准确地判断到网页的性能到底如何，是需要依赖具体指标的。

下面介绍三个常用的指标，分别是：FCP（首次内容绘制）、LCP（最大内容绘制）以及 CLS（积累布局偏移）。

FCP（首次内容绘制）

FCP 是一个关键指标，用来测量页面从开始加载到第一个页面内容在屏幕上完成渲染的时间。越快的 FCP 时间能够让用户感知到网页有在正常运行，而不是停滞、无响应。

这里提到的 “内容” ，指的是文本、图像（包括背景图像）、<svg>元素或非白色的<canvas>元素。如下图所示，FCP 出现在第二帧。

LCP（最大内容绘制）

LCP 指的从页面开始加载到可视区域内可见的「最大图像」或「文本块」完成渲染的时间。

这里提到的「最大图像」或「文本块」，具体来说是包含<img>元素、内嵌在<svg>元素内的<image>元素、块级文本等。

而测量方式，则是在页面加载过程中，记录视窗内的元素的渲染大小，取尺寸最大的元素，回溯这个元素被完整渲染的时间。注意，如果元素的有一部分在视窗外，在视窗外的部分不会参与到尺寸比较当中。

如下图所示，LCP 发生在第二帧，因为这个时候渲染尺寸最大的文本块被渲染出来了。后续帧当中，可能渲染出了一些图片，但尺寸都比文本块小，所以文本块依然是这个视窗内的最大元素。

CLS（积累布局偏移）

CLS 是指可视区域内发生的最大布局偏移分数。简单来说就是测量页面在加载时，元素的位置出现意外的偏移情况，如果元素尺寸大，而且位置偏移比较远，那么 CLS 分数就会显著增高。

这个指标会跟实际的用户操作或者体验有直接相关，所以应该也会是咱们设计师需要重点关注的内容，因为有时候布局偏移，是会比较影响用户获取信息、或者进行操作，甚至引发一些不可挽回的损失。

然后我来介绍一下测量网页性能的工具吧。我自己用过这两个，发现其实没啥差别，大家看喜好使用即可：

• DebugBear
• PageSpeed Insights（谷歌官方出品）

两个工具都能模拟桌面设备或者移动设备，记录多项关键指标的数据，并给出改进建议。

观察页面性能情况，不仅仅是前端技术人员要做的事情，了解到设计师也是可以参与到其中的。

比如 Guillaume Granger，他会比较想控制页面中 JavaScript 的数量，所以它提到，他会将所有用了 JavaScript 相关信息记录在表格当中。之后每次在网页中使用 JavaScript 时，都会跟之前的记录进行比对，判断重要性，决定是否在这个位置上使用 JavaScript。

开发者 Thomas Kelly 则提出了当意识到页面性能出现瓶颈时，需要做的事情，比如：

• 制定一个目标，团队一起往这个目标前进；
• 高频收集页面性能数据；
• 尝试用不同方式来解决同一个问题；
• 与同伴分享对性能的一些新发现…

资源分享

最后来分享一下相关的资源吧，包含两个插件、三个学习网站以及一个 React 课程。

插件：VisBug

介绍一个谷歌官方出品的插件：VisBug，主要用来帮助用户在浏览网页时进行调试和设计，包括编辑和可视化页面的 CSS，尺寸和字体等元素。

插件：Motion DevTools

Motion DevTools 是一个检查网页动效的插件，可视化和分析用户交互设计中的滚动、动画效果，并支持实时编辑、预览或导出等功能。

网站推荐

接下来介绍三个在国内外拥有较高知名度和影响力的设计师和开发人员。他们的观点、经验分享往往能给我带来一些新的启发。尤其是他们对钻研新技术的热情，是非常强烈的。

课程推荐

最后强烈推荐一门 React 课程——The Joy of React，这个课程我在年初的文章也有提到过，是以互动式课程的形式，由浅入深地讲解 React。从基础的组件 props 和 JSX 知识，到 Hooks、API 设计等等，讲述非常清晰，强烈推荐。

分享会感想

分享完之后感觉效果可能还不错，大家都有各自的收获。而且分享会中也不时有人提出相关问题，我也一一进行解答了。

或者也有对我分享内容的一些补充，比如我在分享完 Devtools 环节的时候，有同事也分享了一个在 Application — Cookie 面板里快速切换网页语言的方法。

后面了解到大家对于 CSS 和 React 那块听的比较迷糊，因为原本没有实践过的话，会对这些没有什么概念。而且大家好像对 🛝Playground 没有什么兴趣，并没有人对里面的内容有什么提问和看法之类的，可能到这一步都比较迷糊？🤔

指标那块倒是有不少同事关心，问了几个问题，比如有哪些方法来去改进几个指标的数据，或者在设计过程中是否可以提前避免性能问题等等。

总体来说和之前的分享会相比，这次分享会的参与度比较不错。

我的个人网站从 2017 年底（大四上学期的期末）进行 “研发”，2018 年初部署运行，现在已经过去了 5 年。中途经过大大小小近 300 次迭代和内容更新。

从原本只是用来放置我做 Side Project 成果的内容，到后来变成我对外展示的窗口，用来展示我在实际工作中的项目，以及设计博客和翻译的文章等。LRD.IM 的页面布局、风格样式、内容、功能等等随着我的设计生涯发展有着很大变化。

互联网档案馆 Internet Archive 保留了 2019 年之后的存档。之后每一次改版我也会在该网站留下存档。不知 5 年后又会是啥样呢。🤔

唯一不变的是，它仍然是用纯粹的 HTML + CSS + JavaScript 来实现的。访问我的网站就像是打开一个文件夹，浏览器只是将我的 html 打开而已。

网站内部没有组件，没有数据源。改动一个公用的地方，如页面顶部导航栏或博客的文章添加一个模块时，我需要在编辑器里打开数十个 html 文件逐个修改。

自己一直有想着改造一波，但自己当前的水平，想做出一个现代化的个人网站还差很多。所以这个计划也就一直搁置，自己日常中最多是观察下其他优秀的个人网站及其实现方式，储备点灵感。

直到两个动机和一个条件的出现，我觉得是时候了。

动机和条件

动机：迭代频率

最开始我的博客页面只是一个列表，点击里面的文章都会跳转到 Medium 平台里面。后面我觉得这样做体验巨差，原因：

• 自己创作的内容全部都放在别的平台上面去了。这是一个令我太不舒服的感受。我的想法是可以放到其他平台内，获取一点点流量和 SEO 的优势，但自己的站点是最优先的；
• Medium 需要科学上网才能较好访问。读者的体验未必会好，从稳定性上考虑也不利于长期发展；
• Medium 一直没有进步。感觉这几年这个平台在原地踏步，或者甚至是下坡路。这是我作为长期用户的主观感受。

所以后面我将 Medium 的文章导出成 HTML 文件（平台的功能），作出相应的调整后贴回自己的网站上面，这样文章就能又回到自己那儿了。

但这个转换的过程并不简单，Medium 导出的 HTML 是带有他们的一些标签和样式的，当时我是将每一篇文章的 HTML 都筛掉没用的内容，然后 CSS 里编写了一套自己的格式文本的样式，使其适应网站的设计风格。由于步骤太多我甚至还将做法记录了下来，发布文章之前任何一步有纰漏都会出问题。

这套混乱的秩序维持了至少一年半，这期间我的每一篇文章都经过这样的处理。包括后面添加的「目录功能」、「博客功能区」等有新增或调整代码的时候，我都要在每一篇文章（40+ 篇）的对应位置里增删改。

这种手动、机械式、重复的工作不仅导致迭代网站的时间成本极高，也很容易出错。

比如某篇博客的功能区，本身应该所有页面的这块内容都应该长得一样，只是日期不同，但就是因为我将数十个 html 文件逐个修改的时候出现了纰漏，导致某些页面的样式异常。

这次重构我抛弃了 HTML，改成了用 MDX 来支持我的博客内容。之后的文章会介绍到我是如何用 mdx-bundler 来重构整个博客功能模块。以及我为了提升阅读体验所做的工作。

动机：体验问题

我对网站里面有一个非常刺眼的体验问题一直耿耿于怀。

暗色主题下刷新页面会出现闪烁
原本的做法下，亮/暗主题色的切换功能是写在 JS 文件里面。而用户在跳转页面时会重新加载一次文件，偶尔会出现令人难以接受的闪烁。

我也带着这个问题咨询了前端工程师朋友，他认为如果将网站做成 SPA，应该就能解决这个问题。

单页应用（英语：single-page application，缩写SPA）是一种网络应用程序或网站的模型，它通过动态重写当前页面来与用户交互，而非传统的从服务器重新加载整个新页面。 — — 维基百科

而且对于主题色，其实最好是能给用户手动来切换，并且记录上次更改后的结果。但这个功能要做在静态网站上，而且想到有代码更改的话又得将数十个 html 文件逐个修改，实在是没有研究的动力了。

条件：离职之后

2022 年 11 月我从欢聚离职，回到老家，暂时离开城市和朋友圈。有充足的时间给我去学习这方面的知识，以及去做相关的实践。

技术栈

这次的重构我的个人网站并不是一时兴起，平常自己也会了解相关的资讯。既然选择了行动，就已经做好跳出舒适圈的准备，接触一些以往从没有实践过的内容。

Next.js

整个 2022 年，通过 Next.js 构建的网站挤满了我的推特信息流。时不时都会看到有些设计师/开发者在推特上发布自己的个人网站。也发现许多充满设计感的网站都是通过 Next.js 来做的，比如 Linear、Pipe、Fey、Frame.io 等。

在一众先驱者的引导之下，我也去了解了下相关介绍，甚至还看了点 Next.js 初学者教程，里面大部分内容我大部分都能够 Get 到。感觉上手难度不大，又有这么多大佬级的网站做背书，于是乎，就是你了 — — Next.js!

Tailwind CSS

我选择使用 Tailwind CSS 的原因主要有两个：

第一个是这个网站做得很好看，包括它给出来的 Template，这让我有了进一步了解的兴趣；

第二个原因是这确实有效解决了在迭代原网站时让我烦恼的地方：

1. 我基本上再也不用绞尽脑汁去想某一个元素的类名（还得是英文的，时间久了想不起来哪个样式用在哪）；
2. 在实际写代码的过程中也不用经常在页面和 CSS 文件中来回切换了。现在写反馈效果、媒体查询、深色样式时很方便；
3. 最关键：我再也不用维护一个 2,000+ 行的层叠样式表了！重构后的 CSS 文件轻量了很多，因为都写进网页和组件中了。

Mdx-bundler

之前将 Medium 文章迁移过来的时候，就发现了 HTML 的做法只适合有富文本编辑器的平台。而像我这样式的多数在代码编辑器里面书写的话，可能 Markdown 更合适。

然后我是在 Tailwind CSS 的 Protocol 模版介绍当中了解到原来 MDX 是可以让 Markdown 和 Next.js 联动起来，然后也在 Josh 介绍自己的博客时。也有介绍到相关内容，于是就选择了 mdx-bundler 来实现我的博客模块。

MDX 允许我们安装各种插件来增强博客的能力。比如支持到 Github Markdown 语法的插件 remark-gfm 和代码高亮插件 Rehype Pretty Code 等。

而且还能嵌入自己编写的 React 组件，这是让人感到惊奇的能力。这意味着我的博客文章可以不仅是图文、视频和 iframe 了，还能有一些互动元素，有很大的想象空间。

过程概述

由于我属于边做边学，所以整个重构的过程并非从头到尾一次性完成的。而是一个螺旋式上升的过程。

第一步：核心功能

当时先完成核心或通用的功能部分（遇到难搞的功能先记录并跳过），然后将原站点的所有内容填充进去。
这时确保网站在本地环境中基本能正常跳转和响应点击，深色模式和响应式等适配工作需要完整做好，因为这方面是相对简单的工作。具体来说：

1. 先学会 Tailwind CSS 和 Next.js 的配合使用，设定好通用的布局和主要样式。以及调试主要页面之间的路由跳转；
2. 开始构建主要页面，学会运用数据源和循环遍历来呈现页面内容（完整的内容先不填充，确保循环能跑通，数据能正常获取）；
3. 尝试使用 mdx-bundler 来读取博客列表和渲染 Markdown 文章。这个模块特别重要，当时花了不少时间。

第二步：内容填充

这时会带着早些时候记录下来的问题和卡点，去耐心查阅并参考尝试其他开发者博客里面他们的实现方案，同时也进入 The Joy of React 课程当中系统地学习一遍 React 的基础内容。具体来说：

1. 填充所有数据源和遍历中用到的内容，如某个字段的文本、配图的 URL 等；
2. mdx-bundler 跑通之后，我用 Markdown 重写了所有的博客文章，并且每篇文章都填入相应的元数据；
3. 填充所有作品详情页里的内容。

第三步：填坑优化

有了知识储备之后，最后再回头把原有的一些卡点和问题填补上，或者优化下原本的代码。甚至会改良下组件的命名、文件夹结构等等，这些会参考到其他开发者他们所总结出来的的最佳实践。

1. 带着过程中遇到的卡点和问题，在其他开发者博客或课程中学习理论知识；
2. 解决之前的卡点和问题，完成所有功能，以及边缘场景的处理；
3. 看看原有代码有没有哪些地方可以改良；
4. 重复「学习→解决→改良」步骤，直到网站达到了我认为能够部署的标准。

解决问题的方法

做一个网站实属不容易。尤其像我一样在自己的能力之外，选择用框架来实现，过程更加是绝非一帆风顺。不止跳出了舒适圈，甚至还跳进了「痛苦圈」。

技术方面的指引我不敢乱写，倒是可以分享下在这次重构的过程中，我用到的几个解决问题的方法：

搜索引擎和编程社区

一些广泛的问题我会找 Google 来帮忙，比如我想看看别人是怎么做亮/暗模式切换的，我会搜索类似 “next.js darkmode switch”，搜索结果中可能会出现一些开发者的博客、Stack Overflow 或 Github Issue 中提出相似问题的人，这些内容是我可以拿来参考的。

ChatGPT

在去年 12 月 ChatGPT 横空出世，当时有看到很多推文有展示它的神奇功力。我甚至觉得它很多的回答比人来回答还要好，很清晰和有条理，让人感到意外。

我也利用上这股强大的力量，用 ChatGPT 来解决一些具体的问题。比如现在博客文章里面的目录，会查找页面内所有的H2 H3标签并生成为一个列表，这就是我向 ChatGPT 提出我的需求之后，它来帮我写出来的。

另外我也会让 ChatGPT 帮忙解释某段代码的意思或作用。我从搜索引擎或编程社区里获得的一些解决方案，有时候某些语句自己没看懂的时候，会需要 ChatGPT 来帮忙解释一下，好让我针对自己网站的特点作出些许改造，或者了解报错原因和解决方法。

Joy of React

即便 ChatGPT 能解决部分具体的问题，但也不是万能的。实际开发中有些特别具体的问题，始终还是要靠自己。我对 JavaScript 掌握的程度是属于半滴水（半桶水都算不上），对 React 以及里面的 JSX 语法更是完全没了解过。

简单的内容靠查阅文档 + 观察规律可以学会，比如我通过看其他人的案例，我大概知道了每个组件里面都要有一个export、return()里面只能有一个子标签、JSX 里面有一个特殊的标签是<> ... </>等等...

但稍微再具体一点的问题，比如根据某个条件来更改样式，或者甚至想直接做一个需要传递参数来改变展示方式的组件，这些特别个性化的内容想要光靠搜索引擎和 ChatGPT，效率太低了。很可能搜半天还是一头雾水，浪费光阴。

刚好在今年 1 月 24 日，前端大佬 Josh W. Comeau 发布了 The Joy of React 的教程，这是一份面向初学者的 React 教程。在里面我能系统地学到一些 React 相关的知识，或者课程中会用到的 JavaScript 的基础等。

这门课程对我的网站重构项目起了很大的帮助，学习后我弄清楚了一些 React 的运行规则，也确实做出了一些实用的组件，改进了页面的代码质量。之前一直卡住的、很具体的问题也在学习之后得到了解决。

这份 $50 左右的课程干货满满，作者也很用心地安排了每个章节会有互动性的练习，也会附带一些视频解说（有 CC 字幕和视频摘要）。后续我可能会出一篇文章来回顾下我在这个课程内学到的内容，记录下这段激情澎湃的青葱岁月。

请教专业人士

好吧，如果有些问题确实难搞，自己用尽所有的方法都没法解决，同时也在这个问题上耗费了很长时间的时候，我会咨询一些前端工程师朋友。

工作几年我一直和前端工程师的关系都也还行，所以有时候问到些问题他们也乐意帮我解答（还因为我的问题在他们眼里其实非常基础…）。

除了现实中认识的朋友以外，其实也可以咨询网络上的一些开发者。如果一个开发者将他的经验分享出来后，其他人使用过程中遇到问题，大部分都乐意帮忙解决的。

未完待续…

这一篇文章记录了重构我的个人网站 LRD.IM 时的经历，计划后面会有多几篇文章来记录具体我做到某个模块时的一些过程，或者说重构之后一些我认为比较有意思的改良等等，算是给这次重构计划一个交代。

本文于 2023 年 02 月 21 日首发于 LRD.IM