**瀏覽器中點擊鏈接:**
1. 如果是在當前頁打開的鏈接(也就是在當前選項卡打開的頁面),那么在點擊之后,瀏覽器的**加載狀態**立即變成加載中的(實際上這里面有不同的過程,待會說),此時會開始“**尋址**”,當前頁面維持原狀,不會變化,**瀏覽器地址欄URL**也沒有變化(請記住這些微妙的特征),當尋址完成(這個過程如果線路進,網絡通暢則一般很快),尋址完成后就會開始加載新的鏈接頁面了,此時當前頁面會清空,瀏覽器地址欄URL也變成目標地址,也就是**白屏**了,然后開始渲染加載的新頁面,如果加載渲染這個過程比較長,那么白屏顯示也就越久。不過現代瀏覽器為了提升體驗,減少白屏等待時間,對這個過程進行了優化,一般在開始加載新頁面時不立即顯示白屏,而是先停留原頁面,維持不變(請注意現在瀏覽器是加載狀態,而不是尋址狀態,這兩個狀態有為妙區別,稍后再說),等加載的內容可以渲染時,瀏覽器會檢測到,此時就清空原頁面,開始進入直接渲染新頁面的過程了,所以我們幾乎感覺不到白屏頁面,當然這是現代瀏覽器優化的結果。
記得上面說的瀏覽器加載狀態的那個微妙特征了嗎,細心的我們可以注意到谷歌瀏覽器在尋址的時候是逆時針旋轉,尋址完成后加載時會順時針旋轉,這個微妙的細節凸顯出來谷歌瀏覽器對細節的深入思考及卓越的極客、工程師文化。網上有一篇文章對谷歌留言器這個細節進行了說明:
[chrome瀏覽器的小圈圈逆時針轉動是什么意思?](http://www.zhihu.com/question/21138264)
[Google Chrome瀏覽器的標簽在讀取頁面時有兩種讀取狀態,一種高亮順時針快速轉動,一種稍暗逆時針慢速轉動,分別表示什么或有什么含義嗎?](http://www.zhihu.com/question/20584542?sort=created)。
>[info] 前期逆時針(尋址)慢轉時狀態欄顯示「正在發送請求」和「正在等待回應」,后來順時針(加載)快轉時就是「正在傳輸數據」,所以猜測分別是對應 DNS 查詢和傳輸數據。
2. 如果是在新標簽打開的頁面,那么直接跳轉到新標簽,就沒上面那些優化了,新頁面會由白屏狀態(尋址),到加載渲染完成。
根據這個原理,可以在頭部設置域讓瀏覽器提前緩存DNS,以加快頁面打開速度:
~~~html
<link rel="dns-prefetch" href="//static.360buyimg.com" />
<link rel="dns-prefetch" href="//misc.360buyimg.com" />
<link rel="dns-prefetch" href="//img10.360buyimg.com" />
<link rel="dns-prefetch" href="//img11.360buyimg.com" />
<link rel="dns-prefetch" href="//img12.360buyimg.com" />
<link rel="dns-prefetch" href="//img13.360buyimg.com" />
<link rel="dns-prefetch" href="//img14.360buyimg.com" />
<link rel="dns-prefetch" href="//img30.360buyimg.com" />
~~~
# 擴展知識
- 開始
- 微信小程序
- 獲取用戶信息
- 記錄
- HTML
- HTML5
- 文檔根節點
- 你真的了解script標簽嗎?
- 文檔結構
- 已經落后的技術
- form表單
- html實體
- CSS
- css優先級 & 設計模式
- 如何編寫高效的 CSS 選擇符
- 筆記
- 小計
- flex布局
- 細節體驗
- Flex
- Grid
- tailwindcss
- JavaScript
- javascript物語
- js函數定義
- js中的數組對象
- js的json解析
- js中數組的操作
- js事件冒泡
- js中的判斷
- js語句聲明會提前
- cookie操作
- 關于javascript你要知道的
- 關于innerHTML的試驗
- js引擎與GUI引擎是互斥的
- 如何安全的修改對象
- 當渲染引擎遇上強迫癥
- 不要使用連相等
- 修改數組-對象
- 算法-函數
- 事件探析
- 事件循環
- js事件循環中的上下文和作用域的經典問題
- Promise
- 最佳實踐
- 頁面遮罩加載效果
- 網站靜態文件之思考
- 圖片加載問題
- 路由及轉場解決方案
- web app
- 寫一個頁面路由轉場的管理工具
- 談編程
- 技術/思想的斗爭
- 前端技術選型分析
- 我想放點html模板代碼
- 開發自適應網頁
- 后臺前端項目的開發
- 網站PC版和移動版的模板方案
- 前后端分離
- 淘寶前后端分離
- 前后端分離的思考與實踐(一)
- 前后端分離的思考與實踐(二)
- 前后端分離的思考與實踐(三)
- 前后端分離的思考與實踐(四)
- 前后端分離的思考與實踐(五)
- 前后端分離的思考與實踐(六)
- 動畫
- 開發小技巧
- Axios
- 屏幕適配
- 理論基礎
- 思考
- flexible.js原理
- 實驗
- rem的坑,為什么要設置成百分比,為什么又是62.5%
- 為什么以一個標準適配的,其它寬度也能同等適配
- 自適應、響應式、彈性布局、屏幕適配
- 適配:都用百分比?
- 番外篇
- 給你看看0.5px長什么樣?
- 用事實證明viewport scale縮放不會改變rem元素的大小
- 為什么PC端頁面縮放不會影響rem元素
- 究竟以哪個為設備獨立像素
- PC到移動端初試
- 深入理解px
- 響應式之柵格系統
- 深入理解px(二)
- 一篇搞定移動端適配
- flex版柵格布局
- 其他
- 瀏覽器加載初探
- 警惕你的開發工具
- JS模塊化
- webpack
- 打包原理
- 異步加載
- gulp
- 命名規范
- 接口開發
- sea.js學習
- require.js學習
- react學習
- react筆記
- vue學習
- vue3
- 工具、技巧
- 臨時筆記
- 怎么維護好開源項目
- 待辦
- 對前端MVV*C框架的思考
- jquery問題
- 臨時
- 好文
- 節流防抖