關于控制板開發的幾項建議

在互聯網盛行的今日，越來越多的在線用戶期望得到安全可靠并且快速的拜訪體會。針對控制板開發網頁過于脹大以及第三腳本蠶食流量等問題，Radware向網站運營人員提出以下改進主張，協助他們為用戶提供最快最優質的拜訪體會。

1、 管理“頁面脹大”頁面巨細與功能有著密切的聯系。據調查顯示，100強電商頁面巨細中位數達到了1492KB，比一年半之前增大了48%。

在研究報告里加載最快的10個頁面中，頁面包括的資源懇求中位數為50個，頁面巨細中位數為556KB。而加載最慢的10個頁面中，頁面包括的資源懇求中位數為141個，頁面巨細中位數為3289KB。換句話說，加載最慢的頁面的資源中位數簡直是加載最快的頁面的三倍，頁面巨細則是六倍。

細心研究頁面尺度巨細，我們能夠得到更多的信息。加載最快的10個頁面所包括的資源總數規模比較密集：在15個~72個之間;頁面尺度最小的僅為251KB，最大的2003KB。而加載最慢的10個頁面所包括的資源總數規模則比較廣泛：在89個~373個之間;頁面尺度最小為2073KB，最大的則超過了10MB。

2、進行圖畫優化

　　圖畫是形成頁面脹大的罪魁禍首之一，通常占據頁面字節數的50-60%。在頁面中添加圖片或是將現有圖片擴大，是敏捷獲取用戶并提高業務轉化率的有效方式。但是這種辦法會對功能形成嚴峻的影響。

進行圖畫優化是提高功能最簡單的一種辦法，它能夠使頁面加載更快。為了更有效的完結圖畫渲染，圖畫有必要經過壓縮和整合、圖畫的尺度和格局有必要經過細心調整，圖畫質量也有必要經過優化，這樣才能夠依據圖畫的重要性進行差異化的加載處理。

3、 控制第三方腳本

在典型的頁面效勞器懇求中，來自于第三方腳本的懇求占了其間的50%或更多。這些第三方腳本不僅會添加頁面的字節數，帶來推遲，并且也會成為控制板開發頁面中最大的潛在毛病點。無呼應、未經優化的第三方腳本會降低整個網絡的加載速度。

　解決辦法是推遲第三方腳本的加載，將其放在要害頁面內容之后進行加載，更為理想的狀況是放在頁面onLoad事情之后加載，這樣才不會影響企業的搜索排名(谷歌將onLoad事情作為加載時刻指標)。關于一些分析東西和第三方廣告商而言，假如推遲第三方腳本加載的辦法不可行，能夠利用腳本的異步版別，與要害內容的加載同步進行。用戶有必要了解網站中有哪些腳本，刪去那些無用的腳本，并對第三方腳本的功能進行持續監控。

4、真實做到移動設備優先“移動設備優先”并不是一個全新的概念。

早在2013年，移動設備的使用量就現已超過了臺式機，但是與很多口頭許諾的移動功能相比，真實專注于移動設備的開發仍是存在必定的差距。例如，2011年11月，移動設備上的均勻頁面巨細為475KB，現在則增加至897 KB。也就是說，在短短三年之間，均勻頁面巨細簡直翻了一番。

盡管移動設備和網絡取得了一些進展，但就功能而言，仍是無法與巨細已挨近1MB的效勞頁面需求保持同步。我們知道，頁面巨細與加載時刻休戚相關，移動用戶對緩慢的加載速度特別敏感。假如企業期望網站能夠真實做到“移動設備優先”，就有必要正確處理這些問題。

5、在進行呼應式控制板開發規劃時統籌功能

呼應式規劃讓規劃人員和開發人員能夠更好地控制控制板開發頁面的外觀和感覺。它能夠使跨多渠道和設備上的頁面變得更漂亮。但一起也會帶來巨大的功能丟失，這些功能丟失并不能經過更快速的瀏覽器、網絡和小東西得到緩解。并且隨著時刻的推移，這樣影響還將持續惡化。

呼應式規劃建立在樣式表和JavaScript之上。但是，低效的CSS和JS所帶來的功能問題遠遠大于其規劃優勢給我們帶來的優點。樣式表應當放在HEAD文檔中，用以完結頁面的逐步渲染。但是，樣式表卻經常出現在頁面其它位置，這就阻礙了頁面的渲染速度。換句話說，JavaScript文件應當放在頁面底部或在要害內容加載完結之后再被加載才是合理的處理方式。