來自譯者 markzhai：大家也知道最近 Web 越來越火了，如果你還以為 Web 就是 jQuery、Ajax、CSS 什麼的，那你就 out 了。給大家幾個連結看一看吧：
部分可能需要自備梯子，另外建議在 Chrome 下檢視，畢竟該死的 X5，大家都懂得。
- 原文地址：Progressive Web Apps with React.js: Part I — Introduction
- 原文作者：Addy Osmani
- 譯文出自：掘金翻譯計劃
- 譯者 : markzhai
- 校對者：Tina92, DeadLion
使用 React.js 的漸進式 Web 應用程式：第 1 部分 - 介紹
漸進式 Web 應用程式利用新技術的優勢帶給了使用者最佳的移動網站和原生應用。它們是可靠的，迅捷的，迷人的。它們來自可靠的源，而且無論網路狀態如何都能載入。
在 漸進式 Web 應用程式 (PWAs) 的世界中有很多新東西，你可能會想知道它們和現有架構是如何相容的 —— 比如 React 和 JS 模組化打包工具如 Webpack 之間的相容性如何。PWA 是否需要大量的重寫？你需要關注哪個 Web 效能度量工具？在這系列的文章中，我將會分享將基於 React 的 web apps 轉化為 PWAs 的經驗。我們還將包括為什麼僅載入使用者路由所需要的，並拋開其他所有指令碼是提高效能的好方式。
Lighthouse
讓我們從一個 PWA manifest 開始。為此我們會使用 Lighthouse — 一個評審 app 面向 PWA 特性 的工具，並且檢查你的 app 在模擬移動場景下是否做的足夠好。Lighthouse 可以通過 Chrome 外掛 (我大部分時候都用這個) 以及 CLI 來使用，兩者都會展示一個類似這樣的報告：
來自 Lighthouse Chrome 外掛的結果
頂級評審工具 Lighthouse 會高效地執行一系列為移動世界精煉的現代 web 最佳實踐：
- 網路連線是安全的
- 使用者會被提醒將 app 新增到 Homescreen
- 安裝了的 web app 啟動時會帶自定義的閃屏畫面
- App 可以在離線/斷斷續續的連線下載入
- 頁面載入效能快速
- 設計是移動友好的
- 網頁是漸進式增強的
- 位址列符合品牌顏色
順便一提，有一個 Lighthouse 的 快速入門指南，而且它還能通過 遠端除錯 工作。超級酷炫。
無論在你的技術棧中使用了什麼庫，我想要強調的是在上面列出的一切，在今天都只需要一點小小的工作量就能完成。然而也有一些警告。
我們知道移動 web 是 慢的。
web 從一個以文件為中心的平臺演變為了頭等的應用平臺。同時我們主要的計算能力也從強大的，擁有快速可靠的網路連線的強大桌面機器移動到了相對不給力的，連線通常慢，斷斷續續或者兩者都存在的移動裝置上。這在下一個 10 億使用者即將上網的世界尤其真實。為了解鎖更快的移動 web：
- 我們需要全體轉移到在真實移動裝置，現實的網路連線下進行測試 (e.g 在 DevTools 的常規 3G)。 chrome://inspect 和 WebPageTest (視訊) 是你的好幫手。Lighthouse 模擬一臺有觸控事件的 Nexus 5X 裝置，以及 viewport 模擬 和 被限制的網路連線 （150毫秒延遲，1.6Mbps 吞吐量)。
- 如果你使用的是設計開發時沒有考慮移動裝置的 JS 庫，你可能會為了可互動效能打一場硬仗。我們的理想化目標是在一臺響應式裝置上 5 秒內變得可互動，所以我們應用程式碼的預算會更多是 ❤
通過一些工作，可以寫出 如 Housing.com 所展示的 在有限網路環境下，真機上依然表現良好的使用 React 開發的 PWAs。我們在接下來的系列中討論如何實現的詳盡 細節。
話雖如此，這是一個很多庫都在盡力提高的領域，你可能需要知道他們是否會繼續提高在物理裝置上的效能。只需要看看 Preact 所做的超級棒的 真實世界裝置的效能。
開源 React 漸進式 Web App 示例
如果你想要看更復雜的使用 React 開發，並使用 Lighthouse 優化的 PWAs 例子，你可能會感興趣於： ReactHN— 一個使用服務端渲染並支援離線的 HackerNews 客戶端 或者 iFixit — 一個使用 React 開發，但使用了 Redux 進行狀態管理的硬體修復指南 app。
現在讓我們梳理一遍在 Lighthouse 報告中需要清點的每一項，並在系列中繼續 React.js 專用的小貼士。
網路連線是安全的
HTTPS 的工具和建議
HTTPS 防止壞人篡改你的 app 和你的使用者使用的瀏覽器之間的通訊，你可能讀過 Google 正在推動 羞辱 那些沒有加密的網站。強大的新型 web 平臺 APIs，像 Service Worker，require 通過 HTTPS 保護來源，但是好訊息是像是 LetsEncrypt 這樣的服務商提供了免費的 SSL 證照，便宜的選擇像是 Cloudflare 可以使端到端流量 完全 加密，從來沒有如此簡單直接地能做到現在這樣。
作為我的個人專案，我通常會部署到 Google App Engine，它支援通過 appspot.com 域名的 SSL 通訊服務，只需要你加上 ‘secure’ 引數到你的 app.yaml 檔案。對於需要 Node.js 支援 Universal 渲染的 React apps，我使用 Node on App Engine。Github Pages 和 Zeit.co 現在也支援 HTTPS。
這個 Chrome DevTools Security 皮膚 允許你印證安全證照和混合內容錯誤的問題。
一些更多的小貼士可以使你的網站更加安全：
- 根據需要重定向使用者，升級非安全請求（“HTTP” 連線）到 “HTTPS”。可以一看 內容安全策略 和 升級非安全請求。
- 更新所有引用 “http://” 的連結到 “https://”。如果你依賴第三方的指令碼或者內容，跟他們商量一下讓他們也支援一下 HTTPS 資源。
- 提供頁面的時候，使用 HTTP 嚴格傳輸安全 (HSTS) 頭。這是一個強制瀏覽器只通過 HTTPS 和你的網站交流的指令。
我建議去看看 Deploying HTTPS: The Green Lock and Beyond 和 Mythbusting HTTPS: Squashing security’s urban legends 來了解更多。
使用者會被提醒將 app 新增到 Homescreen
下一個要講的是自定義你的 app 的 “新增到主螢幕” 體驗（favicons，顯示的應用名字，方向和更多）。這是通過新增一個 Web 應用 manifest 來做的。我經常會找定製的跨瀏覽器（以及系統）的圖示來完成這部分工作，但是像是 realfavicongenerator.net 這樣的工具能解決不少麻煩的事情。
有很多關於一個網站只需要在大部分場合能工作的 “最少” favicons 的討論。Lighthouse 提議 提供一個 192px 的圖示給主螢幕，一個 512px 的圖示給你的閃屏。我個人堅持從 realfavicongenerator 得到的輸出，除了它包含更多的 metatags, 我也更傾向於它能涵蓋我的所有基數。
一些網站可能更傾向於為每個平臺提供高度定製化的 favicon。我推薦去看看 設計一個漸進式 Web App 圖示 以獲得更多關於這個主題的指導。
通過 Web App manifest 安裝，你還能獲得 app 安裝器橫幅，讓你有方法可以原生地提示使用者來安裝你的 PWA，如果他們覺得會經常使用它的話。還可以 延遲 提示，直到使用者和你的 app 進行了有意義的互動。Flipkart 找到 最佳時間來顯示這個提示是在他們的訂單確認頁。
Chrome DevTools Application 皮膚 支援通過 Application > Manifest 來檢視你的 Web App manifest：
它會解析出列在你的 manifest 清單檔案的 favicons（網站頭像），還能預覽像是 start URL 和 theme colors 這樣的屬性。順帶一提，如果感興趣的話，這裡有一個完整的關於 Web App Manfests 的工具小貼士 片段 ?
安裝了的 web app 啟動時會帶自定義的閃屏畫面
在舊版本的 Android Chrome 上，點選主螢幕上的 app 圖示通常會花費 200 毫秒（一些慢的網站甚至要數秒）以到達文件的第一幀被渲染到螢幕上。
在這段時間內，使用者會看到一個白屏，減少對你網站的感知到的效能。Chrome 47 和以上版本 支援自定義閃屏（基於來自 Web App manifest 的背景顏色，名字和圖示）會在瀏覽器準備繪製一些東西前給螢幕一些顏色。這使得你的 webapp 感受上更接近 “原生”。
Realfavicongenerator.net 現在還支援根據你的清單（manifest）預覽並自定義閃屏，很方便地節約時間。
注意：Firefox for Android 和 Opera for Android 也支援 Web 應用程式清單，閃屏和新增到主螢幕的體驗。在 iOS 上，Safari 也支援自定義新增到 主螢幕的圖示 並曾經支援一個 專有的閃屏 實現，然而這個在 iOS9 上顯得不能用了。我已經填了一個特性請求給 Webkit，以支援 Web App manifest，所以...希望一切順利吧。
設計是移動友好的
為多種裝置所優化的 Apps 必須在他們的 document 裡面包括一個 meta-viewport。這看上去非常明顯，但是我看到過很多的 React 專案中，人們忘了加上這個。好在 create-react-app 有預設加上有效的 meta-viewport，而且如果缺失的話 Lighthouse 會標記上：
儘管我們非常重視漸進式 Web 應用程式在移動 web 的體驗，這 並不意味著桌面應該被忘記。一個精心設計的 PWA 應該可以在各種 viewport 尺寸、瀏覽器以及裝置上良好運作，正如 Housing.com 所展示的：
在系列第 2 部分，我們將會看看那 使用 React 和 Webpack 的頁面載入效能。我們會深入 code-splitting（程式碼分割），基於路由的 chunking（分塊）以及 達到更快互動性 PRPL 模式。
如果你不熟悉 React，我發現 Wes Bos 寫的 給新手的 React 很棒。
感謝 Gray Norton, Sean Larkin, Sunil Pai, Max Stoiber, Simon Boudrias, Kyle Mathews 和 Owen Campbell-Moore 的校對