原文地址

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 屬性，做到只加載需要的資源：