2012-10-28 106 views
12

我正在一個大型網站上工作,我們正在將很多功能移到客戶端(Require.js,Backbone和Handlebars堆棧)。甚至有關於將所有渲染移動到客戶端的討論。爲什麼服務器端HTML渲染比客戶端更快?

但是閱讀一些文章,特別是關於Twitter從客戶端渲染移開的文章,其中提到服務器端更快/更可靠,我開始有問題。我不明白如何從JSON渲染JS中相當簡單的HTML小部件,而模板是具有4-8 GB RAM的雙核CPU上的當代瀏覽器比在服務器端應用程序中製作幾十個包含任何內容的速度慢。有沒有關於此的真實生活基準數字?

此外,它似乎像服務器端模板引擎解析HTML模板不能比從Handlebars模板呈現相同的HTML代碼更快,特別是如果這是一個precomp JS功能?

+0

我猜想,DOM操作比字符串操作更慢。你能鏈接到一些這些文章? – Blender

+0

這一個特別http://code-inside.de/blog-in/2012/07/06/client-side-vs-server-side-html-rendering/ –

回答

8

原因是多方面的:

  1. JavaScript是解釋型語言,比服務器端 (通常是在編譯語言完成)
  2. DOM操作是慢的慢,如果你是在JS它操縱它 導致性能不佳。有很多方法可以解決這個問題,比如 在文本中準備渲染,然後評估它,這實際上可能會讓您儘可能接近服務器端渲染。
  3. 一些瀏覽器只是過於緩慢,尤其是老IE
+0

我不會真的擔心舊的IE瀏覽器。我們不支持IE8下的IE。而且我不會擔心少數使用較慢機器和連接的用戶。我很好奇在同一臺機器上,性能相同的瀏覽器,只有一個加載HTML,另一個加載JSON並在客戶端呈現。我想我只需要設置一些測試。 –

+1

取決於你在做多少DOM操作以及你在做多少JavaScript。例如,如果要插入一千個DOM元素,則您的腳本可能需要很多秒才能渲染,而同一個千位DOM元素評估一次(服務器渲染或文本)需要幾毫秒。這些數字向您顯示差異,但實際數量取決於您的頁面,機器功率和瀏覽器。 – albattran

3
  • 編譯語言與解釋的JavaScript
  • 緩存的性能,即 - 服務了其他用戶已經要求完全一樣的頁面,這將刪除需要每個客戶端來渲染它。非常適合流量巨大的網站 - 例如新聞網站。微型緩存甚至可以提供接近實時的更新,但仍可緩存來自緩存的重要流量。無需等待客戶端上使用舊電腦或慢/致殘的瀏覽器
  • 用戶呈現
  • 依賴較少只需要擔心的渲染,對瀏覽器有什麼不同管理的依賴DOM(可靠性)

但對於複雜的用戶界面,交互的客戶端呈現將提供更快捷的用戶體驗。

這實際上取決於您試圖優化的性能以及多少用戶。

+0

該網站相當大(不知道用戶的重複數量,但它託管在60多臺服務器上)。大部分內容都是個性化的。這是一個大型的協作和項目管理應用程序。 –

+0

鑑於協作和項目管理,我會盡可能在客戶端上渲染腳本。交互性需要一個敏捷的反應,所以你無論如何都需要js。 –

0

要在客戶端運行代碼,首先必須加載代碼。服務器端代碼只在服務器啓動時加載,而客戶端代碼必須在每次頁面加載時潛在加載。在任何情況下,即使文件已被緩存,加載頁面時也必須解釋代碼。你也可以在瀏覽器中緩存JS解析樹,但我認爲這些樹不會持久化,所以它們不會長壽。

這意味着無論JavaScript有多快(而且速度非常快),用戶必須等待才能執行工作。許多研究表明,頁面加載時間極大地影響用戶對網站質量和相關性的感知。

底線是,您最多有500ms的時間,可以讓您的頁面在典型的開發人員環境中從乾淨的緩存中呈現。較慢的設備和網絡將使這種滯後僅僅是大多數用戶所不能接受的。

因此,在頁面加載過程中,您可能需要50-100毫秒的時間來處理JavaScript中的所有內容,所有這些都是總計,這意味着呈現複雜的頁面並不容易。

相關問題