Tìm hiểu về cách đo lường ảnh động, cách suy nghĩ về khung ảnh động và độ mượt tổng thể của trang.
Có thể bạn đã gặp phải tình trạng các trang "giật" hoặc "đơ" trong khi cuộn hoặc ảnh động. Chúng tôi muốn nói rằng những trải nghiệm này không mượt mà. Để giải quyết các loại vấn đề này, nhóm Chrome đã nỗ lực bổ sung thêm tính năng hỗ trợ cho công cụ trong phòng thí nghiệm để phát hiện ảnh động, cũng như cải thiện liên tục quy trình chẩn đoán kết xuất trong Chromium.
Chúng tôi muốn chia sẻ một số tiến trình gần đây, cung cấp hướng dẫn cụ thể về công cụ và thảo luận về các ý tưởng cho các chỉ số về độ mượt của ảnh động trong tương lai. Như mọi khi, chúng tôi rất mong nhận được ý kiến phản hồi của bạn.
Bài đăng này sẽ đề cập đến 3 chủ đề chính:
- Xem nhanh ảnh động và khung ảnh động.
- Suy nghĩ hiện tại của chúng tôi về việc đo lường độ mượt mà tổng thể của ảnh động.
- Một số đề xuất thực tế để bạn tận dụng trong công cụ của phòng thí nghiệm ngay hôm nay.
Ảnh động là gì?
Ảnh động giúp nội dung trở nên sống động! Bằng cách di chuyển nội dung, đặc biệt là để phản hồi các hoạt động tương tác của người dùng, ảnh động có thể giúp trải nghiệm trở nên tự nhiên, dễ hiểu và thú vị hơn.
Tuy nhiên, việc triển khai hoạt ảnh không tốt hoặc chỉ thêm quá nhiều hoạt ảnh có thể làm giảm trải nghiệm và khiến trải nghiệm đó trở nên không thú vị chút nào. Có thể tất cả chúng ta đều đã tương tác với một giao diện chỉ thêm quá nhiều hiệu ứng chuyển đổi "hữu ích", nhưng thực sự lại gây khó chịu cho trải nghiệm khi hiệu ứng hoạt động kém. Do đó, một số người dùng thực sự có thể thích giảm chuyển động, đây là lựa chọn ưu tiên của người dùng mà bạn nên tuân thủ.
Ảnh động hoạt động như thế nào?
Tóm lại, quy trình kết xuất bao gồm một số giai đoạn tuần tự:
- Kiểu: Tính toán các kiểu áp dụng cho các phần tử.
- Bố cục: Tạo hình học và vị trí cho từng phần tử.
- Paint (Vẽ): Điền các pixel cho từng phần tử vào các lớp.
- Composite (Hợp nhất): Vẽ các lớp lên màn hình.
Mặc dù có nhiều cách để xác định ảnh động, nhưng về cơ bản, tất cả đều hoạt động thông qua một trong những cách sau:
- Điều chỉnh thuộc tính bố cục.
- Điều chỉnh thuộc tính paint.
- Điều chỉnh các thuộc tính composite.
Vì các giai đoạn này theo tuần tự, nên bạn cần xác định ảnh động theo các thuộc tính ở phía dưới quy trình. Quá trình cập nhật càng diễn ra sớm thì chi phí càng lớn và khả năng diễn ra suôn sẻ càng thấp. (Xem phần Hiệu suất kết xuất để biết thêm thông tin chi tiết.)
Mặc dù việc tạo ảnh động cho các thuộc tính bố cục có thể thuận tiện, nhưng bạn sẽ phải trả một số chi phí, ngay cả khi các chi phí đó không rõ ràng ngay lập tức. Bạn nên xác định ảnh động theo các thay đổi về thuộc tính tổng hợp bất cứ khi nào có thể.
Việc xác định ảnh động CSS khai báo hoặc sử dụng Ảnh động web và đảm bảo bạn tạo ảnh động cho các thuộc tính tổng hợp là bước đầu tiên quan trọng để đảm bảo ảnh động mượt mà và hiệu quả. Tuy nhiên, điều này vẫn không đảm bảo độ mượt mà vì ngay cả ảnh động web hiệu quả cũng có giới hạn về hiệu suất. Đó là lý do bạn luôn phải đo lường!
Khung ảnh động là gì?
Nội dung cập nhật đối với hình ảnh đại diện của một trang sẽ mất thời gian để xuất hiện. Một thay đổi về hình ảnh sẽ dẫn đến một khung ảnh động mới, cuối cùng sẽ được kết xuất trên màn hình của người dùng.
Hiển thị nội dung cập nhật theo một số khoảng thời gian, vì vậy, nội dung cập nhật hình ảnh được phân thành lô. Nhiều màn hình cập nhật theo một khoảng thời gian cố định, chẳng hạn như 60 lần/giây (tức là 60 Hz). Một số màn hình hiện đại hơn có thể cung cấp tốc độ làm mới cao hơn (90–120 Hz đang trở nên phổ biến). Thông thường, các màn hình này có thể chủ động điều chỉnh giữa các tốc độ làm mới khi cần hoặc thậm chí cung cấp tốc độ khung hình biến đổi hoàn toàn.
Mục tiêu của mọi ứng dụng, chẳng hạn như trò chơi hoặc trình duyệt, là xử lý tất cả các bản cập nhật hình ảnh theo lô này và tạo một khung ảnh động hoàn chỉnh về mặt hình ảnh trong thời hạn, mỗi lần. Xin lưu ý rằng mục tiêu này hoàn toàn khác với các tác vụ quan trọng khác của trình duyệt, chẳng hạn như tải nội dung từ mạng nhanh chóng hoặc thực thi các tác vụ JavaScript một cách hiệu quả.
Có thể đến một lúc nào đó, bạn sẽ khó có thể hoàn tất tất cả nội dung cập nhật hình ảnh trong thời hạn mà màn hình chỉ định. Khi điều này xảy ra, trình duyệt sẽ thả một khung. Màn hình không chuyển sang màu đen mà chỉ lặp lại chính nó. Bạn sẽ thấy bản cập nhật hình ảnh tương tự lâu hơn một chút – cùng một khung ảnh động được hiển thị ở cơ hội khung hình trước đó.
Điều này thực sự thường xảy ra! Thậm chí, bạn có thể không nhận thấy được sự khác biệt, đặc biệt là đối với nội dung tĩnh hoặc nội dung giống tài liệu, thường thấy trên nền tảng web. Tình trạng bỏ khung hình chỉ trở nên rõ ràng khi có các bản cập nhật hình ảnh quan trọng, chẳng hạn như ảnh động, chúng ta cần có một luồng cập nhật ảnh động ổn định để hiển thị chuyển động mượt mà.
Điều gì ảnh hưởng đến khung ảnh động?
Nhà phát triển web có thể tác động rất lớn đến khả năng của trình duyệt trong việc hiển thị và trình bày nội dung cập nhật hình ảnh một cách nhanh chóng và hiệu quả!
Một số ví dụ:
- Sử dụng nội dung quá lớn hoặc tốn nhiều tài nguyên để giải mã nhanh trên thiết bị mục tiêu.
- Sử dụng quá nhiều lớp yêu cầu quá nhiều bộ nhớ GPU.
- Xác định các kiểu CSS hoặc ảnh động trên web quá phức tạp.
- Sử dụng các mẫu thiết kế chống lại việc tắt tính năng tối ưu hoá kết xuất nhanh.
- Quá nhiều công việc JS trên luồng chính, dẫn đến các tác vụ dài chặn việc cập nhật hình ảnh.
Nhưng làm thế nào để bạn biết thời điểm một khung ảnh động đã bỏ lỡ thời hạn và gây ra tình trạng bị bỏ khung?
Một phương pháp có thể áp dụng là sử dụng tính năng thăm dò ý kiến requestAnimationFrame()
, tuy nhiên phương pháp này có một số nhược điểm. requestAnimationFrame()
hoặc "rAF", cho trình duyệt biết rằng bạn muốn thực hiện ảnh động và yêu cầu cơ hội để thực hiện việc này trước giai đoạn vẽ tiếp theo của quy trình kết xuất. Nếu hàm gọi lại không được gọi tại thời điểm bạn mong đợi, thì điều đó có nghĩa là một lượt vẽ không được thực thi và một hoặc nhiều khung hình đã bị bỏ qua. Bằng cách thăm dò ý kiến và tính tần suất gọi rAF, bạn có thể tính toán một loại chỉ số "khung hình/giây" (FPS).
let frameTimes = [];
function pollFramesPerSecond(now) {
frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
requestAnimationFrame(pollFramesPerSecond);
console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);
Bạn không nên sử dụng tính năng thăm dò ý kiến requestAnimationFrame()
vì một số lý do sau:
- Mỗi tập lệnh phải thiết lập vòng thăm dò ý kiến riêng.
- Lỗi này có thể chặn đường dẫn quan trọng.
- Ngay cả khi hoạt động thăm dò ý kiến rAF diễn ra nhanh chóng, hoạt động này vẫn có thể ngăn
requestIdleCallback()
lên lịch các khối thời gian rảnh dài khi được sử dụng liên tục (các khối vượt quá một khung hình). - Tương tự, việc thiếu các khối thời gian rảnh dài sẽ khiến trình duyệt không thể lên lịch các tác vụ khác chạy trong thời gian dài (chẳng hạn như thu thập rác lâu hơn và các tác vụ dự đoán hoặc trong nền khác).
- Nếu bật và tắt tính năng thăm dò ý kiến, bạn sẽ bỏ lỡ các trường hợp vượt quá ngân sách khung hình.
- Tính năng thăm dò ý kiến sẽ báo cáo kết quả dương tính giả trong trường hợp trình duyệt đang sử dụng tần suất cập nhật biến thiên (ví dụ: do trạng thái nguồn hoặc chế độ hiển thị).
- Và quan trọng nhất là tính năng này không thực sự ghi lại tất cả các loại cập nhật ảnh động!
Quá nhiều công việc trên luồng chính có thể ảnh hưởng đến khả năng xem khung ảnh động. Hãy xem Mẫu giật để biết cách ảnh động do rAF điều khiển, khi có quá nhiều công việc trên luồng chính (chẳng hạn như bố cục), sẽ dẫn đến việc bỏ khung hình và ít lệnh gọi lại rAF hơn, đồng thời giảm FPS.
Khi luồng chính bị tắc nghẽn, nội dung cập nhật hình ảnh sẽ bắt đầu bị giật. Đó là hiện tượng giật!
Nhiều công cụ đo lường đã tập trung nhiều vào khả năng luồng chính tạo ra kết quả kịp thời và để các khung ảnh động chạy trơn tru. Nhưng đó chưa phải là tất cả! Hãy xem ví dụ sau đây:
Video ở trên cho thấy một trang định kỳ chèn các tác vụ dài vào luồng chính. Những tác vụ dài này hoàn toàn làm hỏng khả năng của trang trong việc cung cấp một số loại nội dung cập nhật hình ảnh nhất định. Bạn có thể thấy ở góc trên cùng bên trái, requestAnimationFrame()
đã giảm tương ứng từ FPS được báo cáo xuống 0.
Tuy nhiên, mặc dù có những tác vụ dài như vậy, trang vẫn tiếp tục cuộn một cách mượt mà. Điều này là do trên các trình duyệt hiện đại, việc cuộn thường được tạo luồng, hoàn toàn do trình kết hợp điều khiển.
Đây là ví dụ đồng thời chứa nhiều khung hình bị bỏ qua trên luồng chính, nhưng vẫn có nhiều khung hình cuộn được phân phối thành công trên luồng trình kết hợp. Sau khi hoàn tất tác vụ dài, bản cập nhật sơn luồng chính sẽ không có thay đổi nào về mặt hình ảnh. Tính năng thăm dò ý kiến rAF đề xuất giảm khung xuống 0, nhưng về mặt hình ảnh, người dùng sẽ không thể nhận thấy sự khác biệt!
Đối với các khung ảnh động, câu chuyện không đơn giản như vậy.
Khung ảnh động: Thông tin cập nhật quan trọng
Ví dụ trên cho thấy rằng câu chuyện không chỉ dừng lại ở requestAnimationFrame()
.
Vậy khi nào thì bản cập nhật ảnh động và khung ảnh động trở nên quan trọng? Sau đây là một số tiêu chí mà chúng tôi đang cân nhắc và rất mong nhận được ý kiến phản hồi của bạn:
- Cập nhật luồng chính và luồng trình kết hợp
- Thiếu bản cập nhật sơn
- Phát hiện ảnh động
- Chất lượng so với số lượng
Cập nhật luồng chính và luồng trình kết hợp
Nội dung cập nhật khung ảnh động không phải là boolean. Không phải trường hợp khung hình chỉ có thể được thả hoàn toàn hoặc hiển thị hoàn toàn. Có nhiều lý do khiến một khung ảnh động có thể được hiển thị một phần. Nói cách khác, trang này có thể đồng thời có một số nội dung cũ trong khi cũng có một số nội dung cập nhật mới về hình ảnh được trình bày.
Ví dụ phổ biến nhất về điều này là khi trình duyệt không thể tạo bản cập nhật luồng chính mới trong thời hạn khung hình nhưng có bản cập nhật luồng trình kết hợp mới (chẳng hạn như ví dụ về cuộn theo luồng ở trên).
Một lý do quan trọng khiến bạn nên sử dụng ảnh động khai báo để tạo ảnh động cho các thuộc tính tổng hợp là việc này cho phép luồng trình kết hợp điều khiển hoàn toàn ảnh động ngay cả khi luồng chính đang bận. Các loại ảnh động này có thể tiếp tục tạo bản cập nhật hình ảnh một cách hiệu quả và song song.
Mặt khác, có thể có trường hợp bản cập nhật luồng chính cuối cùng cũng có sẵn để trình bày, nhưng chỉ sau khi bỏ lỡ một số thời hạn khung. Tại đây, trình duyệt sẽ có một số bản cập nhật mới, nhưng có thể không phải là bản cập nhật mới nhất.
Nói chung, chúng tôi coi các khung chứa một số nội dung cập nhật hình ảnh mới, nhưng không phải tất cả nội dung cập nhật hình ảnh mới, là khung một phần. Khung hình một phần khá phổ biến. Lý tưởng nhất là các bản cập nhật một phần ít nhất sẽ bao gồm các bản cập nhật hình ảnh quan trọng nhất, chẳng hạn như ảnh động, nhưng điều đó chỉ có thể xảy ra nếu ảnh động được điều khiển bằng luồng trình kết hợp.
Thiếu bản cập nhật sơn
Một loại cập nhật một phần khác là khi nội dung nghe nhìn như hình ảnh chưa hoàn tất quá trình giải mã và quét đường quét kịp thời để hiển thị khung hình.
Hoặc ngay cả khi một trang hoàn toàn tĩnh, trình duyệt vẫn có thể bị chậm trễ trong việc hiển thị nội dung cập nhật hình ảnh khi cuộn nhanh. Đó là do các bản trình bày pixel của nội dung nằm ngoài khung nhìn hiển thị có thể bị loại bỏ để tiết kiệm bộ nhớ GPU. Cần có thời gian để kết xuất các pixel và có thể mất nhiều thời gian hơn một khung hình để kết xuất mọi thứ sau một thao tác cuộn lớn, chẳng hạn như hất ngón tay. Hiện tượng này thường được gọi là hiệu ứng ô bàn cờ.
Với mỗi cơ hội kết xuất khung hình, bạn có thể theo dõi xem có bao nhiêu nội dung cập nhật hình ảnh mới nhất thực sự xuất hiện trên màn hình. Việc đo lường khả năng thực hiện việc này trên nhiều khung hình (hoặc thời gian) được gọi chung là tốc độ khung hình.
Nếu GPU thực sự bị nghẽn, trình duyệt (hoặc nền tảng) thậm chí có thể bắt đầu điều tiết tốc độ mà trình duyệt cố gắng cập nhật hình ảnh, do đó làm giảm tốc độ khung hình hiệu quả. Mặc dù về mặt kỹ thuật, điều đó có thể làm giảm số lượng bản cập nhật khung hình bị bỏ qua, nhưng về mặt hình ảnh, nó vẫn sẽ xuất hiện dưới dạng tốc độ khung hình thấp hơn.
Tuy nhiên, không phải tất cả các loại tốc độ khung hình thấp đều là xấu. Nếu trang chủ yếu ở trạng thái rảnh và không có ảnh động đang hoạt động, thì tốc độ khung hình thấp cũng hấp dẫn về mặt hình ảnh như tốc độ khung hình cao (và có thể tiết kiệm pin!).
Vậy khi nào thì tốc độ khung hình lại quan trọng?
Phát hiện ảnh động
Thông lượng khung hình cao đặc biệt quan trọng trong những khoảng thời gian có ảnh động quan trọng. Các loại ảnh động khác nhau sẽ phụ thuộc vào nội dung cập nhật hình ảnh từ một luồng cụ thể (chính, trình kết hợp hoặc trình chạy), vì vậy, nội dung cập nhật hình ảnh của ảnh động sẽ phụ thuộc vào việc luồng đó cung cấp nội dung cập nhật trong thời hạn. Chúng ta nói rằng một luồng nhất định ảnh hưởng đến độ mượt mà bất cứ khi nào có ảnh động đang hoạt động phụ thuộc vào bản cập nhật luồng đó.
Một số loại ảnh động dễ xác định và phát hiện hơn so với các loại khác. Ảnh động khai báo hoặc ảnh động do người dùng nhập dễ xác định hơn so với ảnh động do JavaScript điều khiển được triển khai dưới dạng nội dung cập nhật định kỳ cho các thuộc tính kiểu ảnh động.
Ngay cả với requestAnimationFrame()
, bạn cũng không phải lúc nào cũng có thể giả định rằng mọi lệnh gọi rAF đều tạo ra một bản cập nhật hình ảnh hoặc ảnh động. Ví dụ: việc sử dụng tính năng thăm dò ý kiến rAF chỉ để theo dõi tốc độ khung hình (như minh hoạ ở trên) sẽ không ảnh hưởng đến kết quả đo lường độ mượt mà vì không có nội dung cập nhật hình ảnh nào.
Chất lượng so với số lượng
Cuối cùng, việc phát hiện ảnh động và cập nhật khung ảnh động vẫn chỉ là một phần của câu chuyện vì chỉ ghi lại số lượng cập nhật ảnh động chứ không phải chất lượng.
Ví dụ: bạn có thể thấy tốc độ khung hình ổn định ở mức 60 fps khi xem video. Về mặt kỹ thuật, video này hoàn toàn mượt mà, nhưng bản thân video có thể có tốc độ bit thấp hoặc gặp vấn đề về bộ nhớ đệm mạng. Điều này không được ghi lại trực tiếp bằng các chỉ số về độ mượt của ảnh động, nhưng vẫn có thể gây khó chịu cho người dùng.
Hoặc một trò chơi tận dụng <canvas>
(có thể thậm chí sử dụng các kỹ thuật như canvas ngoài màn hình để đảm bảo tốc độ khung hình ổn định) có thể mượt mà hoàn hảo về mặt kỹ thuật đối với các khung ảnh động, trong khi không tải được các thành phần trò chơi chất lượng cao vào cảnh hoặc hiển thị các cấu phần kết xuất.
Và tất nhiên, một trang web có thể chỉ có một số ảnh động thực sự xấu 🙂
Tôi đoán là những chiếc xe này khá ngầu vào thời điểm đó!
Trạng thái của một khung ảnh động
Vì các khung hình có thể được hiển thị một phần hoặc bị bỏ khung hình theo cách không ảnh hưởng đến độ mượt mà, nên chúng tôi đã bắt đầu xem mỗi khung hình có một điểm số về độ hoàn chỉnh hoặc độ mượt mà.
Dưới đây là phổ các cách chúng ta diễn giải trạng thái của một khung ảnh động, được sắp xếp từ trường hợp tốt nhất đến trường hợp tệ nhất:
Không cần cập nhật | Thời gian rảnh, lặp lại khung trước đó. |
Đã trình bày đầy đủ | Nội dung cập nhật luồng chính đã được thực hiện trong thời hạn hoặc không có nội dung cập nhật luồng chính nào được mong muốn. |
Đã trình bày một phần | Chỉ có trình tổng hợp; bản cập nhật luồng chính bị trì hoãn không có thay đổi về hình ảnh. |
Đã trình bày một phần | Chỉ có trình tổng hợp; luồng chính đã có bản cập nhật hình ảnh, nhưng bản cập nhật đó không bao gồm ảnh động ảnh hưởng đến độ mượt. |
Đã trình bày một phần | Chỉ có trình tổng hợp; luồng chính đã có bản cập nhật hình ảnh ảnh hưởng đến độ mượt mà, nhưng một khung hình cũ đã đến và được sử dụng. |
Đã trình bày một phần | Chỉ có trình kết hợp; không có bản cập nhật chính mong muốn và bản cập nhật trình kết hợp có ảnh động ảnh hưởng đến độ mượt. |
Đã trình bày một phần | Chỉ có trình kết hợp nhưng bản cập nhật trình kết hợp không có ảnh động ảnh hưởng đến độ mượt. |
Rớt khung hình | Không có thông tin cập nhật. Không có bản cập nhật trình kết hợp nào được mong muốn và phần chính bị trễ. |
Rớt khung hình | Chúng tôi muốn cập nhật trình tổng hợp nhưng đã bị trì hoãn. |
Khung hình cũ | Một bản cập nhật đã được yêu cầu, bản cập nhật này do trình kết xuất tạo ra, nhưng GPU vẫn chưa hiển thị bản cập nhật đó trước thời hạn vsync. |
Bạn có thể biến các trạng thái này thành một số điểm. Và có lẽ một cách để diễn giải điểm số này là xem xét điểm số này là xác suất mà người dùng có thể quan sát được. Một khung hình bị bỏ có thể không dễ nhận thấy, nhưng một chuỗi nhiều khung hình bị bỏ ảnh hưởng đến độ mượt mà của một hàng thì chắc chắn là có!
Tổng hợp tất cả: Chỉ số Tỷ lệ phần trăm khung hình bị bỏ qua
Đôi khi, bạn có thể cần phải tìm hiểu sâu về trạng thái của từng khung ảnh động, nhưng cũng hữu ích khi chỉ cần chỉ định một điểm số "xem nhanh" nhanh chóng cho một trải nghiệm.
Vì các khung hình có thể được hiển thị một phần và vì ngay cả khi bỏ qua hoàn toàn các bản cập nhật khung hình cũng có thể không thực sự ảnh hưởng đến độ mượt mà, nên chúng ta không nên chỉ tập trung vào việc đếm khung hình mà nên tập trung vào mức độ trình duyệt không thể cung cấp các bản cập nhật hoàn chỉnh về mặt hình ảnh khi cần thiết.
Mô hình tinh thần phải chuyển từ:
- Khung hình/giây, thành
- Phát hiện các bản cập nhật ảnh động bị thiếu và quan trọng để
- Tỷ lệ phần trăm đã giảm trong một khoảng thời gian nhất định.
Điều quan trọng là: tỷ lệ thời gian chờ các bản cập nhật quan trọng. Chúng tôi cho rằng điều này phù hợp với cách người dùng trải nghiệm sự mượt mà của nội dung web trong thực tế. Cho đến nay, chúng ta đã sử dụng các chỉ số sau đây làm bộ chỉ số ban đầu:
- Tỷ lệ phần trăm bị bỏ qua trung bình: đối với tất cả khung ảnh động không ở trạng thái rảnh trong toàn bộ tiến trình
- Trường hợp tệ nhất về Tỷ lệ khung hình bị bỏ qua: được đo lường trong khoảng thời gian trượt 1 giây.
- Phân vị thứ 95 của Tỷ lệ khung hình bị bỏ qua: được đo lường trong khoảng thời gian trượt 1 giây.
Bạn có thể tìm thấy các điểm số này trong một số công cụ dành cho nhà phát triển Chrome hiện nay. Mặc dù các chỉ số này chỉ tập trung vào tổng lưu lượng khung hình, nhưng chúng tôi cũng đang đánh giá các yếu tố khác, chẳng hạn như độ trễ khung hình.
Hãy tự mình thử trong công cụ dành cho nhà phát triển!
HUD hiệu suất
Chromium có một HUD hiệu suất gọn gàng ẩn sau một cờ (chrome://flags/#show-performance-metrics-hud
). Trong đó, bạn có thể tìm thấy điểm số trực tiếp cho các chỉ số như Các chỉ số quan trọng về trang web, cũng như một số định nghĩa thử nghiệm để tạo ảnh động mượt mà dựa trên Tỷ lệ khung hình bị bỏ qua theo thời gian.
Số liệu thống kê kết xuất khung hình
Bật "Frame Rendering Stats" (Thống kê kết xuất khung) trong DevTools thông qua phần cài đặt Kết xuất để xem chế độ xem trực tiếp của các khung ảnh động mới. Các khung này được mã hoá bằng màu để phân biệt các bản cập nhật một phần với các bản cập nhật khung bị bỏ hoàn toàn. Tốc độ khung hình được báo cáo chỉ dành cho các khung hình được hiển thị đầy đủ.
Trình xem khung hình trong bản ghi hồ sơ hiệu suất của DevTools
Bảng điều khiển Hiệu suất trong DevTools từ lâu đã có Trình xem khung. Tuy nhiên, cách này đã không còn phù hợp với cách hoạt động thực tế của quy trình kết xuất hiện đại. Gần đây, chúng tôi đã cải thiện rất nhiều, ngay cả trong Chrome Canary mới nhất. Chúng tôi cho rằng điều này sẽ giúp dễ dàng gỡ lỗi ảnh động hơn rất nhiều.
Hôm nay, bạn sẽ thấy các khung hình trong trình xem khung hình được căn chỉnh tốt hơn với các ranh giới vsync và được mã hoá bằng màu dựa trên trạng thái. Hiện tại, chúng tôi vẫn chưa có hình ảnh trực quan đầy đủ cho tất cả các sắc thái được nêu trên, nhưng chúng tôi dự định sẽ bổ sung thêm trong thời gian sắp tới.
Theo dõi trên Chrome
Cuối cùng, với tính năng Theo dõi của Chrome, một công cụ phù hợp để tìm hiểu sâu về thông tin chi tiết, bạn có thể ghi lại dấu vết "Hiển thị nội dung web" thông qua Giao diện người dùng Perfetto (hoặc about:tracing
) mới và tìm hiểu sâu về quy trình đồ hoạ của Chrome. Đây có thể là một nhiệm vụ khó khăn, nhưng gần đây, chúng tôi đã thêm một số tính năng vào Chromium để giúp bạn dễ dàng thực hiện việc này. Bạn có thể xem thông tin tổng quan về nội dung có sẵn trong tài liệu Vòng đời của khung.
Thông qua các sự kiện theo dõi, bạn có thể xác định chắc chắn:
- Ảnh động nào đang chạy (sử dụng các sự kiện có tên
TrackerValidation
). - Lấy dòng thời gian chính xác của các khung ảnh động (sử dụng các sự kiện có tên
PipelineReporter
). - Đối với các bản cập nhật ảnh động bị giật, hãy tìm hiểu chính xác điều gì đang ngăn ảnh động chạy nhanh hơn (sử dụng bảng chi tiết sự kiện trong các sự kiện
PipelineReporter
). - Đối với ảnh động do đầu vào điều khiển, hãy xem thời gian cần thiết để cập nhật hình ảnh (sử dụng các sự kiện có tên
EventLatency
).
Bước tiếp theo
Sáng kiến Các chỉ số quan trọng về trang web nhằm cung cấp chỉ số và hướng dẫn để tạo trải nghiệm tuyệt vời cho người dùng trên web. Các chỉ số dựa trên phòng thí nghiệm như Tổng thời gian chặn (TBT) rất quan trọng để phát hiện và chẩn đoán các vấn đề tiềm ẩn về khả năng tương tác. Chúng tôi dự định thiết kế một chỉ số tương tự dựa trên phòng thí nghiệm để đo lường độ mượt của ảnh động.
Chúng tôi sẽ thông báo cho bạn khi tiếp tục triển khai các ý tưởng để thiết kế một chỉ số toàn diện dựa trên dữ liệu khung ảnh động riêng lẻ.
Trong tương lai, chúng tôi cũng muốn thiết kế các API cho phép đo lường hiệu suất của ảnh động một cách hiệu quả cho người dùng thực tế trong trường thực cũng như trong phòng thí nghiệm. Hãy chú ý theo dõi thông tin cập nhật trên đó nhé!
Phản hồi
Chúng tôi rất vui mừng về tất cả các điểm cải tiến gần đây và các công cụ dành cho nhà phát triển đã được cung cấp trong Chrome để đo lường độ mượt của ảnh động. Vui lòng dùng thử các công cụ này, đo điểm chuẩn cho ảnh động và cho chúng tôi biết kết quả!
Bạn có thể gửi ý kiến phản hồi đến nhóm Google web-vitals-feedback với dòng tiêu đề là "[Smoothness Metrics]" (Chỉ số về độ mượt). Chúng tôi rất mong nhận được ý kiến của bạn!