jvinhit//lab

Search posts

Type to search across journal entries.

↑ ↓ navigate ↵ open esc close

How Browsers Work · Part 22 — Capstone 2: Profiling Internals End-to-End

Ghép mọi tầng nội bộ lại: đọc Performance panel và Perfetto, khoanh vùng jank theo process/thread/giai đoạn pipeline, rồi kiểm chứng bằng một quy trình có hệ thống.

6 MIN READ

Mười phần chuyên sâu vừa qua mở từng hộp đen: compositor, scheduling, V8, bộ nhớ, a11y, decode ảnh, threading, process model. Capstone cuối dạy kỹ năng buộc tất cả lại bằng profiling: khoanh một trang giật về process, thread và giai đoạn pipeline có bằng chứng mạnh nhất, rồi đo lại sau khi sửa.

1. Bản đồ tinh thần: jank xảy ra ở đâu?

Khi có vấn đề hiệu năng, hãy định vị nó trên kiến trúc đã học:

                ┌─ Network service (Phần 9) ── tải chậm, waterfall xấu
                │
Browser process ┤
                └─ GPU process / Viz ── raster/display composite chậm (Phần 13)

Renderer process
  ├─ Main thread ── JS dài, layout/style, forced reflow (Phần 5,7,15,16)
  ├─ Compositor thread ── scroll/transform (mượt hay rớt về main? Phần 14)
  └─ Raster/helper threads ── raster tile, decode ảnh (Phần 13,19)

Đây là bản đồ phía client; TTFB/server, OS scheduling, driver và thiết bị vẫn có thể là gốc. Câu hỏi của profiler là: độ trễ nằm ở process/thread/giai đoạn nào, hay ở ngoài browser client?

2. Đọc Performance panel theo tầng

DevTools → Performance → record đúng interaction. Track/label đổi theo phiên bản Chrome và capture settings; bảng sau tập trung vào tín hiệu ổn định hơn tên UI:

TrackTương ứngTìm gì
Mainluồng chính rendererlong task (>50ms), function stack, style/layout/paint
Networkrequest qua network servicequeueing, TTFB, download và initiator
Timings / Interactions / Layout shiftsmốc UXLCP/INP phases, shift cluster, event timing
Frames / screenshotsoutput thị giácframe dài/rớt và hình ảnh tương ứng
Compositor/Raster/GPU (khi trace expose)pipeline ngoài maintile/raster/composite; system trace cho chi tiết đầy đủ hơn

Trong theme mặc định, category thường có màu sau; hãy đọc event name + stack + duration, vì màu/UI không phải API ổn định:

Vàng   = Scripting (JS, gọi hàm)        → nghi V8 / long task
Tím    = Rendering (style + layout)     → nghi forced reflow / layout thrash
Xanh lá= Painting                       → nghi paint/raster input nặng

3. Bốn loại jank & cách nhận diện

① JS long task chặn luồng chính
   Dấu hiệu: khối VÀNG dài, cờ "Long task" đỏ, INP cao.
   Soi: Bottom-Up/Call Tree tìm hàm tốn nhất; chỉ đào deopt/IC nếu hotspot thật sự dẫn tới đó. → Phần 7,16
   Sửa: chia nhỏ (`await scheduler.yield()` khi hỗ trợ), đẩy compute phù hợp sang worker (Phần 20).

② Forced synchronous layout (reflow)
   Dấu hiệu: khối TÍM kèm cảnh báo "Forced reflow", thường trong vòng lặp.
   Soi: stack trỏ về đọc offsetWidth/getBoundingClientRect sau khi ghi style.
   Sửa: gom đọc rồi gom ghi (Phần 5,15).

③ Layer/paint nặng hoặc layer explosion
   Dấu hiệu: paint/raster dài; Layers/Rendering tools cho thấy promotion hoặc vùng paint bất thường.
   Soi: bật "Layer borders" + Rendering pane "Paint flashing".
   Sửa: giảm `will-change`; ưu tiên property có fast path và xác nhận lại bằng trace (Phần 13).

④ Scroll rớt về main thread
   Dấu hiệu: cuộn giật khi JS bận; "Scrolling on main thread".
   Soi: kiểm tra non-passive wheel/touch listener.
   Sửa: `{ passive: true }` khi không huỷ input; dùng scroll-driven animation cho property compositor-friendly (Phần 14).

4. Công cụ chuyên sâu hơn DevTools

Performance panel đủ cho đa số bug web. Khi cần nhìn liên process (renderer + Viz/GPU + browser/network service cùng lúc), dùng Chrome system trace và mở bằng Perfetto:

Chrome system trace  →  Perfetto UI
  → trace nhiều process & thread trên cùng timeline
  → thấy commit từ main → compositor, raster threads, GPU draw
  → đo chính xác round-trip giữa các thread (vd input → composite)

chrome://tracing vẫn hữu ích trong flow debug Chromium, còn Perfetto là viewer/phân tích hiện đại. Trace có thể chứa URL, title và dữ liệu nhạy cảm; record ngắn, đóng tab không liên quan và kiểm tra trước khi chia sẻ.

Các pane bổ trợ trong DevTools:

  • Performance → Insights: forced reflow, INP phases, LCP/CLS và các culprit trực tiếp trên timeline.
  • Rendering pane: Paint flashing, Layer borders, Scrolling performance issues, FPS meter (tuỳ phiên bản).
  • Layers tool: cây composited layer/reason ở mức Chromium; đừng quy mỗi layer thành một bitmap VRAM nguyên khối (Phần 13).
  • Performance Monitor: CPU/JS heap/DOM node/listener theo thời gian thực (bắt rò rỉ Phần 17).
  • Memory: heap snapshot (Phần 17).

5. Quy trình điều tra có hệ thống

Đừng tối ưu mò. Theo vòng lặp này:

1. ĐO trước     → record Performance, ghi device/throttle/scenario + số baseline
2. KHOANH VÙNG  → jank ở thread nào? giai đoạn nào? (mục 1–3)
3. TÌM GỐC      → Bottom-Up/Call Tree/retainer path → hàm/dòng cụ thể
4. SỬA 1 THỨ    → đổi đúng một biến số
5. ĐO LẠI       → so với baseline; giữ nếu tốt hơn, revert nếu không
6. LẶP          → tới khi đạt ngân sách (budget)

Gắn số đo vào Core Web Vitals để ưu tiên outcome: LCP (server/resource/render — Phần 9,19,5), INP (input delay + processing + presentation delay — Phần 7,15), CLS (layout shift — Phần 5,19). Lab trace giải thích cơ chế của một phiên; field/RUM cho biết user thật gặp nó bao nhiêu.

Nguyên tắc: đo trước khi sửa, đo lại sau khi sửa. Profiler cũng có overhead, sampling và phần dữ liệu không expose; tái hiện nhiều lần, giữ điều kiện so sánh và đối chiếu field data.

6. Toàn series — bản đồ “How Browsers Work”

Mười hai phần nền tảng + mười phần chuyên sâu hợp thành bức tranh hoàn chỉnh:

NỀN TẢNG (1–12)
  1  Mô hình tinh thần        7  Event loop
  2  URL → pixel              8  Memory & GC
  3  HTML parsing → DOM       9  Networking
  4  CSS → CSSOM             10  Storage
  5  Rendering pipeline      11  Security model
  6  JS engine (V8)          12  Capstone 1

CHUYÊN SÂU (13–22)
  13 GPU & compositor        18 Accessibility tree
  14 Scrolling internals     19 Image/media decode
  15 Frame scheduling        20 Threading (Workers/SAB)
  16 V8 tiers & deopt        21 Process model & BFCache
  17 Memory leak hunting     22 Capstone 2 — profiling (bài này)

7. Tóm tắt

  • Định vị độ trễ theo process/thread/giai đoạn, nhưng luôn chừa giả thuyết server, OS, driver và thiết bị.
  • Performance panel: ưu tiên event name/stack/duration và Insights; track compositor/GPU chi tiết phụ thuộc capture, system trace cho góc nhìn đầy đủ hơn.
  • Bốn loại jank kinh điển: JS long task, forced reflow, layer/paint nặng, scroll rớt về main — mỗi loại có dấu hiệu và cách sửa riêng.
  • Perfetto/Chrome system trace cho góc nhìn liên process; Insights/Rendering/Layers/Memory bổ sung bằng chứng từng tầng.
  • Theo quy trình đo → khoanh vùng → tìm gốc → sửa một thứ → đo lại; gắn vào Core Web Vitals và đặt ngân sách trước.
  • Đây là điểm hội tụ của cả series: hiểu nội bộ trình duyệt biến profiling từ đoán mò thành chẩn đoán có cơ sở.

Cảm ơn bạn đã đi hết 22 phần “How Browsers Work”. Giờ khi một trang chậm, bạn không còn thấy một hộp đen — bạn có bản đồ process/thread/pipeline, biết bằng chứng nào cần thu và cũng biết khi nào phải nhìn ra ngoài browser.