Posts match “ blink ” tag:

週末長知識: scrollable <div> 的捲動重繪問題

前端也是做了很久,直到最近才發現這個事實,感覺有點羞愧 ww
為了讓同樣的事情不要再重演,決定專文說明之!

以下文章的內容基本以 Chrome 瀏覽器作為展示用的平台,所以一些 render performance 的問題不見得會出你家的瀏覽器上,畢竟各家瀏覽器為了讓使用者能夠順暢瀏覽網頁,可能還是有做一些各自的調整。

現在已知的是 Opera 在本文主題的範圍內所受的影響與 Chrome 是一樣的(同為 Blink引擎)。

scrollable <div>

其實直接看一下 CSS 就明白我的意思啦

.scrollable {
    height: 100%;
    overflow: auto;
}

其實就是帶有捲軸的 <div> 而已,它的特性是在內容超出設定的 寬度/高度 之後會出現捲軸(用 overflow: scroll 的話,會一直有捲軸)

捲動重繪問題,初次見面!

其實就是在新版的 手打 首頁。

其實一開始還感覺不大出來,但多捲幾下之後發現這個捲動的吃力程度連我的(三年前的)超級遊戲桌機都有點受不了,馬上來用 Chrome DevTools 看兩把!

從圖中可以清楚的看到每個 frame 中有很長的時間用在 painting,並且很多 frame 的運作時間超過 16~17ms,造成整體的 fps 沒辦法達到 60。

簡單的重現

Preview 的時候先按「Launch the preview in a separate window」在新視窗開啟,再來打開 DevTools 觀察比較準(原本擺在 iframe 裡可能會影響結果)

確認的方法就是開啟 DevTools 裡的「Enable paint flashing」,就可以在捲動的時候看到重繪的區域。

Read on

Blink 系瀏覽器 History API scroll restoration 的 bug

Update 2016/04/02 15:30
Opera 36(.0.2130.46) 跟 Chrome 49 同步了,所以這個問題也消失了。此文章正式壽終正寢(?)

Update 2016/03/06 14:00
更新到 Chrome 49(.0.2623.75) 以後這個問題已經修正(bug & commit);而同樣是 Blink 系的 Opera 更新比較慢,在 Opera 35(.0.2066.92) 上還是可以重現問題。


最近寫的東西幾個主要的 view 都跟捲動位置有關,而捲動位置對網站瀏覽者的體驗事關重大。

本文內容針對桌面瀏覽器。

我覺得良好的捲動位置體驗是

  1. 在同頁面重新整理後會回到一樣的位置 (在內容物不變的前提之下)
  2. 承 (1),如果內容物在重新整理後會改變 (ex: Facebook),重新整理後可以乾脆回到頂端
  3. 使用瀏覽器的「上一頁」、「下一頁」進入頁面時會保持之前瀏覽的位置
  4. 曾經瀏覽過的頁面再次透過連結點擊進去後可以重置捲動位置(不需要有 3. 的行為)

上面這幾點基本上完全在現在瀏覽器的掌握之中,然而最近發現的 Blink 系瀏覽器(Chrome、Opera)在使用 History API 時的 scroll restoration 有點奇怪

  • 程式操作後的 scroll 並不會被記錄
  • 預設的捲軸 restoration 不適合一般 single page app

這兩點發生的一個重要前提 - 「在操作之後,使用者沒有再動過捲軸(拉動 scrollbar 或是用滾輪)」

Read on