1-3 浏览Web页面 · 波仔的 Web技术原理课

📄 一句话概括

浏览 Web 页面，本质是【报一个地址、请对方送来内容、再把内容画出来】——浏览器是干这活的标准工具，而"专用应用程序"是绕过浏览器、直接跟同一台服务器打交道的另一条路。

📝 本节和前面几节的关系

上一篇讲了架构的五层，其中"浏览器"那一层只说了它"负责要、负责画"。这一篇把这个动作拆开看：要的时候靠什么报地址（URL），以及不想用浏览器时还能怎么办（专用应用程序）。 上一篇的五个词、这一篇的两条路，合起来就是"用户这一头"的完整样子。

一、浏览页面，其实就三个动作

把"打开一个网页"拆开，只有三个动作，而且顺序固定：

报地址：告诉对方你要哪一份内容。报的这个地址，就是 URL。
请求与送达：对方找到内容，再发回来。这一来一回的规矩，课程后面会专门讲（HTTP）。
画出来：浏览器把收到的东西变成你能看、能点的画面。这一步在 1-6 讲渲染路径时展开。

三个动作里，最容易出错的是第一个——地址少一个字母、多一个斜杠，结果就完全不同。所以教材把 URL 单列成 1-4，是有道理的：会读地址，是会用 Web 的第一步。

二、为什么地址不是"随便起个名"

你可能会想：地址嘛，写清楚就行，为什么还要专门定一套规矩？

因为地址是拿来给机器看的，不是拿来给人背的。它必须在全世界范围内不重复、而且能被程序一步步解析。所以 URL 被设计成分段的：每一段管一件事，机器从左往右读，读到哪一段就知道该干什么。下一篇会把它一段段拆开。

这里先记住一句话：URL 不是"内容的标题"，是"内容的门牌"。 门牌可能难看，但它精确。标题可以改，门牌改了别人就找不到了——这也是网站改版时"旧链接失效"的由来。

三、不用浏览器行不行：专用应用程序

教材这一条的另一半是"专用应用程序"。它是这么一类东西：同样要访问那台服务器，同样要取数据，但它不经过浏览器，而是自己直接去取。

浏览器：一个通用工具。什么网站都能开，代价是每换一个页面，都要重新搬一遍那些公共的零件（样式、脚本、图片）。
专用应用程序（手机上的各种 App、电脑上的客户端）：只干一件事。它把公共零件提前装好了，所以每次只跟服务器要那一小块数据。

这解释了一个常见现象：同一个服务，手机 App 往往比网页快——不是因为 App 的服务器更快，而是因为它每次要的东西少得多。

四、动手 Demo：两条路，下载量差多少

下面这个 Demo 拿一次完整的"网购下单"来算：同样六步操作，用浏览器和用专用 App，各自要下载多少数据。

# 六步操作，浏览器每次重搬整页，App 每次只要一小段数据
steps = [("打开首页", 1.8, 0.008), ("搜索商品", 0.9, 0.006),
         ("翻看商品详情", 2.4, 0.010), ("加入购物车", 0.7, 0.004),
         ("填写收货地址", 0.8, 0.005), ("提交订单", 0.6, 0.004)]
b = sum(x[1] for x in steps)
a = sum(x[2] for x in steps)
print("浏览器合计 %.2f MB，App 合计 %.3f MB，差 %.0f 倍" % (b, a, b / a))

实跑输出：

--------------------------------------------------------------------
D3  浏览 Web 页面：浏览器和【专用应用程序】各走一条路
--------------------------------------------------------------------
  同一件事（网购下单），两条路走下来，下载量差得很远：
  ----------------------------------------------------------------------------------------
  步骤                    用浏览器              用专用 App
  ----------------------------------------------------------------------------------------
  打开首页                1.80 MB               0.008 MB
  搜索商品                0.90 MB               0.006 MB
  翻看商品详情            2.40 MB               0.010 MB
  加入购物车              0.70 MB               0.004 MB
  填写收货地址            0.80 MB               0.005 MB
  提交订单                0.60 MB               0.004 MB
  ----------------------------------------------------------------------------------------
  合计                    7.20 MB               0.037 MB

  差了约 195 倍。原因不在【谁更快】，在于：
  浏览器每换一个画面，都要重新搬一遍整页的 CSS、JS、图片；
  专用 App 却是【问一句、答一句】，服务器只回一小段数据。
  这也是为什么 URL 之外还会有【专用应用程序】——它和浏览器看的是同一个后台。

读这个输出：195 倍这个数字不是"App 更好"，而是两种工具的设计目的不同。浏览器要能打开任意网站，所以必须通用；App 只服务一件事，所以可以裁到最省。记住这一点，以后判断"该做网页还是该做 App"，问的就是：用户是偶尔来一次，还是天天用同一个功能——偶尔来的用浏览器（不用装），天天用的可以做成 App（更省更快）。

五、⚠️ 2026 现状

教材 2024 年出版，"浏览器 + 专用 App"两条路的格局今天有明显变化：

第三条路出现了：小程序与网页应用。不用去应用商店装、又比普通网页省——它介于两条路之间。判断"做网页还是做 App"时，今天通常是三选一。
App 也在用浏览器的技术。绝大多数 App 内部的界面，其实是用网页那套技术画出来的（外面套一层壳）。所以"浏览器 vs App"更多是分发方式的差别，底下的技术已经高度统一。
浏览器的"通用"代价被压小了。近年的 HTTP/3、缓存策略、按需加载，让网页每次重搬零件的负担轻了不少——195 倍这个差距在真实场景中通常没有这么夸张，但它方向没变：通用工具永远比专用工具多花一点。

30 秒实验

拿手机做一次对比：

用浏览器打开一个常逛的购物网站，点进商品详情页，看它加载了多久。
再用该网站的 App做同样的事，看它加载了多久。
打开手机的流量统计，看看这两个软件今天各用了多少流量。

然后想一想：如果这个功能你一年只用一次，你还愿意为它装一个 App 吗？

常见误区

错误：专用 App 快，是因为它连的服务器更好。——纠正：App 和网页连的往往是同一套服务器。 它快在每次要的东西少——公共零件早就装在手机里了，不用每次重搬。所以"快"的来源是裁剪，不是"服务器偏心"。
错误：有了 App，网站就可以不做了。——纠正：网站是那个"不用装就能来"的入口。第一次来的用户不会为了看一眼就装一个 App；搜索引擎收录的也是网页。App 负责留住老用户，网站负责接住新用户——两者是接力，不是替代。
错误：URL 只是个好看的别名，实际连接靠的是别的。——纠正：URL 就是连接的第一步，里面的域名会被真的拿去查地址。它不是装饰，是"门牌"——机器就靠它找到该去哪台机器、要哪一份内容。
错误：网页慢一定是网速问题。——纠正：从 Demo 能看出来，网页的负担相当一部分在【重复搬公共零件】上。 所以同一台手机、同一个网络，打开不同网站速度可能差很多——问题可能在那个网站怎么组织资源，不在你的网速。

自测三问（点开对答案）

1. 为什么说"报地址"是浏览页面里最容易出错的一步？ —— 因为**地址是精确匹配的**。内容可以模糊理解，地址不行：少一个字母、多一个斜杠、大小写错一个，机器就找不到。而请求和渲染这两步，只要地址对了，通常是自动的、不容易出错。**所以排错时第一件事永远是先看地址对不对**——这一条能省下大量排查时间。 2. 手机 App 每次只跟服务器要"一小段数据"，那一小段通常是什么？ —— 通常是一段**结构化的数据**（含内容的字段和值），而不是带样式的整页。App 拿到这段数据后，用**早就装在自己手机里的界面模板**把它填进去显示。**"数据"和"怎么显示"被分开了**——这正是它省流量的根本原因。 3. 如果一家公司只做一个 App、不做网页版，会丢掉什么？ —— 丢掉**所有"只是路过"的人**。第一次听说这家公司的人，多半不会先装一个 App；搜索引擎也没法把 App 里的内容展示给别人。**网页版是"零门槛的橱窗"**，App 是"老客户的快捷通道"——只留后者，等于把入口关了一半。

☐ 下一节（1-4 什么是URL：FQDN、域名）