[譯] 用 Workers 讓靜態網站動態化

• 原文地址：Using Workers To Make Static Sites Dynamic
• 原文做者：Guest Author
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：MeFelixWang
• 校對者：Park-ma

如下是 Gambling.com 集團首席開發人員 Paddy Sherry 的客座文章。他們使用 Cloudflare 爲全球受衆提供服務，構建績效營銷網站和工具。Paddy 是一位網站性能狂熱愛好者，且對無服務器計算很感興趣。

選擇在大型站點網絡上使用的技術是必須正確的關鍵架構決策。咱們構建靜態網站，但須要找到一種方法讓它們動態地執行地理定位、訪問限制和 A/B 測試等操做。這篇文章分享了咱們在使用 Workers 解決這些挑戰時學到的經驗。

咱們的背景

在 Gambling.com 集團，咱們在全部網站上都使用 Cloudflare，所以咱們對 Workers 的好奇心水平高於大多數人。咱們是靜態網站的忠實粉絲，由於沒有什麼比純 HTML 更快。咱們一直在尋找這樣的技術並應用於部分測試計劃，所以是最早得到該功能的人之一。

咱們如此熱衷於試驗 Workers 的緣由是，對於任何運行靜態站點的人來講，99％ 的時間均可以知足產品要求，但總有一次須要進行一些計算而不是發回靜態響應。

直到最近，最合適的選擇是添加一些在頁面加載後觸發的 JavaScript，並改變 UI 或從端點獲取數據。這樣作的缺點是用戶在加載後會看到頁面移位，即便腳本是異步加載的。閃爍的頁面可能使人憤怒，沒有什麼比嘗試點擊連接但打開了別的東西更使人惱火，由於 DOM 在中途改變了。

一個常見的解決方法是隱藏頁面內容，直到全部 JavaScript 都已處理完畢，但這會讓你停留在一個緩慢加載的腳本，並且用戶在瀏覽器完成下載以前會看到一個空白頁。即便全部腳本都迅速下載，也會有網速較慢或遠離數據中心的用戶能夠響應他們的請求。

輸入 Cloudflare Workers。開發人員能夠處理這些請求，並在它們到達服務器以前動態響應。沒有延遲加載計算，Workers 在後臺響應很是快，過渡基本不可見。

咱們的 Workers 用例

自使用 Workers 以來，咱們一直在嘗試各類方法，在不改變咱們爲網站網絡提供的全部智能技術的前提下使咱們的靜態網站更加動態化。

地理定位

咱們以多種語言在全球運營靜態網站，並使用 Cloudflare 爲其提供服務。用戶經過谷歌搜索或點擊互聯網上其餘地方的連接到達網站。一般，他們登錄的網站可能和興趣不徹底匹配，由於他們點擊的連接並未指向最佳位置。例如，加拿大的用戶登錄英國網站，看到英鎊而不是加拿大元的價格，或者意大利的一我的登錄美國網站看到的是英文內容而不是意大利文。

靜態網站的難題在於頁面加載速度異常快，一旦到達站點，咱們就沒法根據用戶的偏好定製體驗了。

有了 Workers，咱們能夠經過讀取邊緣的請求報頭來解決這個問題。Cloudflare 檢測傳入請求的原始 IP，並將兩個字母的國家代碼附加到名爲 「Cf-Ipcountry」 的報頭中。咱們能夠編寫一個簡單的 worker 來讀取此報頭，檢查國家代碼，而後重定向到相應的站點版本（若是存在的話）。

addEventListener('fetch', event => {
 event.respondWith(fetchAndApply(event.request))
})

async function fetchAndApply(request) {

   const country = request.headers.get('Cf-Ipcountry').toLowerCase() 
   let url = new URL(request.url)

   const target_url = 'https://' + url.hostname + '/' + country
   const target_url_response = await fetch(target_url)

   if(target_url_response.status === 200) {
       return new Response('', {
         status: 302,
         headers: {
           'Location': target_url
         }
       })     
   } else {
       return response
   }
}
複製代碼

用戶如今正在獲取該網站的本地化版本，這能更好地爲他們的興趣服務，而且跳出率更低，由於內容是根據他們的位置定製的。

限制對內容的訪問

對於大多數網站，有時頁面須要在線但不向公衆開放。例如，代理商在最終獲准以前向客戶展現的新登錄頁。

在某些狀況下，公司可能須要多層安全措施來保護其知識產權並避免在準備就緒以前讓用戶看到某些內容，但對於大多數狀況而言，只須要隱藏信息並不須要軍事級別的安全性。

使用內容管理系統，這很容易作到，但靜態站點很難實現。使用 Workers，咱們可以拼湊一個簡單的解決方案阻止訪問頁面，除非請求中存在某個也能夠用於查找參數的報頭。

addEventListener('fetch', event => {
  event.respondWith(fetchAndApply(event.request))
})

async function fetchAndApply(request) {  
  var ua = request.headers.get('user-agent');
    let url = new URL(request.url);

    if (ua.indexOf('MY-TEST-STRING')) {
        return fetch(request)
    } else {
        return new Response('Access Denied',
            { status: 403, statusText: 'Forbidden' })
    }
}
複製代碼

如今能夠向公衆隱藏頁面，而無需對安全性或身份驗證技術進行大量投入，但對於須要進行這些限制的人來講仍然很容易訪問。

A/B 測試

優化流量的重要工具須要從 A/B 測試中領悟。雖然不缺少功能強大的 A/B 測試工具，但大多數都須要添加一個在頁面加載後改變 UI 的 JavaScript。在最佳條件下，這多是肉眼沒法察覺的，但並不是全部用戶都具備最佳的網速，而且有些用戶在頁面加載後會經歷閃爍。如上所述，這是一種帶有負面後果的糟糕經歷。

咱們可以經過調用 A/B 測試腳本 URL 的 Worker 來解決這個問題，在將更改後的響應發送給用戶以前獲取代碼並從新繪製 UI。結果是用戶在頁面加載時看到變體，而且在第一個像素渲染後不會有任何移動。

爲何 Workers 爲咱們消除了障礙

Workers 容許咱們讓靜態網站變得動態化。固然，咱們能夠經過延遲加載 JavaScript 完成此操做，但用戶的體驗會不好。

第二種選擇是遷移到服務器渲染的站點，但即便有這樣的架構轉換，也很難在全球擁有足夠的服務器來爲全部位置的用戶提供相同的體驗。進行這樣的改變也是一項重大的 IT 投資。

另外一方面，Workers 能夠插入到咱們的架構頂部，無需安裝或添加。這是一個單擊 Cloudflare 儀表板中的按鈕並當即訪問 Worker 樂園的問題。在探究任何新技術或供應商時所形成的臭名昭著的時間浪費並無發生在商定試驗或創建開發環境時。

爲何咱們選擇 AWS Lambda 上的 Workers

值得注意的是，Workers 不是無服務器計算的惟一選擇，由於這是行業廣泛的發展方向。雖然 AWS Lambda 是一個強有力的競爭者，但咱們選擇了 Workers，由於 Lambda 須要與更多 AWS 服務集成才能啓動，而最近的性能測試代表 Workers 比 Lambda 更快。

雖然咱們可能由於不一樣需求選擇了 AWS，但 Workers 仍然更容易啓動，且運行迅速。

咱們但願看到的改進

儘管咱們得到了壓倒性的批准，但咱們仍是但願看到一些額外的東西。

除非你有企業計劃，不然帳戶當前能夠訪問單個 Worker 腳本。這意味着許多不相關的代碼存放在一個文件中，雖然這自己並不罕見，可是 Worker 只能觸發單個 URL 模式。若是想要只在一些頁面上觸發功能，這可能會有限制，而且意味着你的 Worker 代碼中會有一系列 if 語句，用於肯定什麼時候觸發它。這不是不可行的，但也不是理想的場景。

隨着 Worker Recipe 交換的增加，以及 Cloudflare 繼續構建出更多內容，咱們期待文檔隨着更多真實世界的示例而增加。

結論

咱們剛剛開始與 Cloudflare Workers 合做。隨着團隊知識的增加，咱們能夠在適當的時候使用它來知足咱們的產品要求，而且在沒有延遲加載 JavaScript 的狀況下執行之前不可能的更高級的事情。Workers 仍處於起步階段，還能夠作出改進。咱們將密切關注這些並嘗試在新功能發佈時找到使用它們的方法。

本指南是一個高級概述。有關更深刻的解釋和代碼片斷，請查看 Cloudflare Workers 的這篇評論，其中詳細解釋了一些示例。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。