走进 MIP，了解你不知道的移动 Web

Posted 2021-04-30 GitChat精品课

从万维网（Web，以下简称 Web）成立，距今已经 29 年了。在 PC 时代，可以说 Web 统治了整个移动互联网，但进入移动时代后，随着 Native App 的兴起，Web 丧失了互联网的绝对统治力，但却依然是当今移动互联网中占据大量应用场景和流量。

移动 Web 的症结

移动 Web 丧失统治力事出有因，我个人把原因归结为三个方面，具体如下：

标准的缺失

W3C 以及业界公司没有一套针对移动 Web 体验而设计的开发标准，导致移动 Web 在移动互联网时代早期开始体验差距与 Native App 较大，无法满足移动用户的需求。（此处值得注意的是，大家平常说的 html5 标准并不是针对移动互联网而设计的标准，而是由几大浏览器 Chrome、Safari、Firefox 共同推进的新 HTML 标准）

国内浏览器实现参差不齐

除了标准缺失以外，Web 的容器层能力对于 Web 体验来说至关重要。在移动互联网时代，移动浏览器一直都是重要入口，而从当前的结果来看，大多数优秀的移动应用使用体验，并不是由移动浏览器这个入口产生的，特别是国内。

国内许多浏览器并没有基于 Web 标准进行 Web 的体验优化，而是自己集成了非公开的标准实现以及部分强制的『体验优化』，导致一个 Web 页面在多个浏览器下体验不一致，并且使用能力受阻。

流量分发平台引导缺失

移动 Web 丧失统治力的另一个重要原因是在移动互联网早期（2011~2015），包括搜索引擎、社交平台都没有过多思考所管理与分发的 Web 站点的体验与 Native App 的差距，并且也没有提供可行的 Web 技术解决方案，导致当前很少出现优秀的移动 Web 应用。

综上，国内的 Web 生态当前并不太好，但 Web 具备其他互联网应用技术无可取代的特征：互联、自由、开放，每一个站点都有自己独立的域名和 URL，可被任何人在任何终端方便快捷的访问、分享。基于以上，我个人认为 Web 在移动时代只是暂时失去统治地位。如果移动 Web 的缺陷与问题被解决，将会重归统治地位，创造新的繁荣。

改善移动 Web 体验的新技术

近几年，移动 Web 中出现了大量改善移动 Web 站点体验以及 Web 开发体验的技术。在移动 Web 站点体验改善方面，包括：国外 Google 推出的 AMP、国内百度推出的 MIP，以及面向未来的移动 Web 应用技术——PWA。在 Web 开发体验方面，包括 Vue、React、Angular 等组件技术。

MIP/AMP

MIP，Mobile Instant Pages ，是一套应用于移动网页的开放性技术标准。通过提供 MIP-HTML 规范、MIP-JS 运行环境以及 MIP-Cache 页面缓存系统，使得移动页面更加符合移动上用户体验的要求。

MIP 的官方网站是：https://www.mipengine.org/，

AMP（Accelerated Mobile Pages）是谷歌提供的网页加速技术，其官方网站是：https://developers.google.com/amp/。

PWA

PWA 没有一个唯一且准确的定义，它是一个用 Web 技术创建的 App，不用打包，不用签名，可以离线工作，如果你愿意，还可以添加到桌面上，看起来就和其他应用一样。

可以通过这里了解更多 （https://lavas.baidu.com/pwa/README）PWA 相关的资料。

MIP 关键技术剖析

本章节不会全面的介绍 MIP 的全部技术细节，而是挑选其中作者觉得关键的部分，为大家详细讲解。如果想全面了解 MIP，请查阅 MIP 官网（https://www.mipengine.org/）。

如上一章节介绍，MIP 是一个移动 Web 应用的构建技术，其中包含了 HTML 规范、组件技术、云端加速技术、校验器等多个关键技术点。

本文中，作者挑选了 MIP 框架核心，MIP 的组件以及云加速（Cache）三个核心技术做详细讲解。其他技术细节大家可以通过查阅 MIP 官网资料或在后续文章中详细讲解。

框架核心

通过 MIP 技术构建一个标准的 Web 页面时，需要加载一个 MIP 的 JS Lib，而这个 JS Lib 就是 MIP 的框架核心代码，它负责 MIP 页面的基础依赖管理、通用的生命周期和视图逻辑处理，并内置部分核心组件。

基础依赖管理：负责注册和加载页面中的 MIP 组件，并提供通用的工具方法。

通用生命周期：包括页面整体展现渲染的时机控制以及页面内部的生命周期控制（例如 Dom Ready）。

视图逻辑处理：包括与外层容器的通信机制、手势与视图属性管理的封装。

内置的部分核心组件：包括mip-img、mip-video、mip-iframe等页面常用的组件。

由于篇幅原因，本小节不进行详细源码的解读，如果大家对本章节的技术设计以及源码解读感兴趣，请留言，并注明希望详细讲解此章节。后续我择机安排此章节的 Chat。

组件机制

MIP 组件使用了 Web Components 标准中的 Custom Element 机制，符合 Web Components 标准。这部分的内容已经存在了很多优秀的博文，在本节不对这部分知识进行展开讲述。

MIP 组件有模板、自定义标签、异步加载等特性。组件之间是互相独立的，能够独立的进行自渲染，同时，MIP 组件提供了一套事件机制可以完成组件间通信。

组件是 MIP 页面的最小页面的功能元素， MIP 页面通过引用 MIP 组件来实现页面中的交互或者比较通用的功能，如：轮播图、折叠等。这些组件都是通过对移动 WEB 页面中的一些功能抽象，然后细致的封装而成，这些组件的功能兼容所有移动端的浏览器和 PC 端支持 H5 特性的浏览器。

在页面中使用 MIP 

使用一个 MIP 组件的方法很简单，只需两个即可搞定。

1.第一步：引入 MIP 组件 JS，例如：

<script src="https://c.mipcdn.com/static/v1/mip-showmore/mip-showmore.js"></script>

2.在页面中使用此组件，例如：

<mip-showmore maxheight='40' animatetime='.3' id="showmore03">
    【外层元素】MIP是一套应用于移动网页的开放性技术标准。通过提供MIP-HTML规范、MIP-JS运行环境以及MIP-Cache页面缓存系统，实现移动网页加速。MIP是一套应用于移动网页的开放性技术标准。通过提供MIP-HTML规范、MIP-JS运行环境以及MIP-Cache页面缓存系统，实现移动网页加速。    <mip-showmore maxheight='40' animatetime='.3' id="showmore04">
    【内层元素】MIP是一套应用于移动网页的开放性技术标准。通过提供MIP-HTML规范、MIP-JS运行环境以及MIP-Cache页面缓存系统，实现移动网页加速。MIP是一套应用于移动网页的开放性技术标准。通过提供MIP-HTML规范、MIP-JS运行环境以及MIP-Cache页面缓存系统，实现移动网页加速。    </mip-showmore>
    <div on="tap:showmore04.toggle" data-closetext="收起内层内容" class="mip-showmore-btn">点击显示内层</div></mip-showmore><div on="tap:showmore03.toggle" data-closetext="收起外层内容" class="mip-showmore-btn">点击显示外层</div>

构建一个 MIP 组件

如果想开发一个组件，可以通过此文档进行了解查看（https://github.com/mipengine/mip-extensions/blob/master/docs/develop.md）。

组件生命周期

MIP 组件设计时提供了对应的生命周期的 API，可以供开发者在不同的生命周期 API 上定义组件不同的处理逻辑，具体 API 包括如下：

createdCallback //组件完成Dom创建attachedCallback  //组件添加到Dom节点上detachedCallback //组件从Dom节点上移除attributeChangedCallback  //组件属性发生变化后firstInviewCallback  //首次进入可视区域viewportCallback  //视图初始化完成prerenderAllowed  //允许被预渲染hasResources  //有用其他资源依赖build  //组件构建时

组件的未来规划

如前文所说，MIP 组件是一套基于 Custom Element 的组件技术，在之前主要集中解决的是页面加载时渲染速度慢的问题，但随着 MIP 技术覆盖的业务场景越来越复杂，当前的组件机制已经无法满足部分站点的开发体验要求，MIP 组件在规划进行组件机制的全面升级与重构，主要预期升级技术点考虑以下几方面：

1. 更完整的组件模板机制；

2. 更友好的数据绑定 API；

3. 更严格的视图渲染规范；

组件相关的技术点已经为大家做了介绍，希望大家能从中学习到 MIP 组件机制设计的思路，如有问题，大家可以通过留言进行讨论。

Cache

Cache 是 MIP 技术的一个重要组成部分。接下来我会给大家介绍 Cache 的设计初中，以及 Cache 的机制和未来 Cache 的规划。

Cache 设计初衷

MIP Cache 希望给所有符合规范的 MIP 页面提供 CDN 缓存服务，能够主动的提高页面加载速度，为使用 MIP Cache 服务的页面上的图片、CSS 文件等资源提供缓存服务，这样能做到所有 HTTP 请求来自于同源，能够加速加载速度。并且缓存后的页面都是 HTTPS 的，安全性更高。

Cache 机制详解

页面被 MIP Cache 模块存储后，Cache 模块会进行以下资源的抓取和替换，保证 Cache 页面的整体性能。

1. 网页地址或 CSS、javascript
HTTPS 资源：

源地址：https://www.mipengine.org
MIP-Cache 地址：https://www-mipengine-org.mipcdn.com/c/s/www.mipengine.org HTTP 资源： 源地址：http://www.mipengine.org
MIP-Cache 地址：https://www-mipengine-org.mipcdn.com/c/www.mipengine.org2. 图片
HTTPS 资源：

源地址：https://www.mipengine.org/static/img/mip_logo_3b722d7.png
MIP-Cache 地址：https://www-mipengine-org.mipcdn.com/i/s/www.mipengine.org/static/img/mip_logo_3b722d7.png HTTP 资源： 源地址：http://www.mipengine.org/static/img/mip_logo_3b722d7.png
MIP-Cache 地址：https://www-mipengine-org.mipcdn.com/i/www.mipengine.org/static/img/mip_logo_3b722d7.png

站点 Cache 更新一般遵循以下规则：

1. 页面的缓存时间为 52 分钟 - 5 天（由该页面用户点击量和站点本身稳定性决定）。

2. 图片缓存时间为 10 天。

3. MIP-JS 组件文件的缓存时间为 10 分钟。

值得注意的是，在当前文件过期后，MIP Cache 会重新抓取资源。如果是 HTML 页面，MIP Cache 还会对页面文件进行 MIP 规范校验。如果此时页面内容不再符合 MIP 规范，MIP Cache 就不再缓存这个页面了。这样，所有 MIP Cache 中的页面都是最新的，并且符合 MIP 规范。

Cache 的未来规划

用心的读者可能已经意识到 Cache 提供的是一套自己定义的规范和规则，在 MIP 和 AMP 推出了类似的 Cache 技术以后，Google Search 和百度搜索也在积极沟通，尝试建立一套标准的 Cache 的解决方案。希望这一套 Cache 技术中的部分通用处理逻辑能成为新的云端加速站点的解决方案。

点击这里（https://github.com/WICG/webpackage/blob/master/explainer.md）可以详细了解标准细节。

总结：MIP 解决了什么问题

MIP 技术的推出，在过去一年是为了解决以下两个问题：

1. 提升百度搜索落地页浏览的速度体验与交互体验；

2. 改善百度搜索的 Web 生态，引导更多站点使用先进的 Web 技术改造自己的站点，满足移动时代的用户体验需求。为此，我们还在搜索端通过容器技术让搜索结果中进行 MIP 技术改造站点的速度和交互得到改善。

MIP 以及 移动 Web 的未来

MIP 并不能完全代表移动 Web 的未来，MIP 是百度为 Web 开发者提供的一套解决当前移动 Web 体验问题的解决方案，下文将为大家描述作者认为的移动 Web 应该有哪些体验与技术。

理想的移动 Web

我们希望未来的 Web 是这样的：

用户的需求可以在不同的信息、服务提供者之间流畅的切换，并且被深度的满足，不会受到容器、平台的限制；

内容提供者和开发者不需要为多个中心化的平台开发不同的版本，而且内容、服务可以被划分为最小粒度，被各个中心化的平台索引并且有效分发，获取流量和用户，产生价值；

每个流量分发平台可以正确、有效的索引移动互联网上的资源，并且通过各自的能力给平台上的用户提供体验标准统一的内容和服务。平台与平台之间的竞争，回到本质的能力竞争，比如：检索能力、推荐能力、获取用户的能力等；

在这样的移动互联网生态下，标准是开放统一的，流量分发平台、内容提供者、开发者共建统一标准，共同推动移动互联网的发展，共享生态繁荣，让用户需求可以最直接的、有效的、深度的被满足。

移动应用体验原则

为了能达到理想移动 Web 的目标，我们倡导所有 Web 的开发者都能通过以下交互体验原则去要求自己的 Web 站点的体验：

• 快速的信息呈现

• 优秀的手势反馈

• 平滑的场景切换

• 沉浸式的浏览

• 连贯的消费流程

关于几大原则的详细解释，希望后续能通过其他的 Chat 与大家分享，请大家留意我的 Chat 发布。

App Shell

App Shell 是 Google 提出的一种应用模型，它对一个 Web 站点是否是 App Like 至关重要。App Shell 是支持用户界面所需的最小的 HTML、CSS 和 JavaScript，如果离线缓存，可确保在用户重复访问时提供即时、可靠的良好性能。这意味着并不是每次用户访问时都要从网络加载 App Shell。 只需要从网络中加载必要的内容。

Web Componen

Web Component 技术是笔者认为将会应用于未来的 Web 应用构建的核心技术之一，它包含以下几个关键技术：

1. Custom Element；

2. Shadow Dom；

3. HTML Template；

4. HTML Import；

感兴趣的读者可以自行查阅资料学习了解。以上每一个技术都值得单独开一个 Chat 进行讲述，如有机会，后续将发布此类技术的 Chat。

容器和浏览器

对容器（浏览器）而言，首先应该做好对目前标准化的支持，标准化意味着更好的兼容性、更少的 bug，对于 WEB 开发者来说就是更低的开发成本。 其次，从推进 WEB 生态发展角度出发，把应用层的开发框架落地为容器内置支持的功能，更加彻底解决 WEB 上的体验问题。 

若浏览器开发者想实现标准之外的功能，除了给自己的 API 增加私有化前缀之外，也应当尽量地按标准的方式设计、实现。这样，更强的功能与 API 可以推广，并吸引更多的网页开发者使用，有了更多的用户、更多的开发者，就可以作为标准的制定者，引导整个工业界的发展。

百度搜索与 Web 生态

Web 的特征是每一个内容、每一个服务都是一个全局可见的 URL，用户可以通过超文本传输协议自由、开放地获取和访问这些内容与信息。搜索则是基于大部分万维网的 URL 与小部分其他封闭的数据去发现和索引信息，将其组织成为内容与服务提供给用户。

对于搜索引擎来说，互联网上封闭的信息是无法被搜索引擎，并且这些封闭的信息没有提供一种标准且有效的协议用于标识内容信息。信息的开放是互联网能持续繁荣的根本原因，也是搜索能持续进化的必要条件。

在 Web 生态中，搜索引擎、分类网站、门户网站等对 Web 起引导作用的角色，拥有流量分配的能力，我们称之为引导者。对引导者而言，给符合体验原则并且可被检测的 Web App 给予更多的流量倾斜。

在影响工业界的路径上，引导者应当大力鼓励开发者和浏览器使用标准化方式进行开发，避免 Web 生态的碎片化。引导者应广泛参与标准的制定，推动浏览器支持标准。

如果你对本文有疑问，

或者想和作者进行技术交流，

扫描下方二维码，

加入读者圈与作者聊天~：