整合營銷服務商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
站前端的用戶體驗，決定了用戶是否想要繼續(xù)使用網站以及網站的其他功能，網站的用戶體驗佳，可留住更多的用戶。除此之外，前端優(yōu)化得好，還可以為企業(yè)節(jié)約成本。那么我們應該如何對我們前端的頁面進行性能優(yōu)化呢？
前端性能優(yōu)化可以分為三個方面：接口訪問優(yōu)化、靜態(tài)資源優(yōu)化和頁面渲染速度優(yōu)化。
1.1、減少http請求，合理設置 HTTP緩存
http協(xié)議是無狀態(tài)的應用層協(xié)議，每次發(fā)送http請求時，都需要建立連接、通信、斷開連接，在服務器端每個http都需要開啟獨立的線程去處理。所以盡量減少http請求，盡可能地提高訪問性能。
減少http請求的方法：
1.2、減少cookie傳輸
cookie 存在于 http 頭，在客戶端與服務器之間交換，盡可能地控制 cookie 的大小，cookie越小，響應速度越快，減少 cookie 傳輸，響應速度更快。
1.3、使用CDN提供靜態(tài)文件
使用 CDN 可以更快地在全球范圍內獲取到你的靜態(tài)文件，加快網頁加載。
1.4、啟用 GZIP 壓縮
http 協(xié)議上 GZIP 編碼，是一種用來改進 web 應用程序的。開啟 GZIP 后，服務器會把網頁內容壓縮后傳輸，一般能壓縮到原大小40%，這樣網頁傳輸速度就更快了。GZIP 有兩大好處：一是減少存儲空間，二是通過網絡傳輸文件時，可以減少傳輸時間。
1.5、分域存放資源
HTTP 客戶端一般對同一個服務器的并發(fā)連接個數(shù)都是有限制的，通常最大并行連接為四了，剩下的會進入等待隊列，等前邊的執(zhí)行完畢，等待的才會執(zhí)行。所以利用多域名主機存放資源，增加并行連接量，縮短資源加載時間。
1.6、減少頁面重定向
開啟 https 可以有效防范攻擊，保證用戶始終訪問到網站的加密連接，保護數(shù)據(jù)安全，同時省去 301/302 跳轉的時間，大大提升網站的安全系數(shù)和用戶體驗。
如果在網站設置當用戶訪問域名的時候強制 https 進行 301 或者 302 跳轉，但是這個過程中，用到 HTTP 因此容易發(fā)生劫持，受到第三方的攻擊。所以盡可能使用https安全。
1.7、避免使用iframe
iframe 相當于本頁面又嵌套了一個頁面，消耗性能，還要加載嵌套頁面的資源，所以更消耗時間。
1.8、借用瀏覽器緩存
ajax 請求到的數(shù)據(jù)，可以緩存到瀏覽器，下次使用的時候無需再次獲取，直接取緩存數(shù)據(jù)就可以。這個會根據(jù)具體的項目來做，比如常用的角色類型就會緩存，獲取到的普通數(shù)據(jù)為了保證實時性，不能使用緩存。
2.1、壓縮 html、css、js 等文件
刪除不必要的空格、注釋和中行，減少文件大小，顯著減少用戶下載時間，加快網頁加載速度。可以直接使用壓縮工具，可以自動刪除所有不必要內容。
2.2、在 js 之前引用 css
這是一個小細節(jié)，js 執(zhí)行的時候會進入阻塞，如果放入 js 之后加載，會等待 js 執(zhí)行完成之后才能加載 css，渲染頁面，此時就會出現(xiàn)布局錯亂。所以 css 文件需要非阻塞引入，以防DOM 花費更多時間才能渲染。
2.3、非阻塞 js
js 會阻止 html 文檔的正常解析，當解析器到達 script 標記時，它會停止解析并執(zhí)行腳本。所以我們經常把 script 引入的 js，放到 html 中最底下。如果需要讓腳本位于頁面頂部，建議添加非阻塞屬性。經常使用 defer 和 async 來異步加載js文件。
<!-- 使用defer -->
<script defer src="foo.js" ></script>
<!-- 使用async -->
<script async src="foo.js"></script>2.4、圖片壓縮
最常見的就是 css 雪碧，就是將很多很多的小圖標放在一張圖片上，就稱為雪碧圖。雪碧圖最大優(yōu)點就是可以減少http請求，除此也能壓縮圖片文件大小。使用的時候，通過設置 background-position ，移動圖片的位置。除此之外，網站用到的大圖，也需要在保證圖片質量前提下優(yōu)化到最小。
2.5、矢量圖替代位圖
矢量圖（SVG）往往比圖像小很多，縮放的時候不失真，這些圖像還可以通過 css 進行動畫和修改，比位圖方便控制。可以的話，盡量用矢量圖多點。
2.6、js代碼相關優(yōu)化
3.1、懶加載
素材類的網站，頁面一屏展示很多圖片，而且圖片還不能失真，圖片加載太多，網頁加載慢得很，所以就引用懶加載，只加載可視區(qū)的圖片，避免加載可以能不需要或不必要的圖像。改善頁面的響應時間。
3.2、避免響應式布局
響應式網站雖然能夠兼容所有終端設備，但是會出現(xiàn)隱藏部分無用內容，浪費帶寬，加載時間還長，頁面的渲染時間也長。想更多了解響應式布局，請點擊《前端響應式布局為什么是個坑？》。
3.3、設置大小，避免重繪
遇到 img 標簽，會立馬發(fā)送一個 http 請求，下載圖片，頁面繼續(xù)向下渲染，等圖片加載成功了，發(fā)現(xiàn)圖片的寬高大小發(fā)生變化，影響后邊排版，所以頁面會重新再繪制一次這部分。所以盡可能設置圖片的大小。
3.4、減少DOM元素
解析 html 內容，將標簽轉化為DOM節(jié)點，之后再解析其他文件，DOM元素越少，也就是標簽越少，文件轉化得越快，加載速度也就快了。
3.5、減少 Flash 的使用
flash 文件比較大，加載起來耗時。除此，flash 插件還需要運行才能運行，最主要有些瀏覽器flash插件馬上要下線了，建議盡量不用 flash。
3.6、文件順序
css文件放在最頂部，優(yōu)先渲染。js放在最底部，避免阻塞。
讓網頁如何加載更快，有好多的細節(jié)，還是要好好提升自己的技能~~~~~~~~~
點個關注！更多分享內容。
年來，隨著互聯(lián)網的高速發(fā)展，網頁中蘊藏的海量數(shù)據(jù)成為各行業(yè)競爭的關鍵。而在獲取這些數(shù)據(jù)的過程中，一個重要的技術就是爬蟲。結合JavaScript渲染技術，爬蟲不僅能夠更好地應對動態(tài)網頁，還能為用戶帶來更加精準、豐富的信息。下面小編將為您詳細介紹這一新興技術。
一、爬蟲與JavaScript渲染的概念
爬蟲是一種自動化程序，可以模擬人類對網頁進行訪問，并從中提取所需信息。而JavaScript渲染則是指網頁加載時，瀏覽器會執(zhí)行其中的JavaScript代碼，生成并顯示頁面內容。傳統(tǒng)的爬蟲技術只能抓取靜態(tài)網頁內容，無法獲取通過JavaScript動態(tài)生成的信息。而結合爬蟲和JavaScript渲染技術，則可以解決這一問題。
二、爬蟲與JavaScript渲染技術的優(yōu)勢
1.動態(tài)網頁抓取：傳統(tǒng)爬蟲只能抓取靜態(tài)頁面，無法獲取動態(tài)生成的內容。而結合JavaScript渲染技術，爬蟲可以模擬瀏覽器行為，獲取完整的網頁數(shù)據(jù)。
2.數(shù)據(jù)準確性：JavaScript渲染技術可以實時加載和更新數(shù)據(jù)，爬蟲可以及時抓取最新的信息，保證數(shù)據(jù)的準確性。
3.用戶體驗優(yōu)化：通過爬蟲和JavaScript渲染技術，網頁內容可以更加豐富、多樣化，提升用戶體驗。
4.數(shù)據(jù)分析與挖掘：爬蟲獲取到的數(shù)據(jù)可以用于各種分析和挖掘工作，為企業(yè)決策提供參考。
三、爬蟲與JavaScript渲染的應用案例
1.電商行業(yè)：通過爬蟲和JavaScript渲染技術，企業(yè)可以實時抓取競爭對手的商品信息、價格變動等數(shù)據(jù)，從而制定更具競爭力的銷售策略。
2.新聞媒體：通過爬蟲和JavaScript渲染技術，新聞媒體可以快速抓取各類資訊，并實時更新到自己的平臺上，提供給用戶最新、全面的新聞內容。
3.社交媒體監(jiān)測：通過爬蟲和JavaScript渲染技術，企業(yè)可以實時監(jiān)測社交媒體上與自身品牌相關的討論和用戶反饋，及時做出回應和調整。
4.數(shù)據(jù)分析與預測：通過爬蟲和JavaScript渲染技術，可以獲取大量的數(shù)據(jù)，進行數(shù)據(jù)分析和挖掘，為企業(yè)決策提供可靠的依據(jù)。
四、注意事項與發(fā)展趨勢
1.合法合規(guī)：在使用爬蟲技術時，需要遵守相關法律法規(guī)，尊重網站的使用規(guī)則，避免侵犯他人的權益。
2.技術更新迭代：隨著互聯(lián)網技術的不斷發(fā)展，爬蟲和JavaScript渲染技術也在不斷更新迭代中。開發(fā)者需要及時了解新技術，并靈活應用于實際項目中。
總結：
爬蟲與JavaScript渲染技術的結合為我們帶來了更多可能性。無論是從數(shù)據(jù)獲取、用戶體驗還是商業(yè)決策等方面，這一技術都具有重要意義。然而，在應用過程中，我們也要遵守相關規(guī)定，保護他人的權益。相信隨著技術的不斷發(fā)展，爬蟲與JavaScript渲染將會在更多領域展現(xiàn)出其強大的潛力和價值。
面性能和用戶體驗的各個指標怎么來優(yōu)化呢？open signal官方提供了2018年2月份統(tǒng)計的全世界4G網絡覆蓋率和通信速率的統(tǒng)計分布圖如下，在目前移動互聯(lián)網的浪潮下，我們要利用好用戶終端設備的每個字節(jié)的流量。
當然頁面性能和體驗優(yōu)化并不是一蹴而就的，需要不斷的研究、跟蹤，發(fā)現(xiàn)問題，解決問題。但是我們可以在一開始編寫業(yè)務代碼的時候就做的更好，做到極致。所以，關于優(yōu)化實戰(zhàn)我們主要分為兩部分：加載渲染鏈路優(yōu)化 和 編程代碼優(yōu)化。
從訪問url到頁面呈現(xiàn)，整個鏈路可以做優(yōu)化的思路。
幸運的是，W3C推薦的Navigation Timing標準中所定義的核心的頁面性能數(shù)據(jù)，它包含了從上個頁面銷毀到跳轉到當前頁面加載完成每個階段所消耗的時間。在canIuse上查到的兼容性也很好：
利用這個接口可以很方便的幫助我們排查鏈路問題。在Navigation Timing標準中介紹到這個API主要包含兩個接口：PerformanceTiming和PerformanceNavigation，這兩個接口由瀏覽器進行實現(xiàn)和維護，當瀏覽器創(chuàng)建頁面的時候就會把接口定義的相關數(shù)據(jù)掛載到window.performance.timing和window.performance.navigation這兩個屬性上。我們可以打開一個網頁看一下：
我們把這兩個圖對比一下，就可以很容易的排查出頁面的加載鏈路問題。
靜態(tài)資源鏈路
打開頁面的第一步是請求頁面的html，這里面涉及TTFB這個綜合指標。同時如果有必要我們也可以統(tǒng)計DNS時間和TCP時間。
DNS時間：主要是根據(jù)請求域名查詢到對應主機IP的時間。這個和DNS服務器有關系，也可能和本地緩存有關，如果這個很慢，可以找服務商排查下問題。
TCP時間：tcp是承接http協(xié)議的下層協(xié)議。主要是路由到主機ip，并建立tcp鏈接的時間。這個時間反應了服務器到用戶客戶端之間鏈路是否通暢，網絡是否通暢。
請求完HTML之后，就開始解析html代碼，按照從上至下、自然順序解析，解析內聯(lián)CSS代碼或者加載外鏈CSS腳本，解析內聯(lián)Javascript腳本，或者加載外鏈Javascript腳本。由于瀏覽器是單線程的，這些CSS和Javascript腳本很可能就會造成頁面卡頓。參考 瀏覽器線程理解與microtask與macrotask。
CDN是內容分發(fā)網絡，主要用于緩存靜態(tài)資源。CDN服務商一般會在全國各地部署服務，而且?guī)捄艽螅@樣訪問CDN的資源時就可以有較短的路由路徑，而且?guī)捯脖容^大，訪問比較快。
加載完JS和CSS之后，瀏覽器開始解析執(zhí)行。Chrome的渲染流程是這樣的：（可以參考 高性能CSS動畫）
為了讓瀏覽器更快的解析渲染，我們需要考慮這幾點：
介紹一下code split的方案： react-loadable
// 未處理
import OtherComponent from './OtherComponent';
const MyComponent = () => (
<OtherComponent/>
);
// 使用react-loadable按需加載
import Loadable from 'react-loadable';
const LoadableOtherComponent = Loadable({
loader: () => import('./OtherComponent'),
loading: () => <div>Loading...</div>,
});
const MyComponent = () => (
<LoadableOtherComponent/>
);
這個也可以在打包工具統(tǒng)一配置，不用每個模塊都自己寫。
只有瀏覽器盡快渲染出來，用戶才能盡快的可以交互。
上面我們梳理了加載到解析渲染過程應該做的事情，那么如果你這些都做好了，發(fā)現(xiàn)網頁表現(xiàn)依然不盡人意，那么你就要考慮做一下數(shù)據(jù)埋點。其實數(shù)據(jù)埋點在企業(yè)項目中也是必不可少的，和性能體驗優(yōu)化構成閉環(huán)。通過數(shù)據(jù)來發(fā)現(xiàn)頁面性能和體驗的問題，更有針對的進行解決。
事實上數(shù)據(jù)埋點分為三類：
工程埋點，統(tǒng)計工程上的數(shù)據(jù)信息，比如頁面秒開率，dns時間等，也就是我們上節(jié)課總結的性能和體驗數(shù)據(jù)指標。
資源緩存
這一節(jié)我們單獨介紹緩存，是的，利用好緩存可以解決很多問題，包括頁面加載和渲染的問題都能得到很好的優(yōu)化。
常見的h5緩存方案有很多種，
通常，與頁面加載性能相關的，有下面幾種緩存，
（1）MemoryCache
MemoryCache，資源存放在內存中，一般資源響應回來就會放進去，頁面關閉就會釋放。內存存取性能可達磁盤緩存性能的100倍，但這還不是MemoryCache的最大優(yōu)勢，MemoryCache最大的優(yōu)勢是離排版渲染引擎非常近，可以直接被讀取，甚至無需經過線程轉換。在真實的頁面訪問過程中，獲取資源的時間，磁盤IO僅僅是其中的一部分，更多的時間往往消耗在各種線程拋轉。
（2）ClientCache
ClientCache，客戶端緩存，比如，手淘里的ZCache（離線壓縮包緩存），本質上屬于磁盤緩存。這類Cache的優(yōu)點是能以相對可控的方式讓資源提前緩存在磁盤，但它也有一系列的成本。比如，它需要一套服務器與客戶端協(xié)同的下發(fā)更新邏輯，服務器端需要管理下發(fā)，客戶端需要提前解壓縮。我們可能覺得提前解壓并不是什么弱點，但如果有一千個離線包，這個問題就比較嚴重了，如果不提前解壓，就無法保證首次訪問性能，如果提前解壓會讓IO非常繁忙，可能會造成客戶端打開時嚴重卡頓。
（3）HttpCache
HttpCache，是歷史比較悠久的緩存，它利用標準的 Cache-Control 與服務器端進行協(xié)商，根據(jù)標準的規(guī)則去緩存或更新資源。它應用非常廣泛，是非常有效果的一種磁盤緩存。它的缺點是完全由瀏覽器按標準規(guī)則控制，其它端的控制力度非常弱。比如，某些被HttpCache緩存的靜態(tài)資源出問題了，通常只能是改頁面，不再使用出問題的資源，而無法主動清除出問題的資源。參考http請求緩存頭，HTTP協(xié)商緩存VS強緩存原理
（4）NetCache
網絡相關的Cache，一般是指DNS解析結果的緩存，或預連接的緩存。DNS預解析和預連接是非常重要的，創(chuàng)建一個Https連接的成本非常大，通常需要600ms以上，也就是說，頁面如果有關鍵資源需要全新建連接，秒開基本是不可能了。
（5）CDN
CDN一般是通過負載均衡設備根據(jù)用戶IP地址，以及用戶請求的URL，選擇一臺離用戶比較近，緩存了用戶所需的資源，有較好的服務能力的服務器，讓用戶從該服務器去請求內容。它能讓各個用戶的緩存共享，縮短用戶獲取資源的路徑，來提升整體的性能。
當然，還有其它非常多類型的Cache，比如，
JS相關，V8 Bytecode Cache，字節(jié)碼緩存，能極大的減少JS解析耗時，甚至可以提升3-6倍的性能。參考：前端優(yōu)化系列 – JS解析性能分析
渲染相關，圖片解碼數(shù)據(jù)緩存，是一塊非常大的內存緩存，約100M，能保證頁面滾動過程可以實時獲取到圖片解碼數(shù)據(jù)，讓滾動非常流暢。
頁面相關，頁面緩存，Safari的PageCache，F(xiàn)irefox的Back-Forward Cache，UC瀏覽器的WebViewCache，都是一樣性質的緩存，將整個執(zhí)行過的頁面保存在內存。標準的頁面緩存，進入的條件非常苛刻，大部分情況都無法進入，而且在前進后退的場景才允許使用。
前面介紹了很多理論層面的內容，我們接下來介紹一些實踐優(yōu)化案例。
（1）預置資源進MemoryCache
在頁面的onPageFinished的回調里面去檢查是否有資源可以預置，如果有，就通過相關接口把資源設置進內核的MemoryCache。我們并不知道用戶即將會訪問什么頁面，如果把大量的資源都預置進內存，而用戶卻沒有使用，那就會造成浪費。另外，資源在內核內存，僅僅是加快了資源的加載速度，頁面的首屏包含非常多非常復雜的流程，某個流程的加速并不一定能帶來整體性能的提升，比如，非關鍵的JS放在內存，可能就會先于一些關鍵JS被提前執(zhí)行，反而讓首屏更慢。所以，選擇放那些資源進內存也是非常有講究的，能預置的資源一般是 非常關鍵的更新頻率較低的少量公共基礎資源。
對于一般公司來說，沒有能力自己定制webview渲染的內核，可以看下系統(tǒng)默認webview內核有沒有這樣的接口來實現(xiàn)操作MemoryCache預置數(shù)據(jù)的能力。
（2）預加載資源進HttpCache
預置資源進內存，對加載性能的提升是最明顯的，但成本也是最大的，會占用用戶手機寶貴的內存資源。另外一種預置資源的思路是，提前通過內核去預加載一些資源，資源加載回來之后就直接保存在標準的HttpCache。資源在HttpCache和在客戶端緩存（比如，手淘ZCache）的性能差別不大。但如果資源不能放進ZCache，通過這種方式提前放到HttpCache，也是一種優(yōu)化思路。
（3）使用WebViewCache極速切換頁面
H5頁面的加載流程是非常重的一套流程，即使同一個頁面多次重復訪問，也需要走比較完整的流程，耗時極長，這與用戶的期望是不符的，通常用戶期望訪問過的頁面就能快速展現(xiàn)出來。在一些特定的場景，H5也是可以做到極速展現(xiàn)的，比如，前進后退。其它的場景，比如頁內幾個TAB切換，是否也可以用上這類緩存呢？也是可以的。原理上也是比較簡單的，在頁面首次訪問時，會將排版渲染好的頁面放進WebViewCache里，WebViewCache是存儲完整頁面的一塊內存。
用戶再次訪問該頁面時，會將WebViewCache內存中的完整頁面讀取出來，直接繪制展現(xiàn)，而無需再進行加載解析排版渲染等流程，從而達到極速打開的效果。
除了內核提供WebViewCache基礎技術之外，前端也需要與內核進行一定的交互，比如，通過JSAPI查詢當前頁面是否在WebViewCache，如果在則返回它在WebViewCache列表的位置，然后前端就可以使用JSAPI去跳轉到相應位置的頁面，內核就把頁面從內存讀取和展現(xiàn)出來。使用此類技術，頁面一般能在500ms左右完全展現(xiàn)出來，具有非常好的用戶體驗。
當然這個也是需要瀏覽器內核提供這種能力，如果公司有自己的內核開發(fā)團隊，可以做到定制。
（4）前端使用LocalStorage緩存HTML文檔
當前前端渲染非常流行，頁面大部分的邏輯都會由前端JS去執(zhí)行，JS執(zhí)行完才會生成完整的HTML文檔，而JS執(zhí)行的成本是非常大的，JS執(zhí)行時間可能占據(jù)首屏時間的50%，有些甚至能達到80%。那么，我們有沒有可能將JS執(zhí)行生成的完整HTML文檔緩存起來呢，下次訪問時直接使用已緩存的頁面，而無需重復執(zhí)行JS？這也是可以的原理上也不復雜，首次訪問頁面時，JS執(zhí)行完之后會生成完整的HTML文檔，我們將HTML文檔緩存到LocalStorage里面。
在后續(xù)的訪問中，我們優(yōu)先從LocalStorage里面讀取HTML文檔，解析排版渲染頁面，而無需JS執(zhí)行去生成頁面，讓頁面展現(xiàn)速度得到極大的提升。
這種方案的關鍵在于前端能夠實現(xiàn)一套DOM-Diff更新的機制，在從LocalStorage讀取HTML頁面的同時，前端還會發(fā)起請求去更新HTML文檔，在新的HTML文檔回來之后，會和舊的文檔進行Diff，針對Diff來進行局部更新，這樣能保證頁面得到及時的更新。
(5) service worker
參考使用 Service Workers提升體驗，這里附帶介紹下這個方案，目前service worker 只有在android的webview中可用，ios還不支持。我們通過先注冊一個serviceworker服務，指定哪些資源和數(shù)據(jù)需要存儲，然后下次請求頁面會自動激活這個service worker，頁面請求時會先從service worker中返回緩存的數(shù)據(jù)。當然service worker中需要自己處理版本和維護數(shù)據(jù)更新。
*請認真填寫需求信息，我們會在24小時內與您取得聯(lián)系。
