1. Give a conclusion first

• There will be an impact, but in most cases it will be small;
• The real performance risks are:
• "A lot of overflow: scroll + custom scroll bar style + high frequency scrolling"

In other words:

• Native Scrollbars: Almost nothing to worry about
• Custom scroll bars (especially WebKit style): need to control the number

2. Why “many scroll bars” may affect performance?

we start from Browser underlying implementation Come and see.

3. How is scrolling implemented in the browser?

1️⃣ Native scrolling (best case scenario)

• Scroll ≠ Re-Layout

• In most cases it is:

  Composite（GPU 位移）

• The browser will treat the scrollable area as an independent scrolling layer

👉 Extremely fast

2️⃣ What does overflow: scroll do?

• Create a scroll container

• The browser needs maintenance:

  • scroll offset
  • clipping area
  • scroll event dispatch

📌 scroll itself is cheap

4. Where does the performance problem really occur?

🔥 Focus: Customize scroll bar style

::-webkit-scrollbar
::-webkit-scrollbar-thumb
::-webkit-scrollbar-track

What happens after customization?

• The scroll bar becomes:

  • Part of normal DOM drawing

• During scrolling:

  • Participation required Paint
  • Can’t completely follow the native synthesis path

📉 Paint times ↑

5. Many scroll bars + custom styles = risk points

Typical high-risk scenarios

页面上有 50~100 个
overflow: scroll 的容器
并且：
- 都使用了 ::-webkit-scrollbar 样式
- 同时滚动（如列表、拖拽）

May cause:

• Paint frequently
• Too many compositing layers
• Stuttering in scrolling (especially on low-end devices)

6. How to verify DevTools?

1️⃣ Open Paint flashing

DevTools → Rendering → Paint flashing

2️⃣Scroll the page

Native scroll bar:

• Almost no green flicker

Custom scroll bars:

• The scroll bar area frequently flashes green
• FPS drop

👉 This is Paint’s proof

7. Will setting the scroll bar style globally affect "all scrolling"?

CSS example:

* {
  scrollbar-width: thin;            /* Firefox */
}

::-webkit-scrollbar {
  width: 6px;
}

Browser behavior:

• Only works on scrollable containers

• Scrollbars are not created in vain

• But:

  • Each scroll container will have styles applied

📌 The style itself is not expensive, the cost is the painting when scrolling

8. Under what circumstances can it be used with confidence?

✅Safety scenarios

• Small number of scroll containers (< 10)
• Low scrolling frequency
• Mainly desktop
• No scrolling in animation/drag

⚠️ Need to be cautious

• Large backend system
• virtual list
• Multiple nested scroll areas
• Mobile WebView

9. Engineering-level best practices

1️⃣ If you can use scroll, don’t use it.

• Page-level scrolling is better than local scrolling
• Reduce nested scroll areas

2️⃣ Only customize “key areas”

/* ❌ 全局 */
::-webkit-scrollbar {}

/* ✅ 指定容器 */
.list::-webkit-scrollbar {}

3️⃣ Use overflow: auto instead of scroll

/* ❌ 永远显示滚动条 */
overflow: scroll;

/* ✅ 需要时才显示 */
overflow: auto;

Reduce:

• scroll container quantity
• Synthetic layer pressure

4️⃣ Avoid scroll bar animation

/* ❌ */
::-webkit-scrollbar-thumb {
  transition: all 0.3s;
}

repaint is triggered when scrolling

5️⃣ Use “virtual scrolling” for large lists

(React/Vue scenario)

• react-window
• vue-virtual-scroller

10. Summary

• The browser's native scrolling can often be done in the compositing stage, with good performance.
• But if you customize the style of the scroll bar, the scroll bar will participate in the drawing.
• In a large number of overflow: scroll containers and high-frequency scrolling scenarios,
• May increase paint and compositing overhead.
• Therefore, global custom scroll bar styles should be avoided in projects.
• And reduce the number of nested scrolling containers.