Cần có ý kiến phản hồi của nhà phát triển – Frame Timing API

Trong vài năm qua, trình duyệt đã có những bước tiến lớn về hiệu suất kết xuất, đặc biệt là trên thiết bị di động. Trước đây, bạn không có hy vọng đạt được tốc độ khung hình mượt mà cho bất kỳ nội dung phức tạp nào từ xa, nhưng giờ đây, ít nhất bạn cũng có thể đạt được điều đó nếu cẩn thận.

Tuy nhiên, đối với hầu hết chúng ta, có sự khác biệt giữa những gì chúng ta có thể kiểm thử một cách hợp lý trên thiết bị của riêng mình và những gì người dùng trải nghiệm. Nếu không có tốc độ 60 khung hình/giây mượt mà, trải nghiệm của họ sẽ bị ảnh hưởng và cuối cùng họ sẽ chuyển sang nơi khác, khiến chúng ta chịu thiệt hại. Rất may, W3C đang thảo luận về một API mới có thể giúp chúng ta xem những gì người dùng nhìn thấy: Frame Timing API (API Thời gian kết xuất khung hình).

Gần đây, Jake Archibald và tôi đã quay một video tổng quan về API này. Nếu bạn thích xem hơn là đọc, hãy xem video sau:

Cách sử dụng Frame Timing API

Chắc chắn bạn có thể làm được nhiều việc với Frame Timing API, và quan trọng là bạn có thể đo lường những điều quan trọng đối với bạn và dự án của bạn. Tuy nhiên, sau đây là một số ý tưởng:

  • Theo dõi số khung hình/giây của ảnh động JavaScript và CSS.
  • Theo dõi độ mượt mà của thao tác cuộn trang (hoặc có thể là danh sách cuộn vô hạn tiện lợi mà bạn có).
  • Tự động giảm quy mô hiệu ứng showbiz dựa trên mức tải hiện tại của thiết bị.
  • Kiểm thử hồi quy trên các chỉ số hiệu suất trong thời gian chạy.

Quảng cáo chiêu hàng cô đọng

Dưới đây là giao diện hiện tại của API trong thông số kỹ thuật: nhờ đó, bạn có thể lấy dữ liệu về thời gian của luồng trình kết xuất, nơi JavaScript, kiểu và bố cục chạy. (Bạn có thể đã nghe thấy luồng kết xuất được gọi là luồng chính; đó là cùng một luồng nhưng có tên khác.)

var rendererEvents = window.performance.getEntriesByType("renderer");

Mỗi bản ghi luồng trình kết xuất mà bạn nhận lại có dạng như sau:

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

Về cơ bản, mỗi bản ghi là một đối tượng chứa một số khung hình duy nhất, một dấu thời gian có độ phân giải cao cho thời điểm bắt đầu khung hình và một dấu thời gian khác cho biết thời gian CPU đã sử dụng. Với một mảng các giá trị này, bạn có thể xem từng giá trị startTime và tìm hiểu xem luồng chính có chạy ở tốc độ 60 khung hình/giây hay không; về cơ bản là "startTime của mỗi khung hình có tăng lên theo từng phần khoảng 16 mili giây không?"

Nhưng hơn thế nữa, bạn cũng nhận được cpuTime để biết liệu bạn có thoải mái nằm trong giới hạn 16 mili giây hay không hoặc liệu bạn có bị trễ hay không. Nếu cpuTime nằm ngay gần ranh giới 16 mili giây, thì sẽ không có nhiều không gian cho các hoạt động như thu gom rác và khi mức sử dụng CPU cao, mức tiêu thụ pin cũng sẽ cao hơn.

Ngoài luồng kết xuất, bạn cũng có thể lấy dữ liệu về thời gian luồng trình kết hợp, nơi diễn ra quá trình vẽ và kết hợp:

var compositeThreadEvents = window.performance.getEntriesByType("composite");

Mỗi sự kiện này cũng quay lại với một số khung nguồn mà bạn có thể sử dụng để liên kết lại với các sự kiện của luồng chính:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Do cách kết hợp thường hoạt động trong trình duyệt, có thể có một số bản ghi trong số này cho mỗi bản ghi luồng trình kết xuất, vì vậy, bạn có thể sử dụng sourceFrameNumber để liên kết các bản ghi đó lại với nhau. Ngoài ra, cũng có một số cuộc thảo luận về việc liệu có nên có thời gian CPU trong các bản ghi này hay không. Vì vậy, nếu bạn cảm thấy mạnh mẽ, hãy lên tiếng về các vấn đề trên GitHub.

Thông tin khác

API này chưa được cung cấp, nhưng hy vọng sẽ sớm được cung cấp. Trong thời gian chờ đợi, bạn có thể đọc và làm một số việc sau: