毫無疑問，用戶體驗會受到感知加載時間的影響。隨著今天更重的前端發展，客戶端渲染感覺不是很快。針對這樣的情況，預渲染可能是一種非常好的策略，這些解決方案與完全由客戶端呈現的應用程序之間有什么區別？想學習前端的同學可以參加Web前端培訓，有系統全面的課程，還有經驗豐富的專業講師指導教學，可以快速掌握前端知識和技能，節省很多學習時間，少走彎路。

　　客戶端渲染的應用程序

　　由于 Angular、Ember.js 和 Backbone 等框架的存在，前端開發人員傾向于在客戶端渲染所有內容。

　　使用客戶端渲染解決方案，你將請求重定向到單個 HTML 文件，服務器將在沒有任何內容(或帶有加載屏幕)的情況下傳遞它，直到你獲取所有 JavaScript 并讓瀏覽器在渲染內容之前編譯所有內容。在良好且可靠的互聯網連接下，它非常快且運行良好。但它可以好得多，而且做到這一點并不難。這就是我們將在以下部分中看到的內容。

　　服務器端渲染 (SSR)

　　SSR 解決方案是我們很多年前經常做的事情，但往往會忘記支持客戶端渲染解決方案。

　　使用舊的服務器端渲染解決方案，你構建了一個網頁(例如使用 PHP)，服務器編譯所有內容，包含數據，并將完全填充的 HTML 頁面交付給客戶端。它快速而有效。但是……每次你導航到另一條路線時，服務器都必須重新做一遍：獲取 PHP 文件，編譯它，然后交付 HTML，所有的 CSS 和 JS 將頁面加載延遲到幾百毫秒或甚至整秒。

　　如果你可以使用 SSR 解決方案進行第一個頁面加載，然后使用框架通過 AJAX 進行動態路由，只獲取必要的數據會怎樣?如果想要盡快學到前端入門的的知識，建議去Web前端培訓學習，有大神老師帶你，學起來又輕松又有效。

　　這就是 SSR 在社區中越來越受到關注的原因，因為 React 通過一個易于使用的解決方案普及了這個問題：RenderToString 方法。

　　這種新型 Web 應用程序稱為通用應用程序或同構應用程序。關于這些術語的確切含義以及它們之間的關系仍然存在一些爭議，但許多人可以互換使用它們。

　　無論如何，該解決方案的優勢在于能夠使用相同的代碼開發應用程序服務器端和客戶端，并使用自定義數據為用戶提供真正快速的體驗。缺點是需要運行服務器。

　　SSR 用于獲取數據并使用自定義內容預填充頁面，利用服務器的可靠互聯網連接。也就是說，服務器自己的互聯網連接比使用 lie-fi 的用戶更好)，因此它能夠在將數據交付給用戶之前預取和合并數據。

　　使用預先填充的數據，使用 SSR 應用程序還可以解決客戶端呈現的應用程序在社交共享和 OpenGraph 系統中存在的問題。例如，如果你只有一個 index.html 文件要交付給客戶端，那么他們將只有一種類型的元數據——很可能是你的主頁元數據。當你想要分享不同的路線時，這不會被上下文化，因此你的任何路線都不會顯示在其他網站上，并帶有用戶希望與全世界分享的正確用戶內容(描述和預覽圖片)。在Web前端培訓中，不僅有理論知識的課程，也會有實操項目的訓練，讓你深入淺出地學習前端技術，彌補項目經驗的空缺。

　　預渲染

　　通用應用程序的強制性服務器對某些人來說可能是一種威懾，而對于小型應用程序來說可能是過度的。這就是為什么預渲染可以是一個非常好的選擇。

　　我通過 Preact 和它自己的 CLI 發現了這個解決方案，它允許你編譯所有預先選擇的路由，以便你可以將完全填充的 HTML 文件存儲到靜態服務器。借助 Preact/React 補水功能，你可以為用戶提供超快速體驗，而無需使用 Node.js。

　　問題是，因為這不是 SSR，所以此時你沒有用戶特定的數據要顯示——它只是一個靜態(有點通用)文件，直接在第一個請求上發送，原樣。因此，如果你有特定于用戶的數據，你可以在此處集成一個設計精美的骨架，向用戶展示他們的數據即將到來，以避免他們感到沮喪。

　　還有一個問題：為了使這項技術起作用，你仍然需要使用代理或其他東西來將用戶重定向到正確的文件。

　　客戶端呈現的應用程序是我們現在應該避免的，因為我們可以為用戶做得更好。在這種情況下，做得更好就像預渲染解決方案一樣簡單。這絕對是對僅客戶端渲染的改進，并且比完全服務器端渲染的應用程序更容易實現。想學習更多渲染技巧，不妨考慮參加Web前端培訓，可以在短時間獲得快速提升，有效提高前端開發工作效率。