经由不断的优化，目前今日头条中详情页在线上的打开体验，从肉眼上基本已经感知不到加载过程。在接下来这篇文章里，我们会逐步拆解和先容我们对详情页加载优化的思路和实践。
先让我们来看看优化前后的效果吧~
今日头条详情页加载体验优化前
今日头条详情页加载体验优化后
数据建立性能当我们开始动手优化页面加载速率之前，我们须要明确一个问题，若何才是用户真正体验到的页面加载韶光。
首先我们可以看下面这个公式：
页面加载韶光=页面加载完成韶光-页面开始加载韶光
页面开始加载韶光很好确定，当用户点击了 Feed 上的卡片，我们就可以认为页面开始加载了。
问题是怎么定义页面加载完成了呢？从客户真个角度上看，无论是 iOS 还是 Android，WebView 都供应了一个 loadFinsih 的回调，但在实际运用中我们创造，loadFinish 回调并不能反应用户的真实体验。
一样平常来说，WebView 渲染须要经由下面几个步骤
解析 HTML 文件加载 JavaScript 和 CSS 文件解析并实行 JavaScript构建 DOM 构造加载图片等资源页面加载完毕而 loadFinish 实际上是在页面加载完毕阶段，而 DOM 构建完成时页面构培养已经基本渲染完成，以是从用户真实体验的角度出发，我们以 DOM 构造构建完成（即 domReady）的韶光点作为页面加载完成韶光点。
白屏在详情页浏览过程中，除了页面加载速率之外，还有一个特殊影响用户体验的问题，便是页面的白屏，也是早期的时候用户反馈比较多的问题，但有很多场景都可能导致详情页发生白屏，比如说网络非常，WebView 非常等等，须要从用户体验的角度出发去检测用户发生白屏的情形。
目前可以想到最直不雅观的方案便是对 WebView 进行截图，遍历截图的像素点的颜色值，如果非白屏颜色的颜色点超过一定的阈值，就可以认为不是白屏，目前须要考虑的是这个方案的性能问题和检测机遇。
iOS 中供应了 WebView 快照的接口获取当前 WebView 渲染的内容，底层采取异步回调的实现办法，API 耗时 10ms 旁边，用户基本无感知。
-(void)takeSnapshotWithConfiguration:(nullableWKSnapshotConfiguration)snapshotConfigurationcompletionHandler:(void(^)(UIImage_NullablesnapshotImage,NSError_Nullableerror))completionHandlerAPI_AVAILABLE(ios(11.0));
Android 中系统供应的获取视图内容的接口为 getDrawingCache，API 耗时在 40ms 旁边，性能损耗也不是特殊大。
除了截图的性能损耗，像素点检测也是白屏检测中比较耗时的场景，经由实验，我们把 WebView 截图的图片进行缩小到原图的 1/6，遍历检测图片的像素点，当非白色的像素点大于 5% 的时候我们就认为是非白屏的情形，可以相对高效检测准确得出详情页是否发生了白屏。
指标建立确定好口径之后，我们还有须要明确的一个问题是，什么指标可以反响用户刷头条时的真实体验。
最早的时候，我们用的是详情页页面的页面均匀加载时长，也便是页面加载时长的总和/页面 pv，在开始的时候这个指标也的确可以明确我们的加载速率。
后来随着详情页的加载优化逐渐的深入，会创造均匀加载时长虽然也可以反响详情页加载速率，但是由于详情页的 pv 比较高，如果利用均匀加载速率化很多用户体验问题就被均匀掉了，并不能反响用户的真实情形，后面我们又调度了口径，将指标调度为所有用户进入详情页的 80 分位值，比如说，如果头条详情页加载速率 80 分位值是 1 秒，那么就解释 80% 的情形下用户进入详情页都能在 1s 内加载完成，当然经由我们的不断优化，详情页加载的 80 分位值已经能够达到 0.3s 以内，也便是说，80% 的情形下用户都能够在 0.3s 内完成页面加载。
80分位优化数据比拟
再后来我们又创造，在头条详情页的量级下面，纵然是 80 分位的数据也不能反应许多长尾用户的真实情形，也为了更极致的追求详情页的加载性能，我们末了将详情页的性能口径调度到 95 分位。到目前在我们的努力下，今日头条详情页的加载速率 95 分位也优化了将近 80% 。
我们究竟做了什么呢，接下来会逐步先容一下。
模板优化模板拆分如前所述，图文详情页是通过 WebView 来承载的，而 WebView 承载页面最大略的做法便是直接通过 URL 去加载一个线上页面。那么先来一道大略的口试题，当用户从浏览器输入一个 URL 到页面展现发生了什么呢？
之前已经先容过页面的渲染流程了，现在我们再大略看看用户从点击到看到页面内容须要经历如下几个阶段：
WebView 加载流程
可以看到，通过线上页面加载用户每次进入详情页都要通过多次网络加载，极随意马虎受网络颠簸的影响，这种情形下，也无法担保页面加载的时长和成功率，极大的影响了用户体验。
于是在头条中，我们将新闻中标题和正文内容进行拆分，把头条详情页的公共样式 CSS 和 逻辑 JS 都抽离出来，形成一个独立而完备的详情页模板，这样我们就可以把模板直接内置在客户端中。
同时我们会与前端约定好的 JS 脚本，通过接口将正文内容数据注入页面完成详情页的页面展示，通过该这种办法我们可以将接口放到客户端上进行要求。
这样用户进入详情页的时候只须要本地加载模板，而且加载模板的时候也可以同时并行要求详情页数据，再将数据注入进模板中。
那么用户点击到看到页面内容只须要经历下面的阶段：
模板拆分
如上图所示，我们只须要通过一次网络加载就可以完成页面渲染。
还能不能更快一点呢？当然能！
为了提高页面的加载速率，客户端通过一定的策略去预加载新闻数据，这样在空想状态下用户进入页面时看到页面时就可以直策应用缓存的数据，用户在看新闻的时候可以实现完备离线化，避免受到网络的影响。
本地加载
模板预热完备分开了网络加载之后，还能再快一点呢？当然还是可以的！
当全流程离线化之后，页面加载的瓶颈就变成了本地模板的加载韶光，以是我们接下来要做的便是优化模板加载韶光。
对付模板来说，我们做了两件事情
模板合并，正常来说，WebView 须要在加载玩主 HTML 之后再去加载 HTML 中的 JS 和 CSS，须要多次 IO 操作，于是我们将 JS 和 CSS 还有一些图片都内联到一个文件中，这样，加载模板时就只须要一次 IO 操作，也大大减少由于 IO 加载冲突导致模板加载失落败问题模板简化，我们将部分非必须的脚本异步化拉取，精简不必要的样式和 JS 代码，将模板大小压缩了 20% 以上通过上面优化，我们就已经将模板加载韶光大大优化了，但是还能不能更给力呢？还是可以的。
对付客户端来说，当模板跟数据分离之后，由于每次用户点击的时候加载的都是同一个模板，以是实际上，我们并不须要在用户进入页面的时候才去创建 WebView 以及加载模板，我们只须要在得当的机遇在后台创建 WebView，并且提前预热加载模板，当用户点击进入页面的时候就能利用已经加载好模板的 WebView，直接将详情页的内容数据通过 JS 注入到页面中，前端收到数据后进行页面渲染即可。
此时用户进入详情页实际就不再须要重新加载模板了，路径就变成了：
模板预热
可以看下，通过本地测试的模板预热和数据预取的优化效果，还是比较明显的，基本上已经达到了上面的截图中的验证效果。
本地测试数据
模板复用
当我们拆分完模板和数据之后，数据上优化已经比较明显，但我们说过，除了验证数据，我们还须要看线上用户的真实体验数据，从 95 分位上看实际数据优化却不是很明显，以是我们从数据上不雅观察，用户预热模板的命中率只有 53%，还有进一步的提升空间。
模板预热率
为了尽可能的提高页面的加载速率，我们希望用户每次进入详情页的时候都能够利用预热好模板的 WebView，一样平常情形下，我们都会利用模板预创建池的手段来优化用户进入详情页时的预热模板命中率。
但其实在很多情形下，WebView 的创建是一个性能开销比较大的操作，如果我们利用预创建池的方案，那么就会在后台频繁创建 WebView，这样对用户在 Feed 场景的浏览体验也会有一定的影响。
而且如果用户频繁且快速进出详情页时，实际场景中用户也很随意马虎碰着无法命中预热模板的场景。
这个时候为了优化用户的体验，如前文所述，我们每次利用的时候都是同一个模板，以是我们利用完当前 WebView 之后，只须要在用户退出页面的时候把正文数据清空，这样进入下一个页面的时候就能够连续复用这个 WebView 重新注入数据即可。
通过这个手段，我们既避免了频繁在后台预创建 WebView 对用户刷 Feed 体验的影响，把用户进入页面时候的预热模板命中率从 53% 提升到 92%，优化了用户体验。
预热模板命中率
网络优化说完我们在模板 WebView 方面的优化之后，再先容一下我们在内容要求上的优化。
CDN 加速由于头条详情页要求有以下特点
流量大，之前说过，看新闻作为用户在头条的核心场景，每天都有上亿用户在利用头条，详情页的数据流量十分大。数据属性基本不变，在详情页的要求中，很多热点文章是重复渲染打算的，正文、标题、作者信息、图片掌握以及一些样式和业务逻辑渲染是基本不变的，这部分重复打算耗费了带宽、做事器资源，是比较没有必要的。用户分布广，网络状况难以担保，头条的用户量很大，覆盖了各种运营商网络和网络状态，网络质量无法得到很好的担保。而 CDN 能够将数据缓存在各地的边缘节点，用户就近接入了边缘节点，避免在网络质量无法担保的公网上永劫光传输，从而提高了相应速率和相应的成功率。接口数据大，由于正文数据的存在，接口返回的数据常常会很大，如果每一次都实时返回，对网络的压力会比较大，可能会把带宽打满而影响其他做事以是我们将详情页内容数据分为静态和动态两部分，将正文内容、标题、作者栏等用户紧张消费的又基本不变的内容托管到了 CDN 上。
CDN 的全称是 Content Delivery Network，即内容分发网络。其目的是通过在现有的 Internet 中增加一层新的网络架构，将网站的内容发布到最靠近用户的网络“边缘”，利用户可以就近取得所需的内容，提高用户访问网站的相应速率。CDN 有别于镜像，由于它比镜像更智能，或者可以做这样一个比喻：CDN=更智能的镜像+缓存+流量导流。因而，CDN 可以明显提高 Internet 网络中信息流动的效率。从技能上全面办理由于网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问网站的相应速率。
托管到 CDN 之后，全国各地的用户可以直接从最佳节点就获取到详情页数据，也大大节省了带宽本钱。
容灾1. 多域名备份
为了防止某个 CDN 涌现故障，导致做事雪崩，做事端会下发多个 CDN 链接，当用户访问当前 CDN 节点的出非常时，可以快速自动切换到下个 CDN 节点。
2. 快速超时
一样平常的超时策略，客户端在要求时，会遍历要求 CDN 1、2、3。如果这些 CDN 都要求失落败，则全体网络要求算作失落败。
但这个方案的问题是，假设要求 CDN 的超时时间是 15s。如果 CDN 1 涌现故障，则须要等待 15s 才能切换到 CDN 2 上，这对付详情页的加载韶光来说是不可接管，如果用户网络溘然变差，则须要等待 45s 才能返回失落败展示缺点页。
基于此我们设计了详情页要求的快速动态超时策略
单次要求 CDN 的超时时间，根据上次成功要求 CDN 的值打算，因子 1.5（z 值）。且最小为 1s（x 值），最大为 4s（y 值）。超过这一韶光不取消，直接要求下个 CDN。单次要求 CDN 有一个硬性超时时间 4s（w 值，w 需>=y），超过这一韶光要求取消。n 个 CDN 的要求全部取消后反馈用户失落败。几个 case：
第 1 个 CDN 溘然挂掉（假设上次成功要求的耗时为 a） 下一次要求：第一个 CDN 很快超时（a _ 1.5）；开始要求第二个 CDN（超时时间为 a _ 1.5，但实际上 b 秒就会返回要求）。用户本次等待韶光为 a _ 1.5 + b 下两次要求：第一个 CDN 很快超时（b _ 1.5）；开始要求第二个 CDN（超时时间为 b _ 1.5，但实际 c 秒就会返回要求）。用户本次等待韶光为 b _ 1.5 + c用户溘然进入了一个网络很差的环境（假设上次成功要求的耗时为 a） 下一次要求：第一个 CDN 很快超时（a _ 1.5）；开始要求第二个 CDN（a _ 1.5）也超时；开始要求第三个 CDN（a _ 1.5）。末了一个要求会在 a _ 3 + w 后返回失落败（这个值会在 12s 以内）。可以看到，通过多域名备份和快速超时的策略，即利用户在网络或者做事非常的情形下，也能快速规复或者让用户能感知到自身网络问题。
渲染优化当我们在模板层和网络层优化到极致的时候，限定我们的便是 WebView 的渲染速率了！
正常来讲，正常的内容数据可能是类似 JSON 等数据，客户端获取到数据之后，将数据注入给前端，前端还须要将 JSON 数据跟模板进行组装，拼上 HTML 标签等模板了之后再呈现到 WebView 渲染，导致前端渲染上耗时也比较久。
为了提高用户的首屏效率，我们在做事端就会把所有的详情页正文的 HTML 数据组装好，通过将做事端直出内容注入到页面中时，可以直接给 WebView 进行渲染，对付其他动态下发的内容（比如干系搜索），前端再进行二次异步处理，提升用户效率。
客户端渲染一样平常来说，我们正文中所有内容都是通过 WebView 渲染，经由上述的优化之后，文章的笔墨部分渲染效率已经很高了，但是实际场景中，很多文章会包含比较多的图片和视频场景。
在实际场景中，WebView 渲染非笔墨内容会存在以下问题：
比较于笔墨内容，非笔墨内容比如说图片和视频类资源的渲染对付 WebView 来说渲染效率比较差在详情页中文章有大量图片的场景，对付 WebView 的渲染内存占用和滑动体验也有问题末了，如果用户多次打开同一篇文章，这篇文章中的图片也会存在多次加载的问题，无法与客户端进行缓存共享，对用户的流量也是一种摧残浪费蹂躏。以是在详情页中，我们会将图片和视频等非笔墨内容通过原生组件的办法放在客户端进行渲染，既可以提高渲染效率，也可以减少不必要的流量花费。
原生化渲染还有一个好处，图片越来越成为文章体验的主要部分，对付多图文章，我们在 Feed 页面也可以智能加载详情页须要的图片，增加用户的文章首屏体验。
白屏优化讲完了性能优化，末了再分享一下我们对详情页白屏率的一些优化，实在很多用户反馈白屏问题大部分都可能是由于网络等问题导致页面加载韶光过长，导致用户从体验上不雅观感是白屏了，这部分通过上面分享的性能优化手段已经能够办理，以是下面只是大略先容下一些非网络缘故原由的白屏问题。
我们通过白屏检测和上报之后的数据剖析之后创造，非网络缘故原由导致的详情页的白屏问题大体是 WebView 加载的问题。
在 iOS 中，我们利用的是系统供应的 WKWebView，WKWebView 是运行在一个独立进程中的组件，以是当 WKWebView 上占用内存过大时，WKWebView 所在的 WebContent Process 会被系统 kill 掉，反响在用户体验上便是发生了白屏。
根据网上的做法，我们可以在 WKWebView 供应的回调 webViewWebContentProcessDidTerminate 函数中通过 reload 方法重新加载当前页面规复，但是这种情形只适用于通过 loadRequest 加载的要求，在详情页中，由于利用了模板化的 WebView 中，重新 reload 只能重新 reload 模板，并不能正常规复全体详情页，须要客户端重新加载模板之后再重新注入数据。
其余由于我们有预热模板的逻辑，以是可能在进入详情页的时候利用的 WKWebView 就已经崩溃，在调用 JS 注入数据时会直接返回失落败，失落败时，我们会考试测验重新加载模板。但后来实际操作中创造一个问题，如果直接调用数据注入的方法，等待系统 WebView 返回失落败的回调耗时比较久，所往后续也调度了数据注入的接口，我们提前在注入的脚本中止定是否存在数据注入的接口，如果不存在，就解释模板存在问题，直接重试即可。
而在 Android 中，我们采取的是自研内核 WebView，也会碰着一些奇奇怪怪的坑。
多线程读模板文件问题，WebView 在运行中会读取的文件模板，如果此时其余一个线程同时更新模板文件时，就涌现了模板加载问题，以是须要担保模板加载的原子性Render 卡去世问题，内核是一个比较繁芜的逻辑，内部渲染极少数情形也会涌现 Render 卡去世问题，但是在详情页整体用户的量级下，纵然只有十万分之一的可能，对用户来说也是一个比较大的问题，此时我们会从业务上做白屏监控进行重试当然不管是 iOS 和 Android， WebView 加载的逻辑都比较繁芜，有时候怎么重试也无法成功，这个时候我们会直接降级到加载线上的详情页，优先担保用户的体验。
总结限于篇幅缘故原由，我们还做了很多其他事情，包括要求精简，push 文章预拉取，数据注入的办法优化等等，也做了很多其他的方向的探索，这里不做展开，希望有机会能再分享给大家。
末了总结一下我们在优化详情页打开速率之后的一些想法
数据很主要，我们在优化加载速率之前做的第一件事情实在是建立了一个详情页的数据看板，只有通过数据我们才能真正理解目前线上用户的现状，从真实用户的体验中找到瓶颈和优化点。用户体验优先，优化方案有很多，除了加载速率之外，还须要从整体运用体验出发，选择对用户最佳的方案追求极致，实在最开始的优化是比较大略的，但是越到后面越难，须要一点点抠细节，才能达到极致的用户体验更多分享Android Camera 内请安题阐发
字节跳动自研线上引流回放系统的架构演进
iOS大解密：玄之又玄的KVO
今日头条 Android '秒' 级编译速率优化
今日头条技能团队今日头条技能团队不仅致力于在业务上不断深耕挖掘，在技能上也一贯在追求极致的用户体验。
如果你也神往在一个亿级 DAU 业务里发展，也期待在技能上有突飞年夜进的提升，欢迎你加入我们。
无论你是 iOS/Android/前端/后端，我们在深圳/北京/广州等你来，一起做更有寻衅的事！
简历投递邮箱： tech@bytedance.com ；邮件标题：姓名-事情年限-头条技能团队。
欢迎关注字节跳动技能团队
