API Khung ảnh động dài (Lo-Af phát âm theo phong cách LoAF) là một bản cập nhật cho API Tác vụ dài để giúp bạn hiểu rõ hơn về các bản cập nhật giao diện người dùng (UI) bị chậm. Điều này có thể hữu ích khi xác định các khung ảnh động chậm có khả năng ảnh hưởng đến chỉ số Chỉ số quan trọng chính của trang web Tương tác với nội dung hiển thị tiếp theo (INP). Chỉ số này đo lường khả năng phản hồi hoặc xác định hiện tượng giật khác trên giao diện người dùng ảnh hưởng đến độ mượt.
Trạng thái của API
Sau bản dùng thử theo nguyên gốc từ Chrome 116 đến Chrome 122, API LoAF đã chuyển từ Chrome 123.
Thông tin cơ bản: Long Tasks API
API Long Animation Frames (Khung ảnh động dài) là một giải pháp thay thế cho Long Tasks API (API Tác vụ dài) hiện đã có trong Chrome một thời gian (kể từ Chrome 58). Đúng như tên gọi, Long Task API cho phép bạn theo dõi các tác vụ dài, tức là các tác vụ chiếm luồng chính trong 50 mili giây trở lên. Bạn có thể theo dõi các công việc dài bằng giao diện PerformanceLongTaskTiming
có PeformanceObserver
:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'longtask', buffered: true });
Các tác vụ dài có thể gây ra vấn đề về khả năng phản hồi. Nếu người dùng cố gắng tương tác với một trang (ví dụ: nhấp vào nút hoặc mở trình đơn) nhưng luồng chính đang xử lý một tác vụ dài, thì hoạt động tương tác của người dùng sẽ bị trì hoãn chờ tác vụ đó hoàn tất.
Để cải thiện khả năng phản hồi, thông thường, bạn nên chia nhỏ các tác vụ dài. Nếu mỗi nhiệm vụ dài được chia thành một loạt các nhiệm vụ nhỏ hơn, thì hệ thống có thể cho phép thực hiện nhiều nhiệm vụ quan trọng hơn giữa các nhiệm vụ đó để tránh sự chậm trễ đáng kể trong việc phản hồi tương tác.
Vì vậy, khi cố gắng cải thiện khả năng phản hồi, nỗ lực đầu tiên thường là chạy theo dõi hiệu suất và xem xét các tác vụ dài. Bạn có thể làm việc này thông qua một công cụ kiểm tra trong phòng thí nghiệm như Lighthouse (có chế độ kiểm tra Tránh các tác vụ dài trong luồng chính) hoặc bằng cách xem xét các tác vụ dài trong Công cụ của Chrome cho nhà phát triển.
Thử nghiệm trong phòng thí nghiệm thường là khởi đầu không tốt để xác định các vấn đề về khả năng phản hồi, vì các công cụ này có thể không bao gồm các lượt tương tác. Tuy nhiên, trong trường hợp có hoạt động tương tác, chúng chỉ là một nhóm nhỏ các lượt tương tác có thể xảy ra. Tốt nhất là bạn nên đo lường các nguyên nhân gây ra các lượt tương tác chậm trong hiện trường.
Hạn chế của Long Tasks API
Việc đo lường các công việc dài trong trường bằng Trình quan sát hiệu suất chỉ khá hữu ích. Trong thực tế, công cụ này không cung cấp nhiều thông tin ngoài việc một nhiệm vụ mất nhiều thời gian đã xảy ra và mất bao lâu.
Các công cụ Giám sát người dùng thực (RUM) thường sử dụng công cụ này để xu hướng số lượng hoặc thời lượng của các tác vụ dài hoặc xác định trang nào chúng xảy ra. Tuy nhiên, nếu không có thông tin chi tiết cơ bản về nguyên nhân gây ra tác vụ dài thì việc này chỉ mang tính hạn chế. Long Tasks API chỉ có mô hình phân bổ cơ bản, tốt nhất chỉ cho bạn biết vùng chứa nơi tác vụ dài đã xảy ra (tài liệu cấp cao nhất hoặc <iframe>
), chứ không phải tập lệnh hoặc hàm đã gọi tác vụ đó, như được hiển thị trong một mục thông thường:
{
"name": "unknown",
"entryType": "longtask",
"startTime": 31.799999997019768,
"duration": 136,
"attribution": [
{
"name": "unknown",
"entryType": "taskattribution",
"startTime": 0,
"duration": 0,
"containerType": "window",
"containerSrc": "",
"containerId": "",
"containerName": ""
}
]
}
Long Tasks API cũng là chế độ xem chưa hoàn chỉnh vì cũng có thể loại trừ một số tác vụ quan trọng. Một số nội dung cập nhật (chẳng hạn như kết xuất) diễn ra trong các tác vụ riêng biệt mà tốt nhất nên được đưa vào cùng với hoạt động thực thi trước đó để giúp nội dung cập nhật đo lường chính xác "toàn bộ công việc" cho tương tác đó. Để biết thêm thông tin về những giới hạn của việc dựa vào việc cần làm, hãy xem bài viết "Trường hợp cần làm nhiều việc thiếu thời gian" của video giải thích.
Vấn đề cuối cùng là việc đo lường các tác vụ dài chỉ báo cáo các tác vụ riêng lẻ mất nhiều thời gian hơn giới hạn 50 mili giây. Khung ảnh động có thể được tạo thành từ một số tác vụ nhỏ hơn giới hạn 50 mili giây này, nhưng nhìn chung vẫn chặn khả năng hiển thị của trình duyệt.
API Khung ảnh động dài
API Khung ảnh động dài (LoAF) là một API mới nhằm giải quyết một số hạn chế của Long Tasks API nhằm giúp nhà phát triển nhận được thông tin chi tiết hữu ích hơn nhằm giải quyết các vấn đề về khả năng phản hồi và cải thiện INP.
Khả năng phản hồi tốt có nghĩa là trang phản hồi nhanh chóng với các tương tác được thực hiện với trang. Điều đó bao gồm khả năng kịp thời vẽ mọi nội dung cập nhật mà người dùng cần và tránh ngăn chặn những nội dung cập nhật này xảy ra. Đối với INP, bạn nên phản hồi trong vòng 200 mili giây trở xuống, nhưng đối với các nội dung cập nhật khác (ví dụ: ảnh động) thì thậm chí có thể quá dài.
API Khung hoạt ảnh dài là một phương pháp thay thế để đo lường công việc chặn. Thay vì đo lường từng tác vụ riêng lẻ, API Khung ảnh động dài (như tên gọi) sẽ đo lường các khung ảnh động dài. Khung hình động dài là khi một bản cập nhật kết xuất bị trễ quá 50 mili giây (giống như ngưỡng dành cho Long Tasks API).
Bạn có thể quan sát các khung ảnh động dài theo cách tương tự như các tác vụ dài bằng PerformanceObserver
, nhưng hãy xem loại long-animation-frame
:
const observer = new PerformanceObserver((list) => {
console.log(list.getEntries());
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Bạn cũng có thể truy vấn các khung ảnh động dài trước đó từ Dòng thời gian hiệu suất như sau:
const loafs = performance.getEntriesByType('long-animation-frame');
Tuy nhiên, có một maxBufferSize
cho các mục nhập hiệu suất mà sau đó các mục mới hơn sẽ bị loại bỏ, vì vậy bạn nên sử dụng phương pháp PerformanceObserver. Dung lượng bộ nhớ đệm long-animation-frame
được thiết lập thành 200, giống như long-tasks
.
Ưu điểm của việc xem khung thay vì tác vụ
Ưu điểm chính của việc xem xét điều này từ góc độ khung hình thay vì góc nhìn công việc là một ảnh động dài có thể được tạo thành từ số lượng công việc bất kỳ tạo nên một khung ảnh động dài. Thao tác này giải quyết điểm cuối cùng đã đề cập trước đó, trong đó tổng của nhiều tác vụ chặn hiển thị nhỏ hơn trước một khung ảnh động có thể không hiển thị bằng Long Tasks API.
Một ưu điểm nữa của chế độ xem thay thế này đối với các tác vụ dài là khả năng cung cấp bảng phân tích thời gian của toàn bộ khung hình. Thay vì chỉ đưa vào startTime
và duration
, chẳng hạn như Long Tasks API, LoAF còn có bảng phân tích chi tiết hơn nhiều về các phần khác nhau trong thời lượng khung hình, bao gồm:
startTime
: thời gian bắt đầu khung ảnh động dài so với thời gian bắt đầu điều hướng.duration
: thời lượng của khung ảnh động dài (không bao gồm thời gian trình bày).renderStart
: thời gian bắt đầu chu kỳ kết xuất, bao gồm cả lệnh gọi lạirequestAnimationFrame
, tính toán kiểu và bố cục, lệnh gọi lại trình quan sát đổi kích thước và trình quan sát giao lộ.styleAndLayoutStart
: thời điểm bắt đầu khoảng thời gian dùng để tính toán kiểu và bố cục.firstUIEventTimestamp
: thời gian của sự kiện giao diện người dùng đầu tiên (chuột/bàn phím, v.v.) được xử lý trong quá trình hiển thị khung này.blockingDuration
: thời lượng tính bằng mili giây mà khung ảnh động bị chặn.
Những dấu thời gian này cho phép chia khung ảnh động dài thành các dấu thời gian:
Thời gian | Cách tính |
---|---|
Thời gian bắt đầu | startTime |
Thời gian kết thúc | startTime + duration |
Thời lượng công việc | renderStart ? renderStart - startTime : duration |
Thời lượng hiển thị | renderStart ? (startTime + duration) - renderStart: 0 |
Kết xuất: Thời lượng bố cục trước | styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0 |
Hiển thị: Thời lượng kiểu và bố cục | styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0 |
Để biết thêm thông tin về các dấu thời gian riêng lẻ này, hãy tham khảo phần giải thích, trong đó cung cấp thông tin chi tiết về hoạt động đang đóng góp vào một khung hình động dài.
Phân bổ hiệu quả hơn
Loại mục nhập long-animation-frame
bao gồm dữ liệu phân bổ tốt hơn của từng tập lệnh đã đóng góp vào một khung hình động dài.
Tương tự như Long Tasks API, API này sẽ được cung cấp trong một loạt các mục nhập phân bổ, mỗi mục như sau:
- Cả
name
vàEntryType
đều sẽ trả vềscript
. - Một
invoker
có ý nghĩa, cho biết cách gọi tập lệnh (ví dụ:'IMG#id.onload'
,'Window.requestAnimationFrame'
hoặc'Response.json.then'
). invokerType
của điểm truy cập tập lệnh:user-callback
: Một lệnh gọi lại đã biết được đăng ký qua API nền tảng web (ví dụ:setTimeout
,requestAnimationFrame
).event-listener
: Trình nghe một sự kiện trên nền tảng (ví dụ:click
,load
,keyup
).resolve-promise
: Trình xử lý của một hứa hẹn về nền tảng (ví dụ:fetch()
. Xin lưu ý rằng trong trường hợp hứa hẹn, tất cả những bên xử lý cùng một lời hứa sẽ kết hợp với nhau thành một "tập lệnh").
reject-promise
: Theoresolve-promise
, nhưng dành cho trường hợp từ chối.classic-script
: Đánh giá tập lệnh (ví dụ:<script>
hoặcimport()
)module-script
: Giống nhưclassic-script
, nhưng dành cho tập lệnh mô-đun.
- Tách dữ liệu thời gian cho tập lệnh đó:
startTime
: Thời gian để gọi hàm nhập.duration
: Khoảng thời gian từstartTime
đến khi hàng đợi vi tác vụ tiếp theo xử lý xong.executionStart
: Thời gian sau khi biên dịch.forcedStyleAndLayoutDuration
: Tổng thời gian dùng để xử lý bố cục và kiểu bắt buộc bên trong hàm này (xem phần đập đổ).pauseDuration
: Tổng thời gian dành cho việc "tạm dừng" hoạt động đồng bộ (cảnh báo, XHR đồng bộ).
- Thông tin chi tiết về nguồn tập lệnh:
sourceURL
: Tên tài nguyên tập lệnh nếu có (hoặc để trống nếu không tìm thấy).sourceFunctionName
: Tên hàm của tập lệnh nếu có (hoặc để trống nếu không tìm thấy).sourceCharPosition
: Vị trí ký tự của tập lệnh nếu có (hoặc -1 nếu không tìm thấy tập lệnh).
windowAttribution
: Vùng chứa (tài liệu cấp cao nhất hoặc<iframe>
) chứa khung ảnh động dài.window
: Tham chiếu đến cửa sổ cùng nguồn gốc.
Nếu được cung cấp, các mục nguồn cho phép nhà phát triển biết chính xác cách gọi từng tập lệnh trong khung ảnh động dài, chi tiết đến vị trí ký tự trong tập lệnh gọi. Thao tác này cung cấp vị trí chính xác trong tài nguyên JavaScript dẫn đến khung hình động dài.
Ví dụ về mục hiệu suất long-animation-frame
Một ví dụ hoàn chỉnh về mục nhập hiệu suất long-animation-frame
có chứa một tập lệnh duy nhất là:
{
"blockingDuration": 0,
"duration": 60,
"entryType": "long-animation-frame",
"firstUIEventTimestamp": 11801.099999999627,
"name": "long-animation-frame",
"renderStart": 11858.800000000745,
"scripts": [
{
"duration": 45,
"entryType": "script",
"executionStart": 11803.199999999255,
"forcedStyleAndLayoutDuration": 0,
"invoker": "DOMWindow.onclick",
"invokerType": "event-listener",
"name": "script",
"pauseDuration": 0,
"sourceURL": "https://web.dev/js/index-ffde4443.js",
"sourceFunctionName": "myClickHandler",
"sourceCharPosition": 17796,
"startTime": 11803.199999999255,
"window": [Window object],
"windowAttribution": "self"
}
],
"startTime": 11802.400000000373,
"styleAndLayoutStart": 11858.800000000745
}
Như có thể thấy, việc này cung cấp một lượng dữ liệu chưa từng có cho các trang web để có thể tìm hiểu nguyên nhân dẫn đến việc cập nhật hiển thị chậm.
Sử dụng API Khung ảnh động dài trong trường
Các công cụ như Công cụ của Chrome cho nhà phát triển và Lighthouse – mặc dù hữu ích trong việc phát hiện và tái tạo vấn đề – là các công cụ trong phòng thí nghiệm có thể bỏ lỡ các khía cạnh quan trọng của trải nghiệm người dùng mà chỉ dữ liệu thực địa mới có thể cung cấp.
API Khung hoạt ảnh dài được thiết kế để sử dụng trong trường nhằm thu thập dữ liệu ngữ cảnh quan trọng cho các tương tác của người dùng mà API Tác vụ dài không thể sử dụng được. Điều này có thể giúp bạn xác định và tái hiện các vấn đề về tương tác mà có thể bạn chưa biết đến.
Tính năng phát hiện tính năng hỗ trợ API Khung ảnh động dài
Bạn có thể sử dụng mã sau để kiểm tra xem API này có được hỗ trợ hay không:
if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
// Monitor LoAFs
}
Liên kết đến tương tác INP dài nhất
Trường hợp sử dụng rõ ràng nhất đối với Long Animation Frames API (API Khung ảnh động dài) là giúp chẩn đoán và khắc phục các vấn đề Tương tác với nội dung hiển thị tiếp theo (INP), cũng như đó là một trong những lý do chính khiến nhóm Chrome phát triển API này. INP tốt là nơi tất cả các tương tác được phản hồi trong vòng 200 mili giây trở xuống từ khi tương tác cho đến khi khung được vẽ và vì API Khung hoạt ảnh dài đo lường tất cả các khung hình mất 50 mili giây trở lên, nên hầu hết các INP có vấn đề phải bao gồm dữ liệu LoAF để giúp bạn chẩn đoán những tương tác đó.
"INP LoAF" là LoAF bao gồm tương tác INP, như thể hiện trong sơ đồ sau:
Trong một số trường hợp, sự kiện INP có thể kéo dài hai LoAF — thường là nếu tương tác xảy ra sau khi khung hình đã bắt đầu phần kết xuất của khung hình trước đó và do đó trình xử lý sự kiện mà sự kiện đó xử lý trong khung hình tiếp theo:
Thậm chí có khả năng hệ thống có thể mở rộng nhiều hơn hai LoAF trong một số ít trường hợp.
Việc ghi lại dữ liệu LoAF liên quan đến hoạt động tương tác INP cho phép bạn nhận thêm nhiều thông tin về hoạt động tương tác INP để giúp chẩn đoán vấn đề. Điều này đặc biệt hữu ích khi bạn cần nắm được độ trễ đầu vào: vì bạn có thể xem các tập lệnh khác đang chạy trong khung đó.
Bạn cũng nên tìm hiểu thời lượng xử lý và độ trễ hiển thị chưa được giải thích nếu trình xử lý sự kiện của bạn không tái tạo các giá trị mà bạn thấy vì các tập lệnh khác có thể đang chạy cho người dùng và có thể không được đưa vào kiểm thử của bạn.
Không có API trực tiếp để liên kết mục nhập INP với mục nhập hoặc mục nhập LoAF liên quan, mặc dù bạn có thể thực hiện việc đó trong mã bằng cách so sánh thời gian bắt đầu và thời gian kết thúc của mục nhập (xem tập lệnh mẫu WhyNp).
Thư viện web-vitals
bao gồm tất cả các LoAF giao nhau trong thuộc tính longAnimationFramesEntries
của giao diện phân bổ INP từ phiên bản 4.
Sau khi liên kết mục nhập LoAF hoặc các mục nhập, bạn có thể thêm thông tin kèm theo thuộc tính INP. Đối tượng scripts
chứa một số thông tin có giá trị nhất vì có thể cho biết những nội dung khác đang chạy trong những khung đó. Do đó, việc chuyển dữ liệu đó về dịch vụ phân tích sẽ giúp bạn hiểu thêm về lý do khiến lượt tương tác bị chậm.
Báo cáo LoAFs cho tương tác INP là một cách hay để tìm ra vấn đề tương tác cấp bách nhất trên trang của bạn. Mỗi người dùng có thể tương tác theo cách khác nhau với trang của bạn và khi có đủ lượng dữ liệu phân bổ INP, một số vấn đề tiềm ẩn sẽ được đưa vào dữ liệu phân bổ INP. Điều này cho phép bạn sắp xếp các tập lệnh theo số lượng để xem tập lệnh nào tương quan với INP chậm.
Báo cáo thêm dữ liệu ảnh động dài cho một điểm cuối Analytics
Nhược điểm của việc chỉ xem xét(các) INP LoAF là bạn có thể bỏ lỡ các khía cạnh tiềm năng khác cần cải thiện, có khả năng gây ra vấn đề về INP trong tương lai. Điều này có thể dẫn đến cảm giác phải đuổi theo, khi bạn khắc phục vấn đề INP và kỳ vọng thấy sự cải thiện đáng kể, chỉ nhận thấy tương tác chậm nhất tiếp theo chỉ cao hơn một chút so với mức đó, do đó INP của bạn không cải thiện nhiều.
Vì vậy, thay vì chỉ tập trung xem INP LoAF, bạn có thể cân nhắc tất cả LoAF trong suốt thời gian tồn tại của trang:
Tuy nhiên, mỗi mục LoAF chứa một lượng dữ liệu đáng kể, do đó, có thể bạn sẽ không muốn báo hiệu cho tất cả mục nhập trở lại. Thay vào đó, bạn sẽ muốn giới hạn phân tích của mình ở một số LoAF hoặc một số dữ liệu.
Một số mẫu được đề xuất bao gồm:
- Quan sát các khung ảnh động dài bằng các hoạt động tương tác
- Quan sát khung ảnh động dài hơn một ngưỡng nhất định
- Quan sát các khung ảnh động dài hoạt động kém hiệu quả nhất
- Xác định các mẫu phổ biến trong khung ảnh động dài
Mẫu nào sau đây phù hợp nhất với bạn, tuỳ thuộc vào hành trình tối ưu hoá của bạn và mức độ phổ biến của khung ảnh động. Đối với một trang web chưa từng được tối ưu hoá cho khả năng phản hồi trước đây, có thể có nhiều LoAF mà bạn có thể muốn giới hạn ở việc chỉ loAF có tương tác, đặt ngưỡng cao hay chỉ xem xét các LoAF kém nhất. Trong quá trình giải quyết các vấn đề thường gặp về khả năng phản hồi, bạn có thể mở rộng phạm vi phản hồi bằng cách không chỉ tương tác, giảm ngưỡng hoặc tìm những điểm chung cụ thể.
Quan sát các khung ảnh động dài bằng các tương tác
Để có được thông tin chi tiết ngoài khung hoạt ảnh dài INP, bạn có thể xem tất cả LoAF cùng với tương tác (có thể được phát hiện khi xuất hiện giá trị firstUIEventTimestamp
).
Đây cũng có thể là một phương pháp theo dõi INP LoAF dễ dàng hơn thay vì cố gắng liên kết cả hai, điều này có thể phức tạp hơn. Trong hầu hết các trường hợp, chỉ số này sẽ bao gồm INP LoAF cho một lượt truy cập nhất định, và trong một số ít trường hợp khi tính năng này không hiển thị các tương tác dài và quan trọng cần khắc phục, vì chúng có thể là tương tác INP cho những người dùng khác.
Mã sau đây ghi lại tất cả các mục LoAF lớn hơn 150 mili giây khi một lượt tương tác xảy ra trong khung hình. 150 được chọn ở đây vì nó nhỏ hơn một chút so với "tốt" 200 mili giây Ngưỡng INP. Bạn có thể chọn giá trị cao hơn hoặc thấp hơn tuỳ theo nhu cầu của mình.
const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.duration > REPORTING_THRESHOLD_MS &&
entry.firstUIEventTimestamp > 0
) {
// Example here logs to console, but could also report back to analytics
console.log(entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Quan sát khung ảnh động lâu hơn một ngưỡng nhất định
Một chiến lược khác là theo dõi tất cả LoAF và báo hiệu những LoAF lớn hơn một ngưỡng nhất định trở về điểm cuối phân tích để phân tích sau này:
const REPORTING_THRESHOLD_MS = 150;
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.duration > REPORTING_THRESHOLD_MS) {
// Example here logs to console, but could also report back to analytics
console.log(entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Vì các mục nhập khung hoạt ảnh dài có thể khá lớn, nhà phát triển nên quyết định dữ liệu nào từ mục nhập đó sẽ được gửi đến Analytics. Ví dụ: thời gian tóm tắt của mục nhập và có thể là tên tập lệnh hoặc một số tập dữ liệu ngữ cảnh tối thiểu khác có thể được coi là cần thiết.
Quan sát các khung ảnh động dài có hiệu suất kém nhất
Thay vì đặt ngưỡng, các trang web có thể muốn thu thập dữ liệu trên khung ảnh động dài nhất (hoặc các khung), để giảm lượng dữ liệu cần được báo hiệu. Vì vậy, bất kể có bao nhiêu ảnh động dài tạo khung hình cho một trải nghiệm trang, chỉ có dữ liệu của 1, 5 hoặc nhiều khung hình động dài nhất cần thiết được báo hiệu trở lại.
MAX_LOAFS_TO_CONSIDER = 10;
let longestBlockingLoAFs = [];
const observer = new PerformanceObserver(list => {
longestBlockingLoAFs = longestBlockingLoAFs.concat(list.getEntries()).sort(
(a, b) => b.blockingDuration - a.blockingDuration
).slice(0, MAX_LOAFS_TO_CONSIDER);
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Các chiến lược này cũng có thể được kết hợp - chỉ xem xét 10 LoAF xấu nhất, với các tương tác, dài hơn 150 mili giây.
Vào thời điểm thích hợp (tốt nhất là vào sự kiện visibilitychange
) báo hiệu cho Analytics trở lại. Để kiểm thử cục bộ, bạn có thể định kỳ sử dụng console.table
:
console.table(longestBlockingLoAFs);
Xác định các mẫu phổ biến trong khung ảnh động dài
Một chiến lược thay thế là xem các tập lệnh phổ biến xuất hiện nhiều nhất trong các mục nhập khung hoạt ảnh dài. Dữ liệu có thể được báo cáo lại ở cấp tập lệnh và vị trí ký tự để xác định người vi phạm nhiều lần.
Điều này có thể đặc biệt hiệu quả trên các nền tảng có thể tuỳ chỉnh, trong đó các chủ đề hoặc trình bổ trợ gây ra vấn đề về hiệu suất có thể được xác định trên một số trang web.
Thời gian thực thi của các tập lệnh phổ biến (hoặc nguồn gốc của bên thứ ba) trong các khung ảnh động dài có thể được tổng hợp và báo cáo lại để xác định những người đóng góp phổ biến cho các khung ảnh động dài trên một trang web hoặc một tập hợp các trang web. Ví dụ về URL:
const observer = new PerformanceObserver(list => {
const allScripts = list.getEntries().flatMap(entry => entry.scripts);
const scriptSource = [...new Set(allScripts.map(script => script.sourceURL))];
const scriptsBySource= scriptSource.map(sourceURL => ([sourceURL,
allScripts.filter(script => script.sourceURL === sourceURL)
]));
const processedScripts = scriptsBySource.map(([sourceURL, scripts]) => ({
sourceURL,
count: scripts.length,
totalDuration: scripts.reduce((subtotal, script) => subtotal + script.duration, 0)
}));
processedScripts.sort((a, b) => b.totalDuration - a.totalDuration);
// Example here logs to console, but could also report back to analytics
console.table(processedScripts);
});
observer.observe({type: 'long-animation-frame', buffered: true});
Ví dụ về kết quả này:
(index) |
sourceURL |
count |
totalDuration |
---|---|---|---|
0 |
'https://example.consent.com/consent.js' |
1 |
840 |
1 |
'https://example.com/js/analytics.js' |
7 |
628 |
2 |
'https://example.chatapp.com/web-chat.js' |
1 |
5 |
Sử dụng Long Animation Frames API (API Khung ảnh động dài) trong công cụ
API này cũng cho phép sử dụng thêm công cụ dành cho nhà phát triển để gỡ lỗi cục bộ. Mặc dù một số công cụ như Lighthouse và Công cụ của Chrome cho nhà phát triển đã có thể thu thập phần lớn dữ liệu này bằng cách sử dụng thông tin theo dõi cấp thấp hơn, nhưng việc có API cấp cao này có thể cho phép các công cụ khác truy cập vào dữ liệu này.
Cho thấy dữ liệu khung ảnh động dài trong Công cụ cho nhà phát triển
Bạn có thể hiển thị các khung ảnh động dài trong Công cụ cho nhà phát triển bằng cách sử dụng API performance.measure()
. Sau đó, API này sẽ được hiển thị trong kênh theo dõi thời gian người dùng của Công cụ cho nhà phát triển trong các dấu vết hiệu suất để cho biết cần tập trung cải thiện hiệu suất ở đâu:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
performance.measure('LoAF', {
start: entry.startTime,
end: entry.startTime + entry.duration,
});
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Về lâu dài, nó có thể sẽ được tích hợp vào chính Công cụ cho nhà phát triển, nhưng đoạn mã trước đó cho phép đoạn mã đó hiển thị ở đó trong thời gian chờ đợi.
Sử dụng dữ liệu khung ảnh động dài trong các công cụ khác dành cho nhà phát triển
Tiện ích Chỉ số quan trọng về trang web đã cho thấy giá trị trong thông tin gỡ lỗi tóm tắt trong việc ghi nhật ký để chẩn đoán các vấn đề về hiệu suất.
Giờ đây, lớp này cũng hiển thị dữ liệu khung ảnh động dài cho mỗi lệnh gọi lại INP và mỗi lượt tương tác:
Sử dụng dữ liệu khung ảnh động dài trong các công cụ kiểm thử tự động
Tương tự như vậy, các công cụ kiểm thử tự động trong quy trình CI/CD có thể hiển thị thông tin chi tiết về các vấn đề tiềm ẩn về hiệu suất bằng cách đo lường các khung ảnh động dài trong khi chạy nhiều bộ kiểm thử.
Câu hỏi thường gặp
Một số câu hỏi thường gặp về API này bao gồm:
Tại sao bạn không chỉ mở rộng hoặc lặp lại trên Long Tasks API?
Đây là một góc nhìn khác để báo cáo một phép đo tương tự (nhưng cuối cùng là khác) về các vấn đề tiềm ẩn liên quan đến khả năng phản hồi. Điều quan trọng là phải đảm bảo các trang web dựa trên Long Tasks API hiện có tiếp tục hoạt động để tránh làm gián đoạn các trường hợp sử dụng hiện có.
Mặc dù Long Tasks API có thể hưởng lợi từ một số tính năng của LoAF (chẳng hạn như mô hình phân bổ tốt hơn), nhưng chúng tôi tin rằng việc tập trung vào khung hình thay vì tác vụ mang lại nhiều lợi ích, khiến API này về cơ bản khác với API Long Tasks hiện có.
Tại sao tôi không có mục nhập tập lệnh?
Điều này có thể cho thấy khung hình động dài không phải do JavaScipt, mà là do tác vụ kết xuất lớn.
Điều này cũng có thể xảy ra khi khung hoạt ảnh dài là do JavaScript nhưng không thể cung cấp thuộc tính tập lệnh vì nhiều lý do bảo mật như đã nêu trước đó (chủ yếu là JavaScript không do trang sở hữu).
Tại sao tôi có các mục nhập tập lệnh nhưng không có hoặc có thông tin hạn chế về nguồn?
Điều này có thể xảy ra vì một số lý do, bao gồm cả đây không phải nguồn thông tin phù hợp.
Thông tin tập lệnh cũng sẽ bị giới hạn đối với các tập lệnh no-cors cross-origin
. Tuy nhiên, bạn có thể giải quyết vấn đề này bằng cách tìm nạp các tập lệnh đó qua CORS bằng cách thêm crossOrigin = "anonymous"
vào lệnh gọi <script>
.
Ví dụ: tập lệnh mặc định trong Trình quản lý thẻ của Google để thêm vào trang:
<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->
Có thể cải tiến để thêm j.crossOrigin = "anonymous"
nhằm cho phép cung cấp đầy đủ thông tin phân bổ cho GTM
API này có thay thế Long Tasks API không?
Chúng tôi tin rằng API Khung hoạt ảnh dài là một API tốt hơn và hoàn chỉnh hơn để đo lường các tác vụ có thời gian dài, nhưng hiện tại, chúng tôi vẫn chưa có kế hoạch ngừng sử dụng API Tác vụ dài.
Mong nhận được ý kiến phản hồi
Bạn có thể cung cấp ý kiến phản hồi tại danh sách Các vấn đề trong GitHub, hoặc bạn có thể gửi các lỗi trong quá trình triển khai API của Chrome trong Công cụ theo dõi lỗi của Chrome.
Kết luận
Long Animation Frames API (API Khung ảnh động dài) là một API mới, rất thú vị với nhiều ưu điểm tiềm năng so với API Long Tasks trước đó.
Đang chứng minh đây là một công cụ quan trọng để giải quyết các vấn đề về khả năng phản hồi theo chỉ số INP (Lượt tương tác đến nội dung hiển thị tiếp theo). INP là chỉ số đầy thách thức để tối ưu hóa và API này là một cách mà nhóm Chrome đang tìm cách giúp nhà phát triển xác định và giải quyết vấn đề dễ dàng hơn.
Tuy nhiên, phạm vi của API Khung hoạt ảnh dài không chỉ dừng lại ở INP. Đồng thời, phạm vi này có thể giúp xác định các nguyên nhân khác khiến việc cập nhật chậm có thể ảnh hưởng đến độ mượt tổng thể của trải nghiệm người dùng trên trang web.