電商網站遷移到一個新的設計、平臺或領域意味著你必須非常嚴謹地執行該操作，否則你的SEO就會受到影響，從而降低流量、轉化率和收入。如果在沒有任何操作策略下執行該工作，甚至會使網站受到攻擊。在電子商務網站遷移之前做好準備是確保其持續成功的關鍵，雖然在遷移站點時SEO通常會出現下降，但如果啟動之前修復錯誤實際上可以幫助你保持穩定的流量。

為此，本文將分享五個網站階段遷移檢查步驟，以盡量減少網站遷移所帶來的任何潛在的SEO負面影響。

為什么遷移？

·網站設計過時

·你的業務更改了服務提供，因此需要添加新信息或更改現有信息以使業務更具有時效性。

·重新命名（當業務名稱更改時，這可能涉及遷移到一個新域）。

·CMS（內部管理系統）平臺存在一些問題，你想要切換到一個具有更多或不同的強大功能或成本更低的平臺。

·網站沒有轉換，你希望從頭開始創建一個新域

接下來將深入討論成功遷移的具體細節，從涉及的風險開始。

不同遷移的類型具有不同的風險

低SEO風險：網站重新設計

當遷移范圍僅限于簡單地更改網站的設計時，風險相對較低。原因很簡單，因為URL并沒有更改，因此你也沒有必要從外部代理機構來尋求幫助以保護SEO不受影響。

中等SEO風險：URL /更改（平臺未更改）

當域發生更改時或者需要具有豐富重定向的新URL結構的更改時，你就需要進行仔細地監視。因為任何URL更改都會給你的SEO帶來風險，因此網站的新URL需要被索引，這一目標是通過使URL易于抓取，從而使它們在發布后被谷歌快速索引。無論實際的設計是否發生了變化，新的URL路徑都是網站SEO的基本改變，應該加以監控。

中等SEO風險：電商平臺的變化

通常，平臺更改意味著站點的URL也會更改。這是因為各種電子商務平臺的url結構不同。例如作為指向Shopify“collections”中的產品的路徑，URL結構必須是domain.com/products/productname或domain.com/collections/collectionname/products/productname

與此同時，WordPress和其他CMS（內容管理系統）都有自己的URL結構，且需求不同。這就是為什么在很多情況下，維護原始URL是不可能的的原因。平臺的變化也會帶來核心功能丟失的風險，而這些核心功能正是SEO（或其他營銷渠道）目前所受益的。在遷移平臺時，評估和最小化這樣的風險才是關鍵。

高SEO風險：域遷移

無論URL或設計更改如何，遷移電子商務網站的域都存在很大的風險。問題是，域名在谷歌中遺留了很多的歷史。因此當你從零開始時，必然會有所損失。在這種情況下，就要做更多的工作來減輕SEO的影響和流量損失。

現在你已經了解了其中的風險，以下是遷移網站需要驗證的所有因素的詳細列表。

階段一：評估活動網站和改進的機會，收集基準數據

由于這是一個從一個平臺到另一個平臺的數據遷移過程，所以你將使用舊站點的數據作為基準，以便在稍后的步驟中參考和比較新站點。目標是在將開發站點的功能與活動站點進行比較時，以盡可能少的差異啟動開發網站。

步驟1：使用DeepCrawl或Screaming Frog抓取當前域

Screaming Frog是一種應用廣泛的工具，其數據輸出適合于該過程。

通將DeepCrawl用于較大的站點，而Screaming Frog是作為較小站點的更便宜和更容易的選擇。也就是說，你可以使用你選擇的抓取工具。

抓取當前活動域可以提供網站上的URL列表，以及關于這些URL的各種數據，從而使用這些數據進行檢查和基準測試。

步驟2：執行 Google Search Console（谷歌站長工具）分析

審查網站的谷歌相關數據非常重要。數據在GSC中以儀表板格式顯示，你將考慮：

·導出站點的CSV數據

·是否需要將結構化數據轉移到新網站？

·hreflang標簽需要轉到新站點嗎？

·是否需要在啟動前處理404錯誤？

步驟3：抓取并分析舊網站

現在你已經有了抓取數據和谷歌的數據，你將記錄下以下幾點，以便能夠將它們與新站點進行比較：

·在源代碼中查找Meta robots nofollow標簽

·查找帶有noindex（禁止索引）標記的頁面

·審查規范標簽

·審查標題標簽

·審查元描述標簽

·審查標題（h1, h2等）的用法

· 在一個文件中收集所有已知的實時URL（根據網站抓取、serp抓取、GSC/Google Search Console、GA/Google Analytics等）。

階段二：評估模擬網站和改進的技術機會

接下來你就要進行技術工作，檢查可能的錯誤，并采取必要的步驟來測試和解決它們。

步驟1：檢查服務器更改

要求開發人員在新服務器上托管開發網站以識別潛在的問題，不要忘記要求開發人員使用robots.txt文件阻止搜索引擎機器人訪問開發站點。

步驟2：建立301重定向策略

要獲得新的URL索引，實現重定向的系統方法是至關重要的一步。

·使用網站抓取數據制定301重定向策略；

·記錄如何實現重定向策略，以及由誰負責，每個人都應該在如何構建和實現重定向的問題上保持一致；

·是否存在需要更新的舊版重定向；

此外你還將在啟動或遷移時檢查重定向是否成功。

步驟3：進行技術開發網站優化

進行技術審核是成功的關鍵：

·查看新站點的網站地圖和線框圖；

·確保站點被阻止索引；

·驗證自定義404錯誤頁面是否存在&正確地發出404標題響應。404頁面標題應該始終為“頁面未找到”（或類似的），這樣就可以在Google Analytics中找到錯誤（也就是用戶訪問的錯誤）；

·抓取開發站點；修正404和soft 404；

·確保你不希望在開發網站上編制索引的鏈接是Nofollowed（無法追蹤）的；

·測試重定向；

·使用多個設備瀏覽開發網站；

·計劃更快的索引；創建一個包含所有舊URL的XML站點地圖（如有必要），并計劃在網站啟動后保留它；

·測試和提高網站速度，盡可能多的開發網站。

由于開發網站的速度只是一個估計值，所以你需要讓開發團隊幫助你了解哪些地方還存在不足，以及你可以做些什么來改進它。

步驟4：確定分析遷移策略

·將分析代碼添加到開發站點。（阻止訪問此站點的團隊成員的IP）；

·目標：編制一個URL列表，以便在新站點上線時更新分析目標；

·檢查網站上不同類型網頁的移動設備友好性；

·檢查參數是否按預期運行（并且確保在頁面重新加載或重定向期間，不會從URL中刪除關鍵跟蹤參數）；

·檢查谷歌站長工具中的參數報告是否存在重復內容問題（舊谷歌站長工具的此功能可能不會長時間保留）；

·檢查谷歌分析以確保本網站不能成為其自己的引用頁；

·社交媒體共享：編制社交次數最多的網址列表。保持舊的嵌入代碼以保持社交計數。如果沒有值得重視的頁面，請不要浪費開發工作來實行這一點。

階段三：比較活動站點和測試站點，以達到持平或更好

這個階段的主要步驟如下：

·將舊網站與新網站相比較；

·為將要修復的內容列一個清單，目的是在遷移期間使流量盡可能接近持平。

內容

·網站是否存在重復內容或URL？

·將所有內容遷移到開發站點，盡可能保持不變；

·確保標題標簽和元描述被延續，并且與當前站點相同或更好；

·檢查頁面內容、規范標簽、內部鏈接，H1s/H2s，IMG ALT標簽的使用。

移動站點特定任務

·在Screaming Frog中抓取移動谷歌機器人，驗證頁面之間的移動對等：標題、描述、標題、內容、鏈接、圖像、指令等；

·將meta =“viewport”標簽履行到網站的

部分的。

Javascript站點特定任務

·可視化地審計所有主要頁面類型；

·審核缺少內容的HTML源代碼；

·使用inspect元素檢查缺少的內容；

·比較HTML源代碼和檢查元素是否矛盾；

·根據用戶交互來識別內容。

AMP頁面特定任務

·每個非AMP頁面（即桌面、手機）都應該有一個指向相應AMP URL的標簽；

·每個AMP頁面應該有一個rel= “canonical ”標簽指向相應的桌面頁面；

·任何沒有相應桌面URL的AMP頁面應該有一個自引用的規范標記。

電子商務特定任務

·類別頁面是否包含指向產品的可索引鏈接；

·檢查分面導航、分頁以獲得最佳實踐；

·如果圖片鏈接出現在錨文本鏈接之前，是否使用了關鍵詞豐富的ALT文本。

WordPress特定任務

·使用Simple 301 Redirects Plugin重定向開發站點WordPress中的URL；

·在WordPress站點和CMS（內部管理系統）上安裝Google Tag Manager Plugin （谷歌標簽管理器插件）并進行配置；

·設置Yoast WordPress SEO & Yoast Analytics插件；

·如果你使用像HubSpot這樣的CMS ，安裝并設置CMS插件；

·建立Yoast Analytics。

階段四：啟動檢查以確保一切順利

步驟1：站點抓取/分析檢查

在這個步驟中，你將檢查活動站點和測試站點之間的匹配數據：

1、驗證301重定向都已正確實施；

2、抓取新站點以確定技術問題和可訪問性；；

3、確保新的活動站點沒有被阻止、被抓取和索引

4、驗證是否將“Nofollow”標記添加到不希望索引的頁面。這些應該在開發站點上進行標識，例如在分面導航鏈接上；

5、確保每個頁面上都有“index、follow”元標記；

6、尋找不應該出現的404頁面；

7、檢查內部鏈接：查找斷開的鏈接，以及指向開發站點的鏈接；

8、驗證規范標簽的項目執行；

9、檢查標準和重復URL；

10、檢查標題標簽（與舊數據匹配）；

11、檢查元描述（與舊數據匹配）；

12、檢查H1、H2使用情況（與舊數據匹配）；

13、檢查IMG ALT屬性（與舊數據匹配）；

14、檢查字數（與舊數據匹配，解釋

標簽內的所有模板文本）；

15、按頁面檢查內部鏈接計數（與舊數據匹配，是否有關鍵頁面丟失鏈接）。

步驟2： Google Analytics（谷歌分析） / Search Console Checks（谷歌站長工具）

現在你可以觀察谷歌為新站點注冊了哪些數據：

1、確保其準確性：驗證所有頁面上的分析代碼，以及實施正確的代碼；

2、更新分析目標，檢查它們是否能夠正常工作；

3、使用網站啟動日期對分析進行注釋。

步驟3：網站速度檢查

1、觀察通過站點速度工具運行幾個頁面，將舊站點和開發站點上的站點速度進行相比；

2、如果可以的話，做好改進的記錄。

步驟4：其他任務

1、站點是否更改了服務器？確保沒有與服務器相關的問題；

2、比較頂部登錄頁面，前后（標題、元描述、頁眉、頁面內容等）；

3、驗證404頁面是否返回404狀態；

4、驗證舊的XML站點地圖是否在新站點上，重新提交到Google Search Console （谷歌站長工具）和 Bing Webmaster Tools（必應網站管理員工具）；

5、如果域正在更改，請在GSC中聲明新的域變體并提交地址更改請求。

階段五：1-2個月以上的網站監測

1、發布后一周

·監控GSC谷歌站長工具（抓取統計數據、排名、流量、索引頁面等）；

·檢查GSC是否有新的索引頁面（并檢查任何沒有索引的頁面）；

·檢查舊的GSC配置文件，以確保舊頁面被取消索引；

·保留舊的XML站點地圖，讓谷歌重新抓取。

2、發布后2 - 3周內

·監控谷歌站長工具（抓取統計數據、排名、流量、索引頁面等）；

·刪除舊的XML站點地圖，用新的XML站點地圖替換它們；

·檢查sitemap.xml文件，是否有正確的url（無多余的URL、沒有Dev URL等）；

·提交新的XML站點地圖到谷歌站長工具&必應網站管理員工具。

3、發布后一個月

·監控谷歌站長工具（抓取統計數據、排名、流量、索引頁面等）；

·檢查流量損失分析，觀察哪些頁面丟失了流量以及原因。

4、發布后2個月

·繼續監控谷歌站長工具（抓取統計數據、排名、流量、索引頁面等）；

·大多數遷移通常會在啟動后出現流量的下降和上升。也就是說，每個地點和遷移都是不同的，所以實際的影響很難預測；

· 較好的辦法就是遵循這個過程。這樣做可以確保新站點的數據仍然被谷歌索引，從而對潛在客戶可見。

（編譯/雨果網 宋淑湲）

【特別聲明】未經許可同意，任何個人或組織不得復制、轉載、或以其他方式使用本網站內容。轉載請聯系：editor@cifnews.com

eta 版的 Execute Program 是用 Ruby 和 JavaScript 編寫的。之后，我們分幾步將整個應用完全移植到了 TypeScript 上。本文介紹的是移植的第一步，也就是前端的部分。

在 Execute Program 的原始 JavaScript 前端中，我經常會犯一些小錯誤。例如，我會將錯誤的 prop 名稱傳遞給 React 組件，或者遺漏某個 prop，抑或傳遞錯誤的數據類型。（Prop 是作為參數發送到 React 組件的數據。組件將一些 props 傳遞給自己的某個子組件，以此類推，這是很常見的。）

對于像 JavaScript 和 Ruby 這樣的動態語言來說，這不是個小問題。過去 15 年來我一直在學習該如何應對這種錯誤問題。我在之前談論的是 2011 年代的情況，其中討論的緩解措施確實有些用途，但它們無法隨著系統的發展順利地擴展下去，而且我們忘掉它們時也沒有安全網可用。

我覺得 15 年時間已經夠長了。我想回到靜態類型系統的懷抱，畢竟這種系統中根本不會出現這類錯誤。彼時我們有幾個選項：Elm、Reason、Flow、TypeScript 和 PureScript。（這里舉了一部分例子。）最后我決定使用 TypeScript 是因為：

1. TypeScript 是 JavaScript 的超集，因此移植起來很容易。移植回來也更容易些：只需刪除類型定義即可，然后我們又回到了 JavaScript。
2. TypeScript 編譯器使用 TypeScript 編寫，并作為已編譯的 JavaScript 代碼分發，因此我們可以在自己的 Web 應用中運行它。我們的 TypeScript 課程正是這樣做的：在瀏覽器中評估用戶的 TypeScript 代碼，以避免網絡延遲。
3. 這一條是我們的業務特有的：TypeScript 比其他選項更受歡迎。這意味著更多的人希望從像我們這樣的課程中學習 TypeScript。用 TypeScript 編寫 Execute Program，讓我們可以制作出更好的 TypeScript 課程。

在 2018 年 10 月，我們用了大約兩天時間將前端 JavaScript 代碼移植到了 TypeScript。下面的圖表顯示了在移植前和移植后每種語言擁有的代碼量。

當時我們還是 pre-beta 版本，所以系統還很小，只有大約 6,000 行。這張圖上沒有涉及移植后的情況；我們將在以后的文章中具體介紹相關內容。

在這次移植之后，React prop 問題消失了。下面我們會看幾個示例，首先是一個簡單的例子。以下是渲染“Continue”按鈕的代碼，這個按鈕出現在我們課程的每個文本段落之后：

復制代碼

<Button  autofocus={true}  icon="arrowRight"  onClick={continue}  primary>  Continue</Button>

這個 Button 組件的 props 的類型如下所示。當讀取諸如 autofocus?: boolean 之類的屬性類型時：“autofocus”是屬性的名稱；“?”表示它是可選的；“:”將屬性名稱與其類型分開；而“boolean”是類型。最后一個屬性類型 onClick 表示“一個不帶參數且不返回任何內容的函數”。如果你不熟悉 TypeScript 的函數類型語法，可以在我們的課程中全面了解 TypeScript 的函數類型。

復制代碼

type ButtonProps = {  autofocus?: boolean  icon?: IconName  primary?: boolean  onClick: () => void}

如果將“autofocus”prop 從 true 更改為 1，會發生什么？現在，我們在類型系統期望一個布爾值的地方傳遞了一個數字值。不到一秒鐘后，編譯器將在下面顯示錯誤。（這里刪除了一些不相關的細節；本系列文章中所有涉及到錯誤的地方都會這樣處理。）

復制代碼

src/client/components/explanation.tsx(13,27):  error: Type 'number' is not assignable to type 'boolean | undefined'.

有害代碼在 vim 中也變成了紅色。修好它后，紅色消失了。解決錯誤只需要幾秒鐘。在 Ruby 或 JavaScript 中，我可能會花幾分鐘的時間手動測試應用程序，并反復瀏覽它的狀態才能知道到底發生了什么事情。我也可以依靠自動化測試，但是我們在另一篇文章中介紹了測試 vs 類型的問題。

這個整數到布爾的更改是對類型系統的一次簡單而低風險的測試。Button 的 icon 屬性顯示了更高級的用法。下面還是 Button 調用：

復制代碼

<Button  autofocus={true}  icon="arrowRight"  onClick={continue}  primary>  Continue</Button>

看起來 icon prop 只是一個字符串：“arrowRight”。在運行時，在已編譯的 JavaScript 代碼中，它將是一個字符串。但是在上面顯示的 ButtonProps 類型中，我們將其定義為 IconName，后者是在其他地方定義的。在查看其定義之前，讓我們先看看這個類型的作用。假設我們將“icon”prop 更改為“banana”。我們實際上沒有名為“banana”的圖標。

復制代碼

<Button  autofocus={true}  icon="banana"  onClick={continue}  primary>  Continue</Button>

不到一秒鐘后，TypeScript 編譯器拒絕了這一更改：

復制代碼

src/client/components/explanation.tsx(13,44):  error: Type '"banana"' is not assignable to type    '"menu" | "arrowDown" | "arrowLeft" | ... 21 more ... | undefined'.

編譯器說“icon”不能是任意字符串。它必須是我們定義為 icon 名稱的 24 個字符串之一。編譯器將拒絕任何使我們引用不存在圖標的更改；這不是有效的程序，甚至無法開始執行。

有多種方法可以實現 IconName 類型。一種是編寫一種類型，該類型顯式列出所有可能的 icon 名稱。然后，我們必須使 icon 名稱與其在磁盤上的圖像文件保持同步。這種類型可能是這樣的：

復制代碼

type IconName =  "menu" |  "arrowDown" |  "arrowLeft" |  "arrowRight" |  ...

翻譯成中文：“這里會靜態地保證 IconName 類型的一個值是此處指定的字符串之一，但不能是其他任何字符串。”（這個類型是我們兩堂課程涵蓋的兩個主題的組合：字面量類型和類型聯合）

我們的 IconName 未被定義為字面量類型的簡單聯合。讓圖標名稱列表與文件列表保持同步是很無聊的工作，我們可以讓計算機來完成它！相反，我們的 icon.tsx 文件如下所示：

復制代碼

export const icons = {  arrowDown: {    label: "Down Arrow",    data() {      return <path ... />    }  },  arrowLeft: {    label: "Left Arrow",    data() {      return <path ... />    }  },  ...}

實際的 SVG < path/> 標簽就在源代碼中，在以 icon 名稱為鍵的對象中。（也可以在不將 SVG 內聯到源文件中的情況下執行此操作。例如，我們可以使用一些 Webpack 技巧將圖像保存在它們自己的文件中，但仍然可以確保列表中的每個圖標也都存在于磁盤上。到目前為止，這種簡單的解決方案對我們來說是很好用的。）

通過這種方式定義 icon 后，我們可以使用一行代碼自動提取其名稱的聯合類型（union type）：

復制代碼

export type IconName = keyof typeof icons

（這里的意思是，你可以認為該類型表示“每當某物的類型為”IconName”時，它必須是與 icons 對象的鍵之一匹配的字符串。）

這樣就搞定了；并不需要其他類型層面的工作。剩下的代碼只是一個簡單的 Icon React 組件，它在列表中查找圖標并返回其 SVG 路徑。這個函數中沒有明確的 TypeScript 類型。它看起來像是純粹的 JavaScript 代碼，但它也經過了類型檢查。這是一個最小版本，其中刪除了所有無關的細節：

復制代碼

export function Icon(props: {  name: IconName}) {  return <svg>    {icons[props.name].data()}  </svg>}

現在，我們可以將 SVG 標簽放入這個源文件中，并將新 icon 拖放到“icons”列表中。當我們這樣做時，這個 icon 就可以在 Button 組件，以及系統內接受 icon 名稱的其他任何部分中使用。如果我們從列表中刪除一個 icon，則系統中引用該 icon 的所有部分都將立即無法編譯，從而確保沒有過時的 icon 引用在運行時導致錯誤。

這些示例按照靜態類型標準來說是很簡單的，但我認為它們證明了 Web 應用程序中有多少可以輕松實現的改進之處。一個應用程序中的大多數代碼都不涉及高級類型系統功能；多數需求僅僅是“確保我們傳遞正確的 props”和“確保我們的圖標確實存在”之類的簡單事情。

我們在整個系統中都做了這種事情。其他的一些示例：

1. 我們在整個系統中使用了一個 Note 組件。它具有一個 tone prop 來確定提示的樣式：“info”“warning”“error”等。如果我們不再使用其中某個 tone 選項，則我們將從聯合類型中將其刪除，并且所有引用這個 tone 的 Note 將出錯，直到我們更新它們。
2. 我們鏈接到的每個 URL 都將靜態保證存在。當我們重命名或刪除 URL 時，鏈接到它的每個組件都無法編譯，直到我們對其進行更新以匹配為止。
3. 當我們鏈接到這些 URL 時，類型系統可確保我們填充 URL 中的所有空缺。例如，路徑“/courses/:courseId/lessons/:lessonId”具有兩個 hole，“courseId”和“lessonId”。如果我們嘗試鏈接到該路徑，但忘記提供“courseId”，則代碼將無法編譯。
4. 我們在客戶端上發出的每個 API 請求都會被靜態確保與相應服務端 API 端點的負載結構匹配。如果我們在端點中重命名一個屬性，哪怕屬性在嵌套的 API 對象的內部深處，引用該端點屬性的任何代碼也都將無法編譯，直到我們對其更新以匹配為止。我們在另一篇文章中介紹了細節。

諸如此類的問題經常會出現在編程工作中，尤其是在動態語言中非常常見；但我們無需編寫任何自動測試，也用不著什么手動測試，就可以從靜態上避免這些問題。有些問題解決起來需要費些功夫。我們的 API 路由器驗證寫起來很麻煩。但是寫多了就順手了。上面的單行“IconName”類型實際上是問題的完整解決方案。如果將其復制到 TypeScript 文件中，它就能起作用。

將我們的前端代碼移植到 TypeScript 僅僅是個開始。那之后，我們又將后端從 Ruby 移植到了 TypeScript，然后在移植后的 9 個月內對其進行了擴展和維護。

oogle Docs宣布將會把HTML遷移到基于Canvas渲染，這一消息的出現再次把幾年前隨HTML5誕生的標簽重新推到了人們視線之中。Canvas在剛推出時主打的優勢就是更快的渲染速度，堪稱HTML屆的“小飛人”，刷新了人們對Web頁面元素繪制速度的印象。但Canvas的優勢僅限于此嗎？

HTML繪圖屆的前輩：SVG

Canvas是HTML5時代引入的“新”標簽。與很多標簽不同，Canvas不具有自己的行為，只將一組API 展現給客戶端 JavaScript ，讓開發者使用腳本把想繪制的東西畫到一張畫布上。

在HTML5之前，人們通常使用SVG來在頁面上繪制出圖形。SVG使用XML來定義圖形，就像使用HTML標簽和樣式定義DIV一樣，我們也可以將一個空白的DIV想象為長方形的SVG，兩者的設計思想是相通的，SVG的本質就是一個DOM元素。而Canvas則不同，Canvas提供的是 JavaScript 的繪圖 API，而不是像 SVG那樣使用XML 描述繪圖，通過JavaScript API直接完成繪制，比起修改XML來說要更簡便、更直接。

除了定義的方式不同，Canvas和DOM（當然也包含SVG）的差異更多的體現在瀏覽器的渲染方式上。

瀏覽器在做頁面渲染時，Dom元素是作為矢量圖進行渲染的。每一個元素的邊距都需要單獨處理，瀏覽器需要將它們全都處理成像素才能輸出到屏幕上，計算量十分龐大。當頁面上內容非常多，存在大量DOM元素的時候，這些內容的渲染速度就會變得很慢。

而Canvas與DOM的區別則是Canvas的本質就是一張位圖，類似img標簽，或者一個div加了一張背景圖（background-image）。所以，DOM那種矢量圖在渲染中存在的問題換到Canvas身上就完全不同了。在渲染Canvas時，瀏覽器只需要在JavaScript引擎中執行繪制邏輯，在內存中構建出畫布，然后遍歷整個畫布里所有像素點的顏色，直接輸出到屏幕就可以了。不管Canvas里面的元素有多少個，瀏覽器在渲染階段也僅需要處理一張畫布。

然而這樣更加強大的功能，不可避免的讓使用canvas渲染有很高的門檻。Google Docs在構建Canvas的過程中重新定義了往常已經被人們所熟悉的內容，例如精確定位、文本選擇、拼寫檢查、重畫調優等。為什么更多開發者還是選擇了接納Canvas這個門檻更高的技術路線呢？這就得回到Canvas的最大優勢：渲染性能。

Canvas的渲染模式

這里的渲染是指瀏覽器將頁面的代碼呈現為屏幕上內容的過程。Canvas和Dom的渲染模式完全不同，搞清楚這個差異對理解Canvas的性能優勢至關重要。

Dom：駐留模式

駐留模式（Retained Mode）是Dom在瀏覽器中的渲染模式。下圖粗略展示了這一過程的工作流程。

DOM的核心是標簽，一種文本標記型語言，多樣性很強且多個標簽之間存在各種關聯（如在同一個DIV下設置為float的子DIV）。瀏覽器為了更好的處理這些DOM元素，減少對繪制API的調用，就設計了一套將中間結果存放于內存的“駐留模式”。首先，瀏覽器會將解析DOM相關的全部內容（包含HTML標簽、樣式和JavaScript），將其轉化為場景（scene）和模型（model）存儲到內存中，然后再調用系統的繪制API（如Windows程序員熟悉的GDI/GDI+），把這些中間產物繪制到屏幕。

駐留模式通過場景和模型緩存減少了對繪制API的調用頻次，將性能壓力轉移到場景和模型生成階段，即瀏覽器需要根據DOM上下文和BOM中的尺寸數據，“自行判斷”每一個元素的繪制結果。

Canvas：快速模式

Canvas采用了和DOM不同的快速模式（Immediate Mode），讓我們先來看看快速模式是如工作的：

與駐留模式相比，快速模式將場景和模型的生成從瀏覽器移交給了開發者。開發者在設計頁面時，就通過Canvas的JavaScript API定義了畫布內所有元素的繪制方式。瀏覽器只需要簡單的執行這些腳本即可，而不需要像渲染DOM一樣逐個處理子元素了。

在快速模式中，頁面的繪制性能得到了大幅提升。但開發者不僅需要指定什么需要畫，還要創建和維護一個模型。此外，開發者還需要管理好當前場景重繪時帶來的改變，以及響應用戶的點擊或輸入操作等。

Canvas的應用優點

上面介紹的兩種不同的模式直接造成了Dom和Canvas的性能差異。對于使用快速模式渲染的Canvas而言，瀏覽器的每次重繪都是基于代碼的，不存在能讓處理流程變慢的多層解析，所以它真的很快。除了快之外，Canvas的靈活性也大大超出DOM。我們可以通過代碼精確的控制如何、何時繪制出我們想要的效果。

在資源消耗上，DOM的駐留模式意味著場景中每增加一點東西就需要額外消耗一些內存，而Canvas并沒有這個問題。這個差異會隨著頁面元素的數量增多而愈加明顯。以B端的企業應用場景為例，表單那種數據量比較小的場景，不同渲染模式帶來的效果差異并不明顯；但在工業制造、金融財會等類Excel電子表格操作的場景下，單元格數量動輒便是上百萬（5萬行x 20列）甚至上億個，瀏覽器需要對表格所有單元格本身內容進行渲染，同時還涉及到豐富的數據處理，情況就完全不同了。

在Canvas出現之前，在前端渲染表格時只能通過構建復雜的DOM來實現。這種方式下，瀏覽器的性能成為了Web應用瓶頸，讓很多開發者放棄了在瀏覽器上實現電子表格的想法。

在Canvas出現后，快速模式帶來的性能優勢無疑是一個巨大的亮點，大量、復雜的DOM渲染處理帶來的性能問題終于有了解決途徑。

回到電子表格的應用場景，業內已經出現了使用Canvas繪制畫布的表格組件，這類組件在渲染數據層時不僅無需重復創建和銷毀DOM元素，在畫布的繪制過程中，也比Dom元素渲染的限制更少。除了表格之外，Canvas也為數字孿生可視化大屏、頁面游戲等場景帶來了變革。

總結

總結一下，在渲染模式上，Canvas站在了DOM的對面，瀏覽器對其內容一無所知，一切渲染的權利回到了開發者的手上，這個改變帶來了顯著的性能優勢。此外，我們可以使用Canvas繪制種類更為豐富的UI元素，如線形、特殊圖形等，通過畫法邏輯，還可以實現更加精準的UI界面渲染，解決了瀏覽器差異造成的樣式誤差，讓更多應用場景可以順利遷移到Web平臺上來。