摘要:然而這些代碼也會競爭系統(tǒng)的處理能力,因此在頁面內(nèi)容被渲染完成之前,必須要經(jīng)常處理一些東西。注意事項當(dāng)在網(wǎng)站上選擇渲染策略時,團(tuán)隊通常會考慮的影響。它顯示了抓取工具顯示任何頁面的方式預(yù)覽,找到的序列化內(nèi)容執(zhí)行后以及渲染過程中遇到的任何錯誤。
客戶端渲染(CSR)
客戶端渲染意味著在瀏覽器中使用Javascript直接渲染頁面。所有的邏輯,數(shù)據(jù)獲取,模板和路由都在客戶端處理。
對于移動設(shè)備來說,客戶端渲染很難得到或者保持一種快速的訪問水平。如果它做最少的工作,保持嚴(yán)格的Javascript預(yù)算,并盡可能減少數(shù)據(jù)請求往返的時間,那么它可以接近純服務(wù)器端渲染的性能。使用HTTP/2推送或者是可以使得關(guān)鍵腳本和數(shù)據(jù)得以更快的傳遞,從而使得解析器更快的為你工作。為了確保初始化和隨后的導(dǎo)航感覺立刻就能完成,像PRPL這樣的模式就比較值得去做。
客戶端渲染主要的缺點就是Javascript的數(shù)量會隨著應(yīng)用程序的增長而變得越來越多。當(dāng)有額外的新Javascript類庫,polyfills和第三方代碼的時候,優(yōu)化工作會尤其困難。然而這些代碼也會競爭系統(tǒng)的處理能力,因此在頁面內(nèi)容被渲染完成之前,必須要經(jīng)常處理一些東西。
對于構(gòu)建單頁應(yīng)用的人員來說,對于被大多數(shù)頁面共享的核心用戶接口,你可以嘗試應(yīng)用Application Shell緩存技術(shù)。并與service workers相結(jié)合,它可以明顯提高重復(fù)訪問的時候的感知性能。
通過rehydration合并服務(wù)器端渲染和客戶端渲染這種方式通常被稱為“Universal Rendering”或簡稱為“SSR”,這種方式試圖通過平滑的方式來平衡客戶端渲染和服務(wù)器端渲染。諸如全頁加載或者是重新加載的請求會在服務(wù)器端被處理,在服務(wù)器端會把其轉(zhuǎn)為HTML,然后Javascript和渲染所用到的數(shù)據(jù)會被一起插入到最后的結(jié)果頁面。如果實現(xiàn)的好的話,這種方式會像服務(wù)器端渲染那樣產(chǎn)生一個很快的First Contentful Paint。服務(wù)器端返回結(jié)果以后,會在客戶端會通過一個叫(rehydration)的技術(shù)再次渲染。這是一個比較新的解決方案,但是他可能有比較大的性能缺陷。
rehydration的SSR的主要的缺點就是它對Time To Interactive有著明顯的缺點,即使它會提高First Paint。它經(jīng)??雌饋硎蔷哂衅垓_性的加載和交互,因為它實際上在js以及事件處理完成之前,是無法響應(yīng)輸入的。在手機(jī)端可能會花費數(shù)秒鐘才會讓頁面真正可以使用。
你可能經(jīng)歷過以下問題 - 頁面請求加載一段時間以后,你的網(wǎng)頁看起來已經(jīng)加載好了,但是點擊以后什么都不會做,你可能很快就會變得崩潰...“現(xiàn)在到底發(fā)生什么事情了?為什么我不能滾動頁面”。
一個Rehydration的問題:一個應(yīng)用程序要構(gòu)建兩次由于JS的原因,Rehydration的問題通常要比延遲可用的問題要更糟。為了使客戶端的Javascript能夠精確的“獲取”服務(wù)器停止渲染的位置,而不必重新渲染服務(wù)器已渲染過的HTML,當(dāng)前的SSR解決方案通常會序列化其UI響應(yīng),并把其依賴的數(shù)據(jù)作為標(biāo)簽放進(jìn)文檔中。HTML文檔的結(jié)果包含一個更高級別的重復(fù)。
正如你所看到的,在響應(yīng)中服務(wù)器不僅返回一個應(yīng)用程序UI的描述給瀏覽器,而且還吧相關(guān)的數(shù)據(jù)也一并返回了過來,當(dāng)啟動客戶端的時候,UI會再次實現(xiàn)渲染一次。其只在bundle.js已經(jīng)完成加載和解析以后,UI才會變?yōu)榭山换サ摹?/p>
在真實世界中通過使用SSR來收集性能指標(biāo),其結(jié)果通常會比較令人沮喪。原因歸結(jié)于用戶體驗:它很容易使用戶留在一個“不可思議的山谷中”。
雖然SSR有rehydration的希望。但是是在一個很短的時期內(nèi),在更高的可緩存的內(nèi)容中使用SSR可以減少TTFB延遲。產(chǎn)生一個和預(yù)渲染相似的結(jié)果。遞增的,逐步的,部分的rehydration可能是未來技術(shù)可用性更高的關(guān)鍵(Rehydrating incrementally, progressively, or partially may be the key to making this technique more viable in the future)。
流服務(wù)器渲染和漸進(jìn)式Rehydration服務(wù)器端渲染在過去幾年擁有大量的開發(fā)者。
流服務(wù)器渲染允許你以塊的方式發(fā)送HTML,瀏覽器可以通過接收到的片段進(jìn)行漸進(jìn)式的渲染。由于內(nèi)容可以更快的送達(dá)給用戶,所以他可以帶來更快的First Paint和First Contentful Paint。在React中,流通過renderToNodeStream()被異步傳輸 - 相比于同步渲染方式 - 意味著背壓處理效果會更好。
漸進(jìn)式rehydration也是值得一看的,在一些React已經(jīng)對此有了一些相關(guān)的探索了。通過這種方法,服務(wù)器端渲染的每一個部分內(nèi)容都會隨著時間的推移而啟動,而不是目前通用的方法,通過一次初始化整個應(yīng)用程序。這可以幫助我們減少頁面交互所需要的Javascript的代碼量。因為可以延緩低優(yōu)先級客戶端的內(nèi)容過早的執(zhí)行,以使得防止阻塞主線程的執(zhí)行。它還可以幫助避免最常見的SSR Rehydration陷阱之一,其中服務(wù)器呈現(xiàn)的DOM樹被破壞然后立即重建 - 通常是因為初始同步客戶端渲染所需的數(shù)據(jù)還沒有完全準(zhǔn)備好,可能還在等待Promise 解析的完成。
部分Rehydration部分Rehydration已經(jīng)被證明是難以實現(xiàn)的。這種方法是漸進(jìn)式rehydration的一種擴(kuò)展。其中逐步分析了漸進(jìn)式的rehydration的每一個部分。標(biāo)記了那些交互性很小,或者沒有交互性的那些。對于每個幾乎靜態(tài)的部分,對應(yīng)的Javascript會被轉(zhuǎn)換為惰性引用或者是裝飾函數(shù)中。將其客戶端占用空間減少到接近為零.部分Rehydration也會有自己的問題和妥協(xié)。它為緩存帶來了一些有趣的挑戰(zhàn),而客戶端導(dǎo)航意味著我們無法假設(shè)應(yīng)用程序的惰性部分的服務(wù)器呈現(xiàn)的HTML將在沒有完整頁面加載的情況下可用。
Trisomorphic渲染如果service workers對于你來說是一個選項的話。那么對于“trisomorphic”渲染來說,你可能也是感興趣的。這是一種可以將初始/非JS應(yīng)用在流服務(wù)器上的一種技術(shù),然后讓您的服務(wù)工作者在安裝后渲染為HTML以進(jìn)行導(dǎo)航,這可以使緩存的組件和模板保持最新,并啟用SPA樣式導(dǎo)航以在同一會話中呈現(xiàn)新視圖。當(dāng)您可以在服務(wù)器,客戶端頁面和服務(wù)器工作程序之間共享相同的模板和路由代碼時,此方法最有效。
SEO注意事項當(dāng)在網(wǎng)站上選擇渲染策略時,團(tuán)隊通常會考慮SEO的影響。服務(wù)器端渲染通常被選擇提供一個對于爬蟲“完全可視”的,更容易爬取的網(wǎng)頁。爬蟲可能會理解Javascript,但是他們在渲染中通常有值得注意的限制??蛻舳虽秩究梢怨ぷ鳎峭ǔ]有額外的測試工作。最近的動態(tài)渲染逐漸成為一個值得考慮的選項,如果你的架構(gòu)很大部分都是由客戶端Javascript驅(qū)動的話。
如果有疑問,移動友好測試工具對于測試您選擇的方法是否符合您的預(yù)期非常寶貴。 它顯示了Google抓取工具顯示任何頁面的方式預(yù)覽,找到的序列化HTML內(nèi)容(執(zhí)行JavaScript后)以及渲染過程中遇到的任何錯誤。
總結(jié)當(dāng)決定渲染的方法的時候,首先要測量并且理解你的瓶頸是什么。思考靜態(tài)渲染或者是服務(wù)器端渲染是否可以滿足你90%的需求。用最少的JS發(fā)布HTML也是極好的,其會得到一個可交互的用戶體驗。下面是一個方便的信息圖,顯示了服務(wù)器-客戶端頻譜。
本文翻譯自:
https://developers.google.com...
本文轉(zhuǎn)載自http://www.lht.ren/article/14/
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/101602.html
摘要:依舊采取傳統(tǒng)的開發(fā)技術(shù)棧進(jìn)行開發(fā),同時在終端的運行體驗不輸。首先來看下前端開發(fā)框架目前與構(gòu)成了三大最流行的前端開發(fā)框架,具有組件化以及三大特性,還學(xué)習(xí)的,引入了狀態(tài)管理模塊。 摘要: WEEX依舊采取傳統(tǒng)的web開發(fā)技術(shù)棧進(jìn)行開發(fā),同時app在終端的運行體驗不輸native app。其同時解決了開發(fā)效率、發(fā)版速度以及用戶體驗三個核心問題。那么WEEX是如何實現(xiàn)的?目前WEEX已經(jīng)完全開...
摘要:處理和函數(shù)之間關(guān)系的程序稱為路由。模板引擎是由實現(xiàn)的是內(nèi)置的模板語言參照設(shè)計思想設(shè)計的,跟差不多渲染模板默認(rèn)情況下,在程序文件夾中的子文件夾中尋找模板。如果需要可在文件夾中使用子文件夾存放文件。 1 程序的基本結(jié)構(gòu) 1.1初始化 所有Flask 程序都必須創(chuàng)建一個程序?qū)嵗eb 服務(wù)器使用一種名為Web 服務(wù)器網(wǎng)關(guān)接口(Web Server Gateway Interface,WSG...
摘要:有效防止黑客對某一個特定注冊用戶用特定程序暴力破解方式進(jìn)行不斷的登陸嘗試。可以通過指定候選樣式。存儲大小數(shù)據(jù)大小不能超過。初始化樣式會對有一定的影響,但魚和熊掌不可兼得,力求影響最小的情況下初始化樣式。二十和聯(lián)系他們都能讓元素不可見。 一、前端需要注意的SEO (1)合理的 title、description 和 keywords,他們的搜索權(quán)重逐個減小title 強(qiáng)調(diào)重點即可,重要關(guān)...
摘要:有效防止黑客對某一個特定注冊用戶用特定程序暴力破解方式進(jìn)行不斷的登陸嘗試??梢酝ㄟ^指定候選樣式。存儲大小數(shù)據(jù)大小不能超過。初始化樣式會對有一定的影響,但魚和熊掌不可兼得,力求影響最小的情況下初始化樣式。二十和聯(lián)系他們都能讓元素不可見。 一、前端需要注意的SEO (1)合理的 title、description 和 keywords,他們的搜索權(quán)重逐個減小title 強(qiáng)調(diào)重點即可,重要關(guān)...
摘要:有效防止黑客對某一個特定注冊用戶用特定程序暴力破解方式進(jìn)行不斷的登陸嘗試。可以通過指定候選樣式。存儲大小數(shù)據(jù)大小不能超過。初始化樣式會對有一定的影響,但魚和熊掌不可兼得,力求影響最小的情況下初始化樣式。二十和聯(lián)系他們都能讓元素不可見。 一、前端需要注意的SEO (1)合理的 title、description 和 keywords,他們的搜索權(quán)重逐個減小title 強(qiáng)調(diào)重點即可,重要關(guān)...
閱讀 2882·2021-09-28 09:36
閱讀 3608·2021-09-27 13:59
閱讀 2484·2021-08-31 09:44
閱讀 2278·2019-08-30 15:54
閱讀 2352·2019-08-30 15:44
閱讀 1180·2019-08-30 13:45
閱讀 1223·2019-08-29 18:38
閱讀 1207·2019-08-29 18:37