原文地址

Web 项目上线后，开始开门迎客，等待着来自大江南北、有着各式各样网络状态的用户莅临。在千差万别的网络状态中，访问页面难免会遇到前端资源加载失败的情况，占比或许不高，但一遇到，轻则页面样式错乱，重则白屏打不开，影响用户体验感受，紧急情况下甚至影响了用户的工作，属于非常严重的问题。本文将从如何监控加载失败、加载失败如何优化、始终加载失败又该如何处理等问题逐一分析。

在 《XSS 终结者-CSP 理论与实践》 中，讲述了 CSP 基础语法组成与使用方式。通过一步步的方案制定，最终我们利用 CSP 提供的域名白名单机制，有效地将异常的外联脚本拦在门外。然而在线上环境千千万万，虽然我们限制了外联脚本，但却仍被内联脚本钻了空子。

Web Worker 文献综述

Web Worker 作为浏览器多线程技术, 在页面内容不断丰富, 功能日趋复杂的当下, 成为缓解页面卡顿, 提升应用性能的可选方案.

但她的容颜, 隐藏在边缘试探的科普文章和不知深浅的兼容性背后; 对 JS 单线程面试题倒背如流的前端工程师, 对多线程开发有着天然的陌生感.

Web Worker 介绍

众所周知，JavaScript 这门语言的一大特点就是单线程，即同一时间只能同步处理一件事情，这也是这门语言衍生出的 nodeJS 被各后端大佬诟病的很重要的一点。

脚本错误量极致优化-定位压缩且无 SourceMap 文件的脚本错误

”JS 代码压缩后，定位具体出错代码困难！“ 的问题，我们可以通过 SourceMap 快速定位，处理得到源文件的具体错误信息。具体方式可以查看 《脚本错误量极致优化-让脚本错误一目了然》

然而当项目外链第三方资源或公共库时，这种压缩且无提供 SourceMap 的文件出现异常，又该如何更好的定位错误位置呢？

在传统的 web 优化中，我们可以采取压缩、拆包、动态加载等方法减少首屏资源大小，也能通过离线包、页面直出等方案加速 html 返回，之前一篇 h5 秒开大全有部分简析。在大部分场景中，这些方案都足够用，也能得到出色的效果。但仍有两种无法尽善尽美的地方：其一是短暂的白屏现象不可避免，其二是对于超大型 web 应用难以做到秒开。结合客户端特性，我们有没有办法，进一步做到极致，打开 web 页面和打开客户端页面无差异的体验呢？

前言

最近在研究网站测速相关的主题，接触到一个概念：First Meaningful Paint，简称 FMP，中文译名：首次有效绘制时间。今天我们来讲讲这个概念的来龙去脉。

写在前面

Omi 框架 正式发布了 → omi-transform。

Made css3 transform super easy. Made 60 FPS easy.

作为 Omi 组件化开发特效运动解决方案，让你轻松在 Omi 项目里快速简便支持 CSS3 Transform 设置。css3transform 是经受过海量项目洗礼的，作为移动 Web 特效解决方案，在微信、手 Q 兴趣部落、日迹、QQ 群、QQ 附近等项目中广泛使用，以激进的修改 DOM 属性为代价，带来极为便利的可编程性。

你可以通过 css3transform 官方首页快速了解它。

原文地址

那一天，我收到设计姐提供的图片

立志成为一位优秀工程师的我，看图深思..

为了节省流量（流量就是金钱）
为了让图片更快加载（更好的体验）

==============接上篇 Preload：有什么好处？（上）=================

译者注：上文讲到了利用 Preload，我们可以做到哪些事情，从这里继续～

响应式加载（RESPONSIVE LOADING）

因为 Preload 是一个链接，遵循规范它应有 media 属性（目前 Chrome 还未支持，不过很快就可以了）。这个属性可以启用资源的条件加载能力。

它又有什么用处呢？举个例子，你的网站的初始视窗，对于 PC／宽屏设备展示可交互的地图版本，而对于手机／窄屏设备则展示静态的地图版本。如果你擅于加载性能优化，会想到在特定设备只加载其中一个版本的资源，而不是所有资源。而要做到这样唯一的办法就是使用 JS 去动态地加载资源。但是这么做，会使得资源对于 preloader（译者注：上文提到过的浏览器内部的预加载器）不可见，因此会使得资源的加载时机稍微滞后，不但影响了用户的视觉体验，还对站点的 SpeedIndex  得分有着负面影响。

所以我们该怎么做，才能让浏览器尽早知道所需加载的资源呢？没错，就是 Preload！

我们可以使用 Preload 提前加载这些资源，并且使用 media 属性，做到只加载需要的资源：