建站
咨詢
售后
建站咨詢
新聞中心
數(shù)周前，在倫敦 Heathrow 機場等飛機的空閑中，我順便處理了一些工作上的事情。不經(jīng)意間發(fā)現(xiàn) Github 在性能方面的一些問題，頗為詫異。通過新 tab 打開的頁面，其加載速度竟然比直接點擊鏈接打開的頁面要快。
成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設,南澗企業(yè)網(wǎng)站建設,南澗品牌網(wǎng)站建設,網(wǎng)站定制,南澗網(wǎng)站建設報價,網(wǎng)絡營銷,網(wǎng)絡優(yōu)化,南澗網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
點擊鏈接的同時復制鏈接并在新的 tab 頁中打開?？梢钥吹剑M管先點擊的是鏈接，但渲染更快的卻是新 tab 中打開的頁面。
有一說一
頁面加載的時候，瀏覽器會接收網(wǎng)絡數(shù)據(jù)流，并將其輸出(pipe)給 HTML 解析器，HTML 解析器再將數(shù)據(jù)輸出到文檔。這意味著，頁面是邊加載邊渲染的。對于一個 100k 的頁面來說，瀏覽器很可能在接收到 20k 數(shù)據(jù)的時候就開始渲染出一些可用內容了。
這個偉大又古老的特性，常常被開發(fā)者們有意無意地忽略了。多數(shù)提高加載性能的建議都歸結于一點，即“展示你所拿到的東西” —— 別怕，千萬不要傻傻等待一切加載完成之后再去展示內容。
GitHub 當然是關注性能的，所以他們使用服務端渲染。但在同一個 tab 下瀏覽頁面時，他們用 JavaScript 重新實現(xiàn)了導航(navigation)功能，類似下面這樣：
- // …一堆重新實現(xiàn)瀏覽器導航功能代碼…
- const response = await fetch('page-data.inc');
- const html = await response.text();
- document.querySelector('.content').innerHTML = html;
- // …加載更多重新實現(xiàn)導航功能的代碼…
這違反了規(guī)則，因為在 page-data.inc 下載完成之前什么事情都沒干。而服務端渲染版完全不會這樣囤積內容，其內容是流式的，這樣就要快得多了。就 Github 的客戶端渲染來說，很多 JavaScript 代碼完全減慢了渲染過程。
這里我僅僅只是拿 Github 舉例子 —— 這種反模式在單頁應用中比比皆是。
在頁面之內切換內容可能確實有些好處，特別是存在大量腳本的情況下，無需重新執(zhí)行全部腳本即可更新內容。但我們能否在不放棄流的情況下完成這樣的工作呢?我曾經(jīng)常說 JavaScript 沒有辦法對流進行解析，但其實還是有的……