原文地址

React 的实践从去年在 PC QQ 家校群开始，由于 PC 上的网络及环境都相当好，所以在使用时可谓一帆风顺，偶尔遇到点小磕绊，也能够快速地填补磨平。而最近一段时间，我们将手 Q 的家校群重构成 React，除了原有框架上存在明显问题的原因外，选择 React 也是因为它确实有足够的吸引力以及优势，加之在 PC 家校群上的实践经验，斟酌下便开始了，到现在已有页面在线上正常跑起。

原文：https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/

作者：Yoav Weiss

译者按：网络优化一直是译者长期研究的方向，除了近期热门的 HTTP/2 之外，还是要关注浏览器在加载策略上的一些改进，从不同层面提升用户的访问体验。prefetch 这些 HTML5 的新特性，虽然很新鲜，但并未在生产环境中得到广泛使用，其中的原因是什么？preload 有什么改进？本文将娓娓道来~

========================译文分割线===========================

Preload（规范）是一项新的 Web 标准，旨在提升性能，让 Web 开发者对加载的控制更加粒度化。它让开发者有自定义加载逻辑的能力，免受基于脚本的 loader 所带来的性能损耗。

几周前，我在 Chrome Canary 提交了对 preload 的支持，解决了一些 bug，预计将在四月中旬合入 Chrome 稳定版。但 preload 到底是什么？它有什么用处？对你有什么好处呢？

做移动 web 页面，受移动网络网速和终端性能影响，我们经常要关注首屏内容展示时间（以下简称首屏时间）这个指标，它衡量着我们的页面是否能在用户耐心消磨完之前展示出来，很大程度影响着用户的使用满意度。

怎么获取首屏时间呢？

我们经常要先问自己：页面是怎么加载数据？

A：加载完静态资源后通过 ajax 请求去后台获取数据，数据回来后渲染内容

背景

为什么是 React？

React 今年在国内特别火，一时间虚拟 DOM（Virtual DOM）等酷炫概念一下刷新了很多前端开发同学的三观，关于性能优劣的争论也在知乎上看到不少。不得不说 React 解决了一些前端项目开发的痛点，而我最近的一年多的工作重心，都在兴趣部落这样一个基于兴趣社交的 web 产品上，有很多感同身受的地方。兴趣部落这个产品从初期只有移动端的 2、3 个页面，发展到现在 50+移动页面，加上 PC 版的最近上线，中间经历了从 2-3 人的小项目到 10+人团队的大型前端项目的巨大转变。这个过程中除了人员相对业务的线性增加，代码量、维护成本也是以指数速度增长的，很快代码臃肿、难以维护与测试等问题就凸显出来。虽然内部经过一些轻量的重构优化，但开发模式还是与高度的迭代节奏很不匹配。这时候，React＋Webpack 的组件开发模式让我眼前一亮，暗下决心要让这样的先进开发模式推广到项目团队，好东西一定要让大家有所受益，而不仅仅是技术的尝鲜、摆设。

译者说明

• 本文翻译自 Prefetching, preloading, prebrowsing，为了阅读通畅，部分技术术语就不做蹩脚的翻译了。
• 原文中有很多扩展文章的链接，都是对所在章节的详细说明，个个都值得一读。

使用 window.performance 提供了一组精确的数据，经过简单的计算就能得出一些网页性能数据。

配合上报一些客户端浏览器的设备类型等数据，就可以实现简单的统计啦！

额，先看下兼容性如何：http://caniuse.com/#feat=nav-timing

这篇文章中 Demo 的运行环境为最新的 Chrome 的控制台，如果你用的是其他浏览器，自查兼容性哈~

对于传统的页面模型来说，数据的拉取+渲染模型如下：

在页面的 head 部分，使用 jsonp 预拉取 cgi 资源，然后在资源加载完成之后，检查预拉取的数据是否已经返回，如果已返回，则直接用该数据渲染（避免了先用缓存数据渲染再用 cgi 数据渲染导致的二次刷新），否则才用缓存数据渲染。

前言

html css javascript 可以算是前端必须掌握的东西了，但是我们的浏览器是怎样解析这些东西的呢 我们如何处理 html css javascript 这些东西来让我们的网页更加合理，在我这里做了一些实验，总结起来给大家看看。