দীর্ঘ অ্যানিমেশন ফ্রেম API

Barry Pollard

Noam Rosenthal

লং অ্যানিমেশন ফ্রেম এপিআই (LoAF-উচ্চারিত Lo-Af) হল লং টাস্ক এপিআই- এর একটি আপডেট যাতে স্লো ইউজার ইন্টারফেস (UI) আপডেটগুলি আরও ভালভাবে বোঝা যায়। এটি ধীরগতির অ্যানিমেশন ফ্রেমগুলি সনাক্ত করতে কার্যকর হতে পারে যা ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (আইএনপি) কোর ওয়েব ভাইটাল মেট্রিককে প্রভাবিত করতে পারে যা প্রতিক্রিয়াশীলতা পরিমাপ করে, বা অন্যান্য UI জ্যাঙ্ক সনাক্ত করতে যা মসৃণতাকে প্রভাবিত করে।

API এর স্থিতি

Chrome 116 থেকে Chrome 122-এ একটি অরিজিন ট্রায়াল অনুসরণ করে, LoAF API Chrome 123 থেকে পাঠানো হয়েছে।

পটভূমি: লং টাস্ক API

লং অ্যানিমেশন ফ্রেম এপিআই হল লং টাস্ক এপিআই এর একটি বিকল্প যা কিছু সময়ের জন্য ক্রোমে উপলব্ধ (ক্রোম 58 থেকে)। এর নাম অনুসারে, লং টাস্ক এপিআই আপনাকে দীর্ঘ কাজগুলির জন্য নিরীক্ষণ করতে দেয়, যেগুলি 50 মিলিসেকেন্ড বা তার বেশি সময়ের জন্য মূল থ্রেড দখল করে। একটি PeformanceObserver সাহায্যে PerformanceLongTaskTiming ইন্টারফেস ব্যবহার করে দীর্ঘ কাজগুলি পর্যবেক্ষণ করা যেতে পারে:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'longtask', buffered: true });

দীর্ঘ কাজগুলি প্রতিক্রিয়াশীলতার সমস্যার কারণ হতে পারে। যদি একজন ব্যবহারকারী একটি পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করার চেষ্টা করে-উদাহরণস্বরূপ, একটি বোতামে ক্লিক করুন, বা একটি মেনু খুলুন-কিন্তু মূল থ্রেডটি ইতিমধ্যেই একটি দীর্ঘ টাস্ক নিয়ে কাজ করছে, তাহলে ব্যবহারকারীর মিথস্ক্রিয়া সেই কাজটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করতে বিলম্বিত হয় ।

প্রতিক্রিয়াশীলতা উন্নত করতে, প্রায়শই দীর্ঘ কাজগুলি ভেঙে ফেলার পরামর্শ দেওয়া হয়। যদি প্রতিটি দীর্ঘ টাস্ককে একাধিক, ছোট টাস্কের একটি সিরিজে বিভক্ত করা হয়, তবে এটি মিথস্ক্রিয়াগুলিতে প্রতিক্রিয়া জানাতে উল্লেখযোগ্য বিলম্ব এড়াতে তাদের মধ্যে আরও গুরুত্বপূর্ণ কাজগুলি সম্পাদন করার অনুমতি দিতে পারে।

তাই প্রতিক্রিয়াশীলতা উন্নত করার চেষ্টা করার সময়, প্রথম প্রচেষ্টাটি প্রায়শই একটি পারফরম্যান্স ট্রেস চালানো এবং দীর্ঘ কাজগুলি দেখতে হয়। এটি লাইটহাউসের মতো একটি ল্যাব-ভিত্তিক অডিটিং টুলের মাধ্যমে হতে পারে (যাতে একটি এড়িয়ে চলা দীর্ঘ প্রধান-থ্রেড টাস্ক অডিট রয়েছে), অথবা Chrome DevTools-এ দীর্ঘ কাজগুলি দেখে ।

ল্যাব-ভিত্তিক পরীক্ষা প্রায়শই প্রতিক্রিয়াশীলতার সমস্যাগুলি সনাক্ত করার জন্য একটি দুর্বল সূচনা স্থান , কারণ এই সরঞ্জামগুলিতে মিথস্ক্রিয়া অন্তর্ভুক্ত নাও হতে পারে—যখন তারা করে, তারা সম্ভাব্য মিথস্ক্রিয়াগুলির একটি ছোট উপসেট। আদর্শভাবে, আপনি ক্ষেত্রের ধীর মিথস্ক্রিয়াগুলির কারণগুলি পরিমাপ করবেন।

লং টাস্ক এপিআই এর ত্রুটি

একটি পারফরম্যান্স পর্যবেক্ষক ব্যবহার করে ক্ষেত্রের দীর্ঘ কাজগুলি পরিমাপ করা শুধুমাত্র কিছুটা কার্যকর। বাস্তবে, এটি এত বেশি তথ্য দেয় না যে একটি দীর্ঘ কাজ ঘটেছে, এবং কত সময় লেগেছে।

রিয়েল ইউজার মনিটরিং (RUM) টুলগুলি প্রায়শই এটি ব্যবহার করে দীর্ঘ টাস্কের সংখ্যা বা সময়কাল প্রবণতা বা কোন পৃষ্ঠায় তারা ঘটছে তা চিহ্নিত করতে - কিন্তু দীর্ঘ টাস্কের কারণের অন্তর্নিহিত বিবরণ ছাড়াই, এটি শুধুমাত্র সীমিত ব্যবহারের জন্য। লং টাস্ক এপিআই-এর শুধুমাত্র একটি বেসিক অ্যাট্রিবিউশন মডেল রয়েছে, যা সর্বোত্তমভাবে আপনাকে কেবল কন্টেইনারটি বলে দেয় যে দীর্ঘ কাজটি ঘটেছে (শীর্ষ-স্তরের নথি বা একটি <iframe> ), কিন্তু স্ক্রিপ্ট বা ফাংশনটি নয় যা এটিকে বলে, যেমন দেখানো হয়েছে একটি সাধারণ এন্ট্রি:

{
  "name": "unknown",
  "entryType": "longtask",
  "startTime": 31.799999997019768,
  "duration": 136,
  "attribution": [
    {
      "name": "unknown",
      "entryType": "taskattribution",
      "startTime": 0,
      "duration": 0,
      "containerType": "window",
      "containerSrc": "",
      "containerId": "",
      "containerName": ""
    }
  ]
}

লং টাস্ক এপিআইও একটি অসম্পূর্ণ দৃশ্য, কারণ এটি কিছু গুরুত্বপূর্ণ কাজ বাদ দিতে পারে। কিছু আপডেট—যেমন রেন্ডারিং—বিচ্ছিন্ন টাস্কে ঘটে যা আদর্শভাবে পূর্ববর্তী এক্সিকিউশনের সাথে একত্রে অন্তর্ভুক্ত করা উচিত যা সেই আপডেটটিকে সেই ইন্টারঅ্যাকশনের জন্য "মোট কাজ" সঠিকভাবে পরিমাপ করতে দেয়। কাজের উপর নির্ভর করার সীমাবদ্ধতার আরও বিশদ বিবরণের জন্য, ব্যাখ্যাকারীর "যেখানে দীর্ঘ কাজগুলি কম হয়" বিভাগটি দেখুন।

চূড়ান্ত সমস্যা হল যে দীর্ঘ টাস্কগুলি পরিমাপ করা শুধুমাত্র পৃথক টাস্কগুলির রিপোর্ট করে যা 50 মিলিসেকেন্ড সীমার চেয়ে বেশি সময় নেয়। একটি অ্যানিমেশন ফ্রেম এই 50 মিলিসেকেন্ডের সীমার চেয়ে ছোট বেশ কয়েকটি কাজ নিয়ে গঠিত হতে পারে, তবুও সমষ্টিগতভাবে এখনও ব্রাউজারের রেন্ডার করার ক্ষমতাকে ব্লক করে।

দীর্ঘ অ্যানিমেশন ফ্রেম API

লং অ্যানিমেশন ফ্রেম এপিআই (LoAF) হল একটি নতুন এপিআই যা লং টাস্ক এপিআই-এর কিছু ত্রুটির সমাধান করতে চায় যাতে ডেভেলপাররা প্রতিক্রিয়াশীলতার সমস্যাগুলি মোকাবেলা করতে এবং INP উন্নত করতে সাহায্য করার জন্য আরও কার্যকর অন্তর্দৃষ্টি পেতে সক্ষম হয়, সেইসাথে মসৃণতা সমস্যাগুলির অন্তর্দৃষ্টি পেতে। .

ভাল প্রতিক্রিয়াশীলতার অর্থ হল একটি পৃষ্ঠা এটির সাথে করা মিথস্ক্রিয়াগুলিতে দ্রুত প্রতিক্রিয়া জানায়৷ এটি একটি সময়মত পদ্ধতিতে ব্যবহারকারীর দ্বারা প্রয়োজনীয় যেকোন আপডেটগুলি আঁকতে সক্ষম হওয়া এবং এই আপডেটগুলিকে ঘটতে বাধা দেওয়া এড়ানো জড়িত। INP-এর জন্য, 200 মিলিসেকেন্ড বা তার কম সময়ে প্রতিক্রিয়া জানানোর পরামর্শ দেওয়া হয় , কিন্তু অন্যান্য আপডেটের জন্য (উদাহরণস্বরূপ, অ্যানিমেশন) এমনকি 200 মিলিসেকেন্ডও খুব দীর্ঘ হতে পারে৷

লং অ্যানিমেশন ফ্রেম API হল ব্লকিং কাজ পরিমাপের একটি বিকল্প পদ্ধতি। স্বতন্ত্র কাজগুলি পরিমাপ করার পরিবর্তে, লং অ্যানিমেশন ফ্রেম এপিআই—যেমন এর নাম থেকে বোঝা যায়— দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পরিমাপ করে৷ একটি দীর্ঘ অ্যানিমেশন ফ্রেম হল যখন একটি রেন্ডারিং আপডেট 50 মিলিসেকেন্ডের বেশি বিলম্বিত হয় (লং টাস্ক API-এর থ্রেশহোল্ডের মতো)।

লম্বা অ্যানিমেশন ফ্রেমগুলি কাজগুলির শুরু থেকে পরিমাপ করা হয় যার জন্য একটি রেন্ডার প্রয়োজন। যেখানে একটি সম্ভাব্য দীর্ঘ অ্যানিমেশন ফ্রেমের প্রথম টাস্কের জন্য রেন্ডারের প্রয়োজন হয় না, সেখানে দীর্ঘ অ্যানিমেশন ফ্রেমটি নন-রেন্ডারিং টাস্কটি সম্পূর্ণ হওয়ার পরে শেষ হয় এবং পরবর্তী টাস্কের সাথে একটি নতুন সম্ভাব্য দীর্ঘ অ্যানিমেশন ফ্রেম শুরু হয়। এই ধরনের নন-রেন্ডারিং লং অ্যানিমেশন ফ্রেম এখনও লং অ্যানিমেশন ফ্রেম এপিআই-তে অন্তর্ভুক্ত থাকে যখন 50 মিলিসেকেন্ডের বেশি (0 এর renderStart টাইম সহ) সম্ভাব্য ব্লকিং কাজ পরিমাপ করার অনুমতি দেয়।

দীর্ঘ অ্যানিমেশন ফ্রেমগুলি PerformanceObserver সাথে দীর্ঘ কাজগুলির মতো একইভাবে পর্যবেক্ষণ করা যেতে পারে, তবে এর পরিবর্তে long-animation-frame ধরণটি দেখুন:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'long-animation-frame', buffered: true });

পূর্ববর্তী দীর্ঘ অ্যানিমেশন ফ্রেমগুলিও পারফরম্যান্স টাইমলাইন থেকে জিজ্ঞাসা করা যেতে পারে যেমন:

const loafs = performance.getEntriesByType('long-animation-frame');

যাইহোক, পারফরম্যান্স এন্ট্রিগুলির জন্য একটি maxBufferSize রয়েছে যার পরে নতুন এন্ট্রিগুলি বাদ দেওয়া হয়, তাই PerformanceObserver পদ্ধতিটি প্রস্তাবিত পদ্ধতি। long-animation-frame বাফার সাইজ 200-এ সেট করা হয়েছে, long-tasks মতো।

কাজের পরিবর্তে ফ্রেমের দিকে তাকানোর সুবিধা

একটি টাস্ক দৃষ্টিকোণ থেকে এটিকে ফ্রেমের দৃষ্টিকোণ থেকে দেখার মূল সুবিধা হল যে একটি দীর্ঘ অ্যানিমেশন যেকোন সংখ্যক টাস্ক দিয়ে তৈরি করা যেতে পারে যা একটি দীর্ঘ অ্যানিমেশন ফ্রেমে পরিণত হয়। এটি পূর্বে উল্লিখিত চূড়ান্ত বিন্দুকে সম্বোধন করে, যেখানে একটি অ্যানিমেশন ফ্রেমের আগে অনেক ছোট, রেন্ডার-ব্লকিং টাস্কের যোগফল লং টাস্ক API দ্বারা প্রদর্শিত নাও হতে পারে।

দীর্ঘ কাজের ক্ষেত্রে এই বিকল্প দৃষ্টিভঙ্গির আরও একটি সুবিধা হল পুরো ফ্রেমের টাইমিং ব্রেকডাউন প্রদান করার ক্ষমতা। লং টাস্ক এপিআই-এর মতো startTime এবং একটি duration অন্তর্ভুক্ত করার পরিবর্তে, LoAF ফ্রেমের সময়কালের বিভিন্ন অংশের আরও বিশদ বিভাজন অন্তর্ভুক্ত করে।

ফ্রেম টাইমস্ট্যাম্প এবং সময়কাল

• startTime : নেভিগেশন শুরুর সময়ের তুলনায় দীর্ঘ অ্যানিমেশন ফ্রেমের শুরুর সময়।
• duration : দীর্ঘ অ্যানিমেশন ফ্রেমের সময়কাল (প্রেজেন্টেশনের সময় সহ নয়)।
• renderStart : রেন্ডারিং চক্রের শুরুর সময়, যার মধ্যে requestAnimationFrame কলব্যাক, স্টাইল এবং লেআউট গণনা, রিসাইজ পর্যবেক্ষক এবং ইন্টারসেকশন পর্যবেক্ষক কলব্যাক অন্তর্ভুক্ত রয়েছে।
• styleAndLayoutStart : শৈলী এবং বিন্যাস গণনায় অতিবাহিত সময়ের শুরু।
• firstUIEventTimestamp : প্রথম UI ইভেন্টের সময় (মাউস/কীবোর্ড এবং তাই) এই ফ্রেমের সময় পরিচালনা করতে হবে।
• blockingDuration : মিলিসেকেন্ডে মোট সময়কাল যার জন্য অ্যানিমেশন ফ্রেম ইনপুট বা অন্যান্য উচ্চ অগ্রাধিকারমূলক কাজগুলির প্রক্রিয়াকরণকে ব্লক করবে।

blockingDuration ব্যাখ্যা

একটি দীর্ঘ অ্যানিমেশন ফ্রেম বেশ কয়েকটি কাজ নিয়ে গঠিত হতে পারে। blockingDuration হল 50 মিলিসেকেন্ডের (দীর্ঘতম টাস্কের মধ্যে চূড়ান্ত রেন্ডারের সময়কাল সহ) দীর্ঘ সময়ের টাস্কের সমষ্টি।

উদাহরণস্বরূপ, যদি একটি দীর্ঘ অ্যানিমেশন ফ্রেম 55 মিলিসেকেন্ড এবং 65 মিলিসেকেন্ডের দুটি টাস্ক নিয়ে গঠিত হয় এবং তারপরে 20 মিলিসেকেন্ডের রেন্ডার হয়, তাহলে duration প্রায় 140 মিলিসেকেন্ড হবে যার blockingDuration (55 - 50) + (65 + 20) - 50) = 40 মিলিসেকেন্ড। এই 140 মিলিসেকেন্ড দীর্ঘ অ্যানিমেশন ফ্রেমের সময় 40 মিলিসেকেন্ডের জন্য, ফ্রেমটিকে ইনপুট পরিচালনা থেকে অবরুদ্ধ বলে মনে করা হয়েছিল৷

duration বা blockingDuration দেখুন কিনা

সাধারণ 60 হার্টজ ডিসপ্লের জন্য, একটি ব্রাউজার কমপক্ষে প্রতি 16.66 মিলিসেকেন্ডে একটি ফ্রেম নির্ধারণ করার চেষ্টা করবে (মসৃণ আপডেটগুলি নিশ্চিত করতে), বা ইনপুট হ্যান্ডলিং (প্রতিক্রিয়াশীল আপডেটগুলি নিশ্চিত করতে) এর মতো একটি উচ্চ অগ্রাধিকার কাজ করার পরে। যাইহোক, যদি কোনো ইনপুট না থাকে—না অন্য উচ্চ-অগ্রাধিকারমূলক কাজগুলি—কিন্তু অন্যান্য কাজের একটি সারি থাকে, তাহলে ব্রাউজারটি সাধারণত বর্তমান ফ্রেমটিকে 16.66 মিলিসেকেন্ডের আগে চালিয়ে যাবে, কাজগুলি যতই ভালভাবে ভেঙে ফেলা হোক না কেন। অর্থাৎ, ব্রাউজার সর্বদা ইনপুটগুলিকে অগ্রাধিকার দেওয়ার চেষ্টা করবে, তবে রেন্ডার আপডেটের উপর কাজগুলির একটি সারি মোকাবেলা করতে বেছে নিতে পারে। এটি রেন্ডারিং একটি ব্যয়বহুল প্রক্রিয়া হওয়ার কারণে তাই একাধিক কাজের জন্য একটি সম্মিলিত রেন্ডারিং টাস্ক প্রক্রিয়াকরণ সাধারণত কাজের সামগ্রিক হ্রাসের দিকে পরিচালিত করে।

অতএব, কম বা শূন্য blockingDuration সহ দীর্ঘ অ্যানিমেশন ফ্রেমগুলি এখনও ইনপুট করার জন্য প্রতিক্রিয়াশীল বোধ করা উচিত। দীর্ঘ টাস্কগুলি ভেঙে blockingDuration হ্রাস করা বা নির্মূল করা তাই INP দ্বারা পরিমাপ করা প্রতিক্রিয়াশীলতা উন্নত করার মূল চাবিকাঠি।

যাইহোক, অনেক লম্বা অ্যানিমেশন ফ্রেম, blockingDuration নির্বিশেষে UI আপডেটগুলিকে নির্দেশ করে যেগুলি বিলম্বিত হয় এবং তাই এখনও মসৃণতাকে প্রভাবিত করতে পারে এবং স্ক্রলিং বা অ্যানিমেশনগুলির জন্য একটি ল্যাজি ইউজার ইন্টারফেসের অনুভূতির দিকে নিয়ে যেতে পারে, এমনকি যদি এইগুলি প্রতিক্রিয়াশীলতার জন্য কম সমস্যা হয় INP দ্বারা পরিমাপ করা হয়। এই ক্ষেত্রের সমস্যাগুলি বোঝার জন্য duration দেখুন, তবে এটির জন্য অপ্টিমাইজ করা আরও জটিল হতে পারে কারণ আপনি কাজ ভেঙে দিয়ে এটি সমাধান করতে পারবেন না, তবে তার পরিবর্তে কাজ কমাতে হবে।

ফ্রেমের সময়

পূর্বে উল্লিখিত টাইমস্ট্যাম্পগুলি দীর্ঘ অ্যানিমেশন ফ্রেমকে সময়গুলিতে বিভক্ত করার অনুমতি দেয়:

আরও ভালো স্ক্রিপ্ট অ্যাট্রিবিউশন

long-animation-frame এন্ট্রি টাইপটিতে প্রতিটি স্ক্রিপ্টের আরও ভাল অ্যাট্রিবিউশন ডেটা অন্তর্ভুক্ত থাকে যা একটি দীর্ঘ অ্যানিমেশন ফ্রেমে অবদান রাখে (5 মিলিসেকেন্ডের বেশি স্ক্রিপ্টের জন্য)।

লং টাস্ক API-এর মতো, এটি অ্যাট্রিবিউশন এন্ট্রিগুলির একটি অ্যারেতে সরবরাহ করা হবে, যার প্রতিটি বিশদ:

• একটি name এবং EntryType উভয়ই script প্রদান করবে।
• একটি অর্থপূর্ণ invoker , যা নির্দেশ করে যে স্ক্রিপ্টটি কীভাবে কল করা হয়েছিল (উদাহরণস্বরূপ, 'IMG#id.onload' , 'Window.requestAnimationFrame' , বা 'Response.json.then' )।
• স্ক্রিপ্ট এন্ট্রি পয়েন্টের invokerType :
  • user-callback : একটি ওয়েব প্ল্যাটফর্ম API থেকে নিবন্ধিত একটি পরিচিত কলব্যাক (উদাহরণস্বরূপ, setTimeout , requestAnimationFrame )।
  • event-listener : একটি প্ল্যাটফর্ম ইভেন্টের একজন শ্রোতা (উদাহরণস্বরূপ, click , load , keyup )।
  • resolve-promise : একটি প্ল্যাটফর্ম প্রতিশ্রুতির হ্যান্ডলার (উদাহরণস্বরূপ, fetch() । উল্লেখ্য যে প্রতিশ্রুতির ক্ষেত্রে, একই প্রতিশ্রুতির সমস্ত হ্যান্ডলারকে একটি "স্ক্রিপ্ট" হিসাবে একত্রে মিশ্রিত করা হয়) .
  • reject-promise : resolve-promise অনুযায়ী, কিন্তু প্রত্যাখ্যানের জন্য।
  • classic-script : স্ক্রিপ্ট মূল্যায়ন (উদাহরণস্বরূপ, <script> বা import() )
  • module-script : classic-script মতো, কিন্তু মডিউল স্ক্রিপ্টের জন্য।
• সেই স্ক্রিপ্টের জন্য আলাদা টাইমিং ডেটা:
  • startTime : এন্ট্রি ফাংশন আহ্বান করা হয়েছে সময়.
  • duration : startTime এবং পরবর্তী মাইক্রোটাস্ক সারি প্রক্রিয়াকরণ শেষ হওয়ার মধ্যে সময়কাল।
  • executionStart : সংকলনের পরের সময়।
  • forcedStyleAndLayoutDuration : এই ফাংশনের ভিতরে বাধ্যতামূলক লেআউট এবং শৈলী প্রক্রিয়াকরণে ব্যয় করা মোট সময় ( থ্র্যাশিং দেখুন)।
  • pauseDuration : "পজ" সিঙ্ক্রোনাস অপারেশনে ব্যয় করা মোট সময় (সতর্ক, সিঙ্ক্রোনাস এক্সএইচআর)।
• স্ক্রিপ্ট উত্স বিবরণ:
  • sourceURL : স্ক্রিপ্ট রিসোর্সের নাম যেখানে পাওয়া যায় (বা না পাওয়া গেলে খালি)।
  • sourceFunctionName : স্ক্রিপ্ট ফাংশনের নাম যেখানে উপলব্ধ (বা না পাওয়া গেলে খালি)।
  • sourceCharPosition : স্ক্রিপ্ট অক্ষর অবস্থান যেখানে উপলব্ধ (অথবা -1 যদি না পাওয়া যায়)।
• windowAttribution : কন্টেইনার (শীর্ষ-স্তরের নথি, অথবা একটি <iframe> ) যে দীর্ঘ অ্যানিমেশন ফ্রেমটি ঘটেছে।
• window : একই-অরিজিন উইন্ডোর একটি রেফারেন্স।

যেখানে সরবরাহ করা হয়েছে, উত্স এন্ট্রিগুলি ডেভেলপারদের কলিং স্ক্রিপ্টের অক্ষরের অবস্থানে, দীর্ঘ অ্যানিমেশন ফ্রেমের প্রতিটি স্ক্রিপ্টকে ঠিক কীভাবে কল করা হয়েছিল তা জানতে দেয়৷ এটি একটি জাভাস্ক্রিপ্ট রিসোর্সে সঠিক অবস্থান দেয় যা দীর্ঘ অ্যানিমেশন ফ্রেমে পরিণত হয়।

একটি long-animation-frame কর্মক্ষমতা এন্ট্রির উদাহরণ

একটি সম্পূর্ণ long-animation-frame কর্মক্ষমতা এন্ট্রি উদাহরণ, একটি একক স্ক্রিপ্ট সমন্বিত, হল:

{
  "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
}

দেখা যায়, এটি ল্যাজি রেন্ডারিং আপডেটের কারণ বুঝতে সক্ষম হওয়ার জন্য ওয়েবসাইটগুলির জন্য অভূতপূর্ব পরিমাণ ডেটা দেয়।

ক্ষেত্রে দীর্ঘ অ্যানিমেশন ফ্রেম API ব্যবহার করুন

Chrome DevTools এবং Lighthouse-এর মতো টুলগুলি-যদিও সমস্যাগুলি আবিষ্কার এবং পুনরুত্পাদন করার জন্য উপযোগী—এমন ল্যাব টুল যা ব্যবহারকারীর অভিজ্ঞতার গুরুত্বপূর্ণ দিকগুলি মিস করতে পারে যা শুধুমাত্র ফিল্ড ডেটা প্রদান করতে পারে।

লং অ্যানিমেশন ফ্রেম API ব্যবহারকারীর মিথস্ক্রিয়াগুলির জন্য গুরুত্বপূর্ণ প্রাসঙ্গিক ডেটা সংগ্রহ করতে ক্ষেত্রে ব্যবহার করার জন্য ডিজাইন করা হয়েছে যা লং টাস্ক API করতে পারেনি। এটি আপনাকে ইন্টারঅ্যাক্টিভিটি সহ সমস্যাগুলি সনাক্ত করতে এবং পুনরুত্পাদন করতে সহায়তা করতে পারে যা আপনি অন্যথায় আবিষ্কার করতে পারেননি।

দীর্ঘ অ্যানিমেশন ফ্রেম API সমর্থন সনাক্তকরণ বৈশিষ্ট্য

API সমর্থিত কিনা তা পরীক্ষা করতে আপনি নিম্নলিখিত কোড ব্যবহার করতে পারেন:

if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
  // Monitor LoAFs
}

দীর্ঘতম INP মিথস্ক্রিয়া লিঙ্ক

লং অ্যানিমেশন ফ্রেম এপিআই-এর সবচেয়ে সুস্পষ্ট ব্যবহারের ক্ষেত্রে নেক্সট পেইন্ট (আইএনপি) সমস্যাগুলির ইন্টারঅ্যাকশন নির্ণয় এবং ঠিক করতে সাহায্য করা, এবং এটিই ছিল ক্রোম টিম এই APIটি তৈরি করার অন্যতম প্রধান কারণ। একটি ভাল INP হল যেখানে ফ্রেম আঁকা না হওয়া পর্যন্ত মিথস্ক্রিয়া থেকে 200 মিলিসেকেন্ড বা তার কম সময়ে সমস্ত ইন্টারঅ্যাকশনের প্রতিক্রিয়া জানানো হয় এবং যেহেতু লং অ্যানিমেশন ফ্রেম এপিআই 50ms বা তার বেশি সময় নেয় এমন সমস্ত ফ্রেম পরিমাপ করে, তাই বেশিরভাগ সমস্যাযুক্ত INP-এ আপনাকে নির্ণয় করতে সহায়তা করার জন্য LoAF ডেটা অন্তর্ভুক্ত করা উচিত। যারা মিথস্ক্রিয়া.

"INP LoAF" হল LoAF যা INP মিথস্ক্রিয়া অন্তর্ভুক্ত করে, যেমনটি নিম্নলিখিত চিত্রে দেখানো হয়েছে:

কিছু ক্ষেত্রে একটি INP ইভেন্টের জন্য দুটি LoAFs স্প্যান করা সম্ভব-সাধারণত যদি ফ্রেমটি পূর্ববর্তী ফ্রেমের রেন্ডারিং অংশ শুরু করার পরে মিথস্ক্রিয়া ঘটে, এবং তাই ইভেন্ট হ্যান্ডলার পরবর্তী ফ্রেমে প্রক্রিয়া করা হয়:

এটি এমন কি সম্ভব যে এটি কিছু বিরল পরিস্থিতিতে দুটির বেশি LoAFs জুড়ে থাকতে পারে।

INP ইন্টারঅ্যাকশনের সাথে যুক্ত LoAF(গুলি) ডেটা রেকর্ড করা আপনাকে এটি নির্ণয় করতে সাহায্য করার জন্য INP মিথস্ক্রিয়া সম্পর্কে আরও অনেক তথ্য পেতে দেয়। ইনপুট বিলম্ব বোঝার জন্য এটি বিশেষভাবে সহায়ক: আপনি দেখতে পাচ্ছেন যে সেই ফ্রেমে অন্যান্য স্ক্রিপ্টগুলি কী চলছিল।

এটি অব্যক্ত প্রক্রিয়াকরণের সময়কাল এবং উপস্থাপনা বিলম্ব বুঝতে সহায়ক হতে পারে যদি আপনার ইভেন্ট হ্যান্ডলাররা তাদের জন্য দেখা মানগুলি পুনরুত্পাদন না করে কারণ অন্যান্য স্ক্রিপ্টগুলি আপনার ব্যবহারকারীদের জন্য চলমান হতে পারে যা আপনার নিজের পরীক্ষায় অন্তর্ভুক্ত নাও হতে পারে৷

একটি INP এন্ট্রিকে এর সম্পর্কিত LoAF এন্ট্রি বা এন্ট্রিগুলির সাথে লিঙ্ক করার জন্য কোনও সরাসরি API নেই , যদিও প্রতিটির শুরু এবং শেষের সময় তুলনা করে কোডে এটি করা সম্ভব ( WhyNp উদাহরণ স্ক্রিপ্ট দেখুন)। web-vitals লাইব্রেরিতে v4 থেকে INP অ্যাট্রিবিউশন ইন্টারফেসের longAnimationFramesEntries সম্পত্তিতে সমস্ত ছেদ করা LoAFs অন্তর্ভুক্ত রয়েছে।

একবার আপনি LoAF এন্ট্রি বা এন্ট্রি লিঙ্ক করলে, আপনি INP অ্যাট্রিবিউশন সহ তথ্য অন্তর্ভুক্ত করতে পারেন। scripts অবজেক্টে কিছু সবচেয়ে মূল্যবান তথ্য রয়েছে কারণ এটি সেই ফ্রেমে আর কী চলছিল তা দেখাতে পারে তাই আপনার বিশ্লেষণ পরিষেবাতে সেই ডেটা ফিরে আসার ফলে আপনি কেন মিথস্ক্রিয়াগুলি ধীর ছিল সে সম্পর্কে আরও বুঝতে পারবেন।

INP ইন্টারঅ্যাকশনের জন্য LoAFs রিপোর্ট করা আপনার পৃষ্ঠায় সবচেয়ে চাপের ইন্টারঅ্যাকটিভিটি সমস্যাগুলি খুঁজে বের করার একটি ভাল উপায়। প্রতিটি ব্যবহারকারী আপনার পৃষ্ঠার সাথে আলাদাভাবে ইন্টারঅ্যাক্ট করতে পারে এবং যথেষ্ট পরিমাণ INP অ্যাট্রিবিউশন ডেটা সহ, অনেকগুলি সম্ভাব্য সমস্যা INP অ্যাট্রিবিউশন ডেটাতে অন্তর্ভুক্ত করা হবে৷ এটি আপনাকে স্ক্রিপ্টগুলিকে ভলিউম অনুসারে বাছাই করতে দেয় যে কোন স্ক্রিপ্টগুলি ধীর INP এর সাথে সম্পর্কযুক্ত।

আরও দীর্ঘ অ্যানিমেশন ডেটা অ্যানালিটিক্স এন্ডপয়েন্টে রিপোর্ট করুন

শুধুমাত্র INP LoAF(গুলি) দেখার একটি নেতিবাচক দিক হল, আপনি উন্নতির জন্য অন্যান্য সম্ভাব্য ক্ষেত্রগুলি মিস করতে পারেন যা ভবিষ্যতে INP সমস্যার কারণ হতে পারে। এটি আপনার লেজের পিছনে তাড়া করার অনুভূতির দিকে নিয়ে যেতে পারে যেখানে আপনি একটি বিশাল উন্নতির আশা করে একটি INP সমস্যা সমাধান করেন, শুধুমাত্র পরবর্তী ধীর মিথস্ক্রিয়া খুঁজে পেতে তার চেয়ে সামান্য পরিমাণে ভাল হয় যাতে আপনার INP খুব বেশি উন্নতি করে না।

তাই শুধুমাত্র INP LoAF দেখার পরিবর্তে, আপনি পৃষ্ঠার জীবনকাল জুড়ে সমস্ত LoAF বিবেচনা করতে চাইতে পারেন:

যাইহোক, প্রতিটি LoAF এন্ট্রিতে যথেষ্ট ডেটা থাকে, তাই আপনি সম্ভবত আপনার বিশ্লেষণকে শুধুমাত্র কিছু LoAF তে সীমাবদ্ধ রাখতে চাইবেন। উপরন্তু, যেহেতু দীর্ঘ অ্যানিমেশন ফ্রেম এন্ট্রিগুলি বেশ বড় হতে পারে, তাই বিকাশকারীদের সিদ্ধান্ত নেওয়া উচিত যে এন্ট্রি থেকে কোন ডেটা বিশ্লেষণে পাঠানো উচিত। উদাহরণস্বরূপ, এন্ট্রির সারাংশ সময় এবং সম্ভবত স্ক্রিপ্টের নাম, বা অন্যান্য প্রাসঙ্গিক ডেটার কিছু ন্যূনতম সেট যা প্রয়োজনীয় বলে মনে করা যেতে পারে।

দীর্ঘ অ্যানিমেশন ফ্রেম ডেটার পরিমাণ কমাতে কিছু প্রস্তাবিত নিদর্শনগুলির মধ্যে রয়েছে:

• মিথস্ক্রিয়া সহ দীর্ঘ অ্যানিমেশন ফ্রেম পর্যবেক্ষণ করুন
• উচ্চ ব্লকিং সময়কাল সহ দীর্ঘ অ্যানিমেশন ফ্রেম পর্যবেক্ষণ করুন
• মসৃণতা উন্নত করতে সমালোচনামূলক UI আপডেটের সময় দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন
• সবচেয়ে খারাপ দীর্ঘ অ্যানিমেশন ফ্রেম পর্যবেক্ষণ করুন
• দীর্ঘ অ্যানিমেশন ফ্রেমে সাধারণ নিদর্শন সনাক্ত করুন

এই প্যাটার্নগুলির মধ্যে কোনটি আপনার জন্য সবচেয়ে ভাল কাজ করে, আপনার অপ্টিমাইজেশান যাত্রায় আপনি কতটা দূরে আছেন এবং কতটা সাধারণ অ্যানিমেশন ফ্রেম তার উপর নির্ভর করে। এমন একটি সাইটের জন্য যেটি আগে কখনো প্রতিক্রিয়াশীলতার জন্য অপ্টিমাইজ করেনি, সেখানে অনেক LoAF থাকতে পারে আপনি কি ইন্টারঅ্যাকশনের সাথে শুধুমাত্র LoAFs-এ সীমাবদ্ধ রাখতে চান, বা একটি উচ্চ থ্রেশহোল্ড সেট করতে চান, অথবা শুধুমাত্র সবচেয়ে খারাপের দিকে তাকান।

আপনি আপনার সাধারণ প্রতিক্রিয়াশীলতার সমস্যাগুলি সমাধান করার সাথে সাথে, আপনি কেবল মিথস্ক্রিয়া বা উচ্চ ব্লকিং সময়কাল বা থ্রেশহোল্ড কমিয়ে সীমাবদ্ধ না করে এটিকে প্রসারিত করতে পারেন।

মিথস্ক্রিয়া সহ দীর্ঘ অ্যানিমেশন ফ্রেম পর্যবেক্ষণ করুন

শুধুমাত্র INP দীর্ঘ অ্যানিমেশন ফ্রেমের বাইরে অন্তর্দৃষ্টি পেতে, আপনি একটি উচ্চ blockingDuration সহ মিথস্ক্রিয়া (যা একটি firstUIEventTimestamp মানের উপস্থিতি দ্বারা সনাক্ত করা যেতে পারে) সহ সমস্ত LoAFs দেখতে পারেন।

এটি দুটিকে পারস্পরিক সম্পর্ক স্থাপনের চেষ্টা করার পরিবর্তে INP LoAFs পর্যবেক্ষণ করার একটি সহজ পদ্ধতি হতে পারে, যা আরও জটিল হতে পারে। বেশিরভাগ ক্ষেত্রে এটি একটি প্রদত্ত দর্শনের জন্য INP LoAF অন্তর্ভুক্ত করবে, এবং বিরল ক্ষেত্রে যখন এটি এখনও দীর্ঘ ইন্টারঅ্যাকশনগুলি প্রকাশ করে না যা ঠিক করা গুরুত্বপূর্ণ, কারণ সেগুলি অন্যান্য ব্যবহারকারীদের জন্য INP মিথস্ক্রিয়া হতে পারে।

নিম্নলিখিত কোডটি 100 মিলিসেকেন্ডের বেশি blockingDuration সহ সমস্ত LoAF এন্ট্রি লগ করে যেখানে ফ্রেমের সময় একটি মিথস্ক্রিয়া ঘটেছে। 100 এখানে বেছে নেওয়া হয়েছে কারণ এটি 200 মিলিসেকেন্ড "ভাল" INP থ্রেশহোল্ডের চেয়ে কম। আপনি আপনার প্রয়োজনের উপর নির্ভর করে একটি উচ্চ বা নিম্ন মান চয়ন করতে পারেন।

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.blockingDuration > 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 });

উচ্চ ব্লকিং সময়কাল সহ দীর্ঘ অ্যানিমেশন ফ্রেম পর্যবেক্ষণ করুন

মিথস্ক্রিয়া সহ সমস্ত দীর্ঘ অ্যানিমেশন ফ্রেমগুলি দেখার উন্নতি হিসাবে, আপনি উচ্চ ব্লকিং সময়কাল সহ সমস্ত দীর্ঘ অ্যানিমেশন ফ্রেমগুলি দেখতে চাইতে পারেন। এই দীর্ঘ অ্যানিমেশন ফ্রেমের সময় কোনো ব্যবহারকারী ইন্টারঅ্যাক্ট করলে এগুলি সম্ভাব্য INP সমস্যাগুলি নির্দেশ করে৷

নিম্নলিখিত কোডটি 100 মিলিসেকেন্ডের বেশি ব্লকিং সময়কাল সহ সমস্ত LoAF এন্ট্রি লগ করে যেখানে ফ্রেমের সময় একটি মিথস্ক্রিয়া ঘটেছে। 100 এখানে বেছে নেওয়া হয়েছে কারণ এটি 200 মিলিসেকেন্ডের "ভাল" INP থ্রেশহোল্ডের চেয়ে কম, সম্ভাব্য সমস্যা ফ্রেমগুলি সনাক্ত করতে সাহায্য করার জন্য, দীর্ঘ অ্যানিমেশন ফ্রেমের পরিমাণকে ন্যূনতম রিপোর্ট করার সময়। আপনি আপনার প্রয়োজনের উপর নির্ভর করে একটি উচ্চ বা নিম্ন মান চয়ন করতে পারেন।

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.blockingDuration > 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 });

মসৃণতা উন্নত করতে সমালোচনামূলক UI আপডেটের সময় দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন

পূর্বে উল্লিখিত হিসাবে, উচ্চ ব্লকিং সময়কালের দীর্ঘ অ্যানিমেশন ফ্রেমের দিকে তাকানো ইনপুট প্রতিক্রিয়াশীলতার সমাধান করতে সাহায্য করতে পারে। তবে মসৃণতার জন্য আপনাকে দীর্ঘ duration সমস্ত দীর্ঘ অ্যানিমেশন ফ্রেমগুলি দেখতে হবে।

যেহেতু, এটি বেশ শোরগোল পেতে পারে আপনি এইগুলির মতো একটি প্যাটার্ন সহ মূল পয়েন্টগুলিতে পরিমাপ সীমাবদ্ধ করতে চাইতে পারেন:

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  if (measureImportantUIupdate) {
    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 });

async function doUIUpdatesWithMeasurements() {
  measureImportantUIupdate = true;
  await doUIUpdates();
  measureImportantUIupdate = false;
}

সবচেয়ে খারাপ দীর্ঘ অ্যানিমেশন ফ্রেম পর্যবেক্ষণ করুন

একটি সেট থ্রেশহোল্ড থাকার পরিবর্তে, সাইটগুলি দীর্ঘতম অ্যানিমেশন ফ্রেমের (বা ফ্রেমে) ডেটা সংগ্রহ করতে চাইতে পারে, যাতে বীকন করা দরকার এমন ডেটার পরিমাণ কমাতে। তাই একটি পৃষ্ঠার অভিজ্ঞতা যতই দীর্ঘ অ্যানিমেশন ফ্রেমে থাকুক না কেন, শুধুমাত্র সবচেয়ে খারাপ, পাঁচ, দশ, বা যেকোন দীর্ঘ অ্যানিমেশন ফ্রেমের জন্য একেবারে প্রয়োজনীয় ডেটাই ফিরে আসবে।

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 });

এই কৌশলগুলিকেও একত্রিত করা যেতে পারে—শুধুমাত্র 10টি সবচেয়ে খারাপ LoAF দেখুন, মিথস্ক্রিয়া সহ, 100 মিলিসেকেন্ডের বেশি।

উপযুক্ত সময়ে ( আদর্শভাবে visibilitychange ইভেন্টে ) বিশ্লেষণে ফিরে যান। স্থানীয় পরীক্ষার জন্য আপনি পর্যায়ক্রমে console.table ব্যবহার করতে পারেন:

console.table(longestBlockingLoAFs);

দীর্ঘ অ্যানিমেশন ফ্রেমে সাধারণ নিদর্শন সনাক্ত করুন

একটি বিকল্প কৌশল হ'ল দীর্ঘ অ্যানিমেশন ফ্রেম এন্ট্রিগুলিতে সর্বাধিক প্রদর্শিত সাধারণ স্ক্রিপ্টগুলি দেখতে হবে। পুনরাবৃত্তি অপরাধীদের সনাক্ত করতে একটি স্ক্রিপ্ট এবং চরিত্রের অবস্থান স্তরে ডেটা আবার রিপোর্ট করা যেতে পারে।

এটি কাস্টমাইজযোগ্য প্ল্যাটফর্মের জন্য বিশেষভাবে ভাল কাজ করতে পারে যেখানে থিম বা প্লাগইনগুলি কর্মক্ষমতা সমস্যা সৃষ্টি করে এমন অনেক সাইট জুড়ে চিহ্নিত করা যেতে পারে।

দীর্ঘ অ্যানিমেশন ফ্রেমে সাধারণ স্ক্রিপ্ট-অথবা তৃতীয়-পক্ষের উৎপত্তি-এর সম্পাদনের সময় সংক্ষিপ্ত করা যেতে পারে এবং একটি সাইট বা সাইটগুলির একটি সংগ্রহ জুড়ে দীর্ঘ অ্যানিমেশন ফ্রেমে সাধারণ অবদানকারীদের সনাক্ত করতে আবার রিপোর্ট করা যেতে পারে। উদাহরণস্বরূপ 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});

এবং এই আউটপুটের উদাহরণ হল:

টুলিং এ লং অ্যানিমেশন ফ্রেম API ব্যবহার করুন

এপিআই স্থানীয় ডিবাগিংয়ের জন্য অতিরিক্ত ডেভেলপার টুলিংয়ের অনুমতি দেয়। যদিও কিছু টুলিং যেমন লাইটহাউস এবং ক্রোম ডেভটুল নিম্ন-স্তরের ট্রেসিং বিশদ ব্যবহার করে এই ডেটার বেশির ভাগ সংগ্রহ করতে সক্ষম হয়েছে, এই উচ্চ-স্তরের API থাকা অন্যান্য সরঞ্জামগুলিকে এই ডেটা অ্যাক্সেস করার অনুমতি দিতে পারে।

DevTools-এ সারফেস লং অ্যানিমেশন ফ্রেম ডেটা

আপনি performance.measure() API ব্যবহার করে DevTools-এ দীর্ঘ অ্যানিমেশন ফ্রেম দেখাতে পারেন, যেগুলি তারপরে পারফরম্যান্স ট্রেসে DevTools ব্যবহারকারীর টাইমিং ট্র্যাকে প্রদর্শিত হয় যাতে দেখা যায় কর্মক্ষমতা উন্নতির জন্য আপনার প্রচেষ্টাকে কোথায় ফোকাস করতে হবে। DevTools এক্সটেনসিবিলিটি API ব্যবহার করে এগুলি তাদের নিজস্ব ট্র্যাকেও দেখানো যেতে পারে:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    performance.measure('LoAF', {
      start: entry.startTime,
      end: entry.startTime + entry.duration,
      detail: {
        devtools: {
          dataType: "track-entry",
          track: "Long animation frames",
          trackGroup: "Performance Timeline",
          color: "tertiary-dark",
          tooltipText: 'LoAF'
        }
      }
    });
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

দীর্ঘমেয়াদী, দীর্ঘ অ্যানিমেশন ফ্রেমগুলি সম্ভবত DevTools-এর মধ্যেই অন্তর্ভুক্ত করা হবে, কিন্তু পূর্ববর্তী কোড স্নিপেট এটিকে ইতিমধ্যে সেখানে উপস্থিত হওয়ার অনুমতি দেয়।

আগের চিত্রের প্রথম এন্ট্রিটিও দেখায় যেখানে ব্রাউজারটি তাদের মধ্যে রেন্ডার না করে একই দীর্ঘ অ্যানিমেশন ফ্রেমে একসাথে বেশ কয়েকটি কাজ প্রক্রিয়া করেছে। পূর্বে উল্লিখিত হিসাবে এটি ঘটতে পারে যখন কোন উচ্চ-অগ্রাধিকার ইনপুট টাস্ক নেই, কিন্তু কাজের একটি সারি আছে। প্রথম দীর্ঘ টাস্কটি সম্পূর্ণ করার জন্য কিছু রেন্ডার আপডেট রয়েছে (অন্যথায় বর্তমান দীর্ঘ অ্যানিমেশন ফ্রেমটি এটির পরে পুনরায় সেট করা হবে এবং পরবর্তী টাস্ক দিয়ে একটি নতুন শুরু হবে), কিন্তু অবিলম্বে রেন্ডার হওয়া অ্যাকশনের পরিবর্তে, ব্রাউজারটি বেশ কয়েকটি প্রক্রিয়া করেছে অতিরিক্ত কাজ এবং শুধুমাত্র তারপর দীর্ঘ রেন্ডার টাস্ক অ্যাকশন এবং দীর্ঘ অ্যানিমেশন ফ্রেম শেষ. এটি বিলম্বিত রেন্ডার শনাক্ত করতে সাহায্য করার জন্য শুধুমাত্র দীর্ঘ টাস্কের পরিবর্তে DevTools-এ দীর্ঘ অ্যানিমেশন ফ্রেম দেখার উপযোগিতা প্রদর্শন করে।

অন্যান্য ডেভেলপার টুলিং-এ দীর্ঘ অ্যানিমেশন ফ্রেম ডেটা ব্যবহার করুন

ওয়েব ভাইটালস এক্সটেনশনটি কার্য সম্পাদনের সমস্যাগুলি নির্ণয় করার জন্য সারাংশ ডিবাগ তথ্য লগ করার মান দেখিয়েছে ।

এটি এখন প্রতিটি INP কলব্যাক এবং প্রতিটি ইন্টারঅ্যাকশনের জন্য দীর্ঘ অ্যানিমেশন ফ্রেম ডেটাও সারফেস করে:

স্বয়ংক্রিয় পরীক্ষার সরঞ্জামগুলিতে দীর্ঘ অ্যানিমেশন ফ্রেম ডেটা ব্যবহার করুন

একইভাবে সিআই/সিডি পাইপলাইনে স্বয়ংক্রিয় পরীক্ষার সরঞ্জামগুলি বিভিন্ন টেস্ট স্যুট চালানোর সময় দীর্ঘ অ্যানিমেশন ফ্রেম পরিমাপ করে সম্ভাব্য কার্যক্ষমতা সংক্রান্ত সমস্যাগুলির বিবরণ প্রকাশ করতে পারে।

FAQ

এই API-তে প্রায়শই জিজ্ঞাসিত প্রশ্নগুলির মধ্যে রয়েছে:

কেন শুধু দীর্ঘ টাস্ক API এ প্রসারিত বা পুনরাবৃত্তি করবেন না?

এটি সম্ভাব্য প্রতিক্রিয়াশীলতার সমস্যাগুলির একটি অনুরূপ-কিন্তু শেষ পর্যন্ত ভিন্ন-পরিমাপের প্রতিবেদন করার একটি বিকল্প চেহারা। বিদ্যমান লং টাস্ক API-এর উপর নির্ভরশীল সাইটগুলি বিদ্যমান ব্যবহারের ক্ষেত্রে ব্যাঘাত এড়াতে কাজ চালিয়ে যাচ্ছে তা নিশ্চিত করা গুরুত্বপূর্ণ।

যদিও লং টাস্ক এপিআই LoAF এর কিছু বৈশিষ্ট্য (যেমন একটি ভাল অ্যাট্রিবিউশন মডেল) থেকে উপকৃত হতে পারে, আমরা বিশ্বাস করি যে টাস্কের পরিবর্তে ফ্রেমের উপর ফোকাস করা অনেক সুবিধা দেয় যা এটিকে বিদ্যমান লং টাস্ক এপিআই থেকে একটি মৌলিকভাবে আলাদা API করে তোলে।

কেন আমার স্ক্রিপ্ট এন্ট্রি নেই?

এটি ইঙ্গিত দিতে পারে যে দীর্ঘ অ্যানিমেশন ফ্রেমটি JavaScipt এর কারণে নয়, বরং বড় রেন্ডার কাজের কারণে।

এটি তখনও ঘটতে পারে যখন দীর্ঘ অ্যানিমেশন ফ্রেম জাভাস্ক্রিপ্টের কারণে হয় কিন্তু যেখানে পূর্বে উল্লেখ করা বিভিন্ন গোপনীয়তার কারণে স্ক্রিপ্ট অ্যাট্রিবিউশন প্রদান করা যায় না (প্রাথমিকভাবে জাভাস্ক্রিপ্ট পৃষ্ঠার মালিকানাধীন নয়)।

কেন আমি স্ক্রিপ্ট এন্ট্রি আছে কিন্তু কোন, বা সীমিত, উৎস তথ্য আছে?

এটি বিভিন্ন কারণে ঘটতে পারে, যার মধ্যে নির্দেশ করার জন্য একটি ভাল উত্স না থাকা সহ।

no-cors cross-origin স্ক্রিপ্টগুলির জন্যও স্ক্রিপ্টের তথ্য সীমিত থাকবে, যদিও <script> কলে crossOrigin = "anonymous" যোগ করে CORS ব্যবহার করে সেই স্ক্রিপ্টগুলি আনার মাধ্যমে এটি সমাধান করা যেতে পারে।

উদাহরণস্বরূপ, পৃষ্ঠায় যোগ করার জন্য ডিফল্ট Google ট্যাগ ম্যানেজার স্ক্রিপ্ট:

<!-- 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 -->

j.crossOrigin = "anonymous" যোগ করার জন্য উন্নত করা যেতে পারে যাতে GTM-এর জন্য সম্পূর্ণ অ্যাট্রিবিউশন বিশদ প্রদান করা যায়

এটি কি লং টাস্ক API প্রতিস্থাপন করবে?

যদিও আমরা বিশ্বাস করি লং অ্যানিমেশন ফ্রেম এপিআই দীর্ঘ কাজ পরিমাপ করার জন্য একটি ভাল, আরও সম্পূর্ণ API, এই সময়ে, লং টাস্ক এপিআইকে অবমূল্যায়ন করার কোন পরিকল্পনা নেই।

প্রতিক্রিয়া চেয়েছিলেন

গিটহাব ইস্যু তালিকায় প্রতিক্রিয়া প্রদান করা যেতে পারে, বা ক্রোমের এপিআই বাস্তবায়নে বাগগুলি ক্রোমের ইস্যু ট্র্যাকারে ফাইল করা যেতে পারে।

উপসংহার

লং অ্যানিমেশন ফ্রেম API হল একটি উত্তেজনাপূর্ণ নতুন API যা আগের লং টাস্ক API এর তুলনায় অনেক সম্ভাব্য সুবিধা সহ।

এটি INP দ্বারা পরিমাপ করা প্রতিক্রিয়াশীলতার সমস্যাগুলি সমাধানের জন্য একটি মূল হাতিয়ার হিসাবে প্রমাণিত হচ্ছে৷ INP হল অপ্টিমাইজ করার জন্য একটি চ্যালেঞ্জিং মেট্রিক এবং এই API হল একটি উপায় যা Chrome টিম ডেভেলপারদের জন্য সমস্যাগুলি সনাক্ত করা এবং সমাধান করা সহজ করতে চাইছে৷

লং অ্যানিমেশন ফ্রেম এপিআই-এর সুযোগ শুধুমাত্র INP-এর বাইরেও প্রসারিত, এবং এটি ধীরগতির আপডেটের অন্যান্য কারণ চিহ্নিত করতে সাহায্য করতে পারে যা একটি ওয়েবসাইটের ব্যবহারকারীর অভিজ্ঞতার সামগ্রিক মসৃণতাকে প্রভাবিত করতে পারে।

স্বীকৃতি

আনস্প্ল্যাশে হেনরি বি -এর থাম্বনেইল ছবি।

Barry Pollard

Noam Rosenthal

লং অ্যানিমেশন ফ্রেম এপিআই (LoAF-উচ্চারিত Lo-Af) হল লং টাস্ক এপিআই- এর একটি আপডেট যাতে স্লো ইউজার ইন্টারফেস (UI) আপডেটগুলি আরও ভালভাবে বোঝা যায়। এটি ধীরগতির অ্যানিমেশন ফ্রেমগুলি সনাক্ত করতে কার্যকর হতে পারে যা ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (আইএনপি) কোর ওয়েব ভাইটাল মেট্রিককে প্রভাবিত করতে পারে যা প্রতিক্রিয়াশীলতা পরিমাপ করে, বা অন্যান্য UI জ্যাঙ্ক সনাক্ত করতে যা মসৃণতাকে প্রভাবিত করে।

API এর স্থিতি

Chrome 116 থেকে Chrome 122-এ একটি অরিজিন ট্রায়াল অনুসরণ করে, LoAF API Chrome 123 থেকে পাঠানো হয়েছে।

পটভূমি: লং টাস্ক API

লং অ্যানিমেশন ফ্রেম এপিআই হল লং টাস্ক এপিআই এর একটি বিকল্প যা কিছু সময়ের জন্য ক্রোমে উপলব্ধ (ক্রোম 58 থেকে)। এর নাম অনুসারে, লং টাস্ক এপিআই আপনাকে দীর্ঘ কাজগুলির জন্য নিরীক্ষণ করতে দেয়, যেগুলি 50 মিলিসেকেন্ড বা তার বেশি সময়ের জন্য মূল থ্রেড দখল করে। একটি PeformanceObserver সাহায্যে PerformanceLongTaskTiming ইন্টারফেস ব্যবহার করে দীর্ঘ কাজগুলি পর্যবেক্ষণ করা যেতে পারে:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'longtask', buffered: true });

দীর্ঘ কাজগুলি প্রতিক্রিয়াশীলতার সমস্যার কারণ হতে পারে। যদি একজন ব্যবহারকারী একটি পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করার চেষ্টা করে-উদাহরণস্বরূপ, একটি বোতামে ক্লিক করুন, বা একটি মেনু খুলুন-কিন্তু মূল থ্রেডটি ইতিমধ্যেই একটি দীর্ঘ টাস্ক নিয়ে কাজ করছে, তাহলে ব্যবহারকারীর মিথস্ক্রিয়া সেই কাজটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করতে বিলম্বিত হয় ।

প্রতিক্রিয়াশীলতা উন্নত করতে, প্রায়শই দীর্ঘ কাজগুলি ভেঙে ফেলার পরামর্শ দেওয়া হয়। যদি প্রতিটি দীর্ঘ টাস্ককে একাধিক, ছোট টাস্কের একটি সিরিজে বিভক্ত করা হয়, তবে এটি মিথস্ক্রিয়াগুলিতে প্রতিক্রিয়া জানাতে উল্লেখযোগ্য বিলম্ব এড়াতে তাদের মধ্যে আরও গুরুত্বপূর্ণ কাজগুলি সম্পাদন করার অনুমতি দিতে পারে।

তাই প্রতিক্রিয়াশীলতা উন্নত করার চেষ্টা করার সময়, প্রথম প্রচেষ্টাটি প্রায়শই একটি পারফরম্যান্স ট্রেস চালানো এবং দীর্ঘ কাজগুলি দেখতে হয়। এটি লাইটহাউসের মতো একটি ল্যাব-ভিত্তিক অডিটিং টুলের মাধ্যমে হতে পারে (যাতে একটি এড়িয়ে চলা দীর্ঘ প্রধান-থ্রেড টাস্ক অডিট রয়েছে), অথবা Chrome DevTools-এ দীর্ঘ কাজগুলি দেখে ।

ল্যাব-ভিত্তিক পরীক্ষা প্রায়শই প্রতিক্রিয়াশীলতার সমস্যাগুলি সনাক্ত করার জন্য একটি দুর্বল সূচনা স্থান , কারণ এই সরঞ্জামগুলিতে মিথস্ক্রিয়া অন্তর্ভুক্ত নাও হতে পারে—যখন তারা করে, তারা সম্ভাব্য মিথস্ক্রিয়াগুলির একটি ছোট উপসেট। আদর্শভাবে, আপনি ক্ষেত্রের ধীর মিথস্ক্রিয়াগুলির কারণগুলি পরিমাপ করবেন।

লং টাস্ক এপিআই এর ত্রুটি

একটি পারফরম্যান্স পর্যবেক্ষক ব্যবহার করে ক্ষেত্রের দীর্ঘ কাজগুলি পরিমাপ করা শুধুমাত্র কিছুটা কার্যকর। বাস্তবে, এটি এত বেশি তথ্য দেয় না যে একটি দীর্ঘ কাজ ঘটেছে, এবং কত সময় লেগেছে।

রিয়েল ইউজার মনিটরিং (RUM) টুলগুলি প্রায়শই এটি ব্যবহার করে দীর্ঘ টাস্কের সংখ্যা বা সময়কাল প্রবণতা বা কোন পৃষ্ঠায় তারা ঘটছে তা চিহ্নিত করতে - কিন্তু দীর্ঘ টাস্কের কারণের অন্তর্নিহিত বিবরণ ছাড়াই, এটি শুধুমাত্র সীমিত ব্যবহারের জন্য। লং টাস্ক এপিআই-এর শুধুমাত্র একটি বেসিক অ্যাট্রিবিউশন মডেল রয়েছে, যা সর্বোত্তমভাবে আপনাকে কেবল কন্টেইনারটি বলে দেয় যে দীর্ঘ কাজটি ঘটেছে (শীর্ষ-স্তরের নথি বা একটি <iframe> ), কিন্তু স্ক্রিপ্ট বা ফাংশনটি নয় যা এটিকে বলে, যেমন দেখানো হয়েছে একটি সাধারণ এন্ট্রি:

{
  "name": "unknown",
  "entryType": "longtask",
  "startTime": 31.799999997019768,
  "duration": 136,
  "attribution": [
    {
      "name": "unknown",
      "entryType": "taskattribution",
      "startTime": 0,
      "duration": 0,
      "containerType": "window",
      "containerSrc": "",
      "containerId": "",
      "containerName": ""
    }
  ]
}

লং টাস্ক এপিআইও একটি অসম্পূর্ণ দৃশ্য, কারণ এটি কিছু গুরুত্বপূর্ণ কাজ বাদ দিতে পারে। কিছু আপডেট—যেমন রেন্ডারিং—বিচ্ছিন্ন টাস্কে ঘটে যা আদর্শভাবে পূর্ববর্তী এক্সিকিউশনের সাথে একত্রে অন্তর্ভুক্ত করা উচিত যা সেই আপডেটটিকে সেই ইন্টারঅ্যাকশনের জন্য "মোট কাজ" সঠিকভাবে পরিমাপ করতে দেয়। কাজের উপর নির্ভর করার সীমাবদ্ধতার আরও বিশদ বিবরণের জন্য, ব্যাখ্যাকারীর "যেখানে দীর্ঘ কাজগুলি কম হয়" বিভাগটি দেখুন।

চূড়ান্ত সমস্যা হল যে দীর্ঘ টাস্কগুলি পরিমাপ করা শুধুমাত্র পৃথক টাস্কগুলির রিপোর্ট করে যা 50 মিলিসেকেন্ড সীমার চেয়ে বেশি সময় নেয়। একটি অ্যানিমেশন ফ্রেম এই 50 মিলিসেকেন্ডের সীমার চেয়ে ছোট বেশ কয়েকটি কাজ নিয়ে গঠিত হতে পারে, তবুও সমষ্টিগতভাবে এখনও ব্রাউজারের রেন্ডার করার ক্ষমতাকে ব্লক করে।

দীর্ঘ অ্যানিমেশন ফ্রেম API

লং অ্যানিমেশন ফ্রেমস এপিআই (এলএএফ) একটি নতুন এপিআই যা বিকাশকারীদের প্রতিক্রিয়াশীলতার সমস্যাগুলি সমাধান করতে এবং আইএনপি উন্নত করতে আরও কার্যকরভাবে অন্তর্দৃষ্টি পেতে সক্ষম করার জন্য দীর্ঘ কার্যগুলি এপিআইয়ের কিছু ত্রুটিগুলি সমাধান করার চেষ্টা করে, পাশাপাশি মসৃণতার সমস্যাগুলির অন্তর্দৃষ্টি পেতে সক্ষম করে তোলে .

ভাল প্রতিক্রিয়াশীলতার অর্থ একটি পৃষ্ঠা এটির সাথে তৈরি মিথস্ক্রিয়ায় দ্রুত সাড়া দেয়। এর মধ্যে একটি সময় মতো ব্যবহারকারীর দ্বারা প্রয়োজনীয় কোনও আপডেট আঁকতে সক্ষম হওয়া এবং এই আপডেটগুলি ঘটতে বাধা দেওয়া এড়ানো জড়িত। আইএনপির জন্য, 200 মিলিসেকেন্ড বা তারও কম সময়ে প্রতিক্রিয়া জানানোর পরামর্শ দেওয়া হয় তবে অন্যান্য আপডেটের জন্য (উদাহরণস্বরূপ, অ্যানিমেশন) এমনকি 200 মিলিসেকেন্ডও খুব দীর্ঘ হতে পারে।

দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই ব্লকিং কাজ পরিমাপের একটি বিকল্প পন্থা। পৃথক কাজগুলি পরিমাপ করার পরিবর্তে, দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই - এর নাম হিসাবে প্রস্তাবিত - দীর্ঘ অ্যানিমেশন ফ্রেমগুলি নির্ধারণ করে। একটি দীর্ঘ অ্যানিমেশন ফ্রেম হ'ল যখন একটি রেন্ডারিং আপডেট 50 মিলিসেকেন্ডের বাইরে বিলম্বিত হয় (দীর্ঘ কার্য এপিআইয়ের প্রান্তিকের সমান)।

দীর্ঘ অ্যানিমেশন ফ্রেমগুলি এমন কাজগুলির শুরু থেকে পরিমাপ করা হয় যার জন্য একটি রেন্ডার প্রয়োজন। যেখানে সম্ভাব্য দীর্ঘ অ্যানিমেশন ফ্রেমের প্রথম কাজটি কোনও রেন্ডার প্রয়োজন হয় না, সেখানে দীর্ঘ অ্যানিমেশন ফ্রেমটি অ-রেন্ডারিং টাস্কটি শেষ হওয়ার পরে শেষ হয় এবং পরবর্তী কাজটি দিয়ে একটি নতুন সম্ভাব্য দীর্ঘ অ্যানিমেশন ফ্রেম শুরু করা হয়। সম্ভাব্য অবরুদ্ধ কাজের পরিমাপের অনুমতি দেওয়ার জন্য 50 মিলিসেকেন্ড (0 এর renderStart সময় সহ) এর চেয়ে বেশি সময় এ জাতীয় নন-রেন্ডারিং দীর্ঘ অ্যানিমেশন ফ্রেম এখনও দীর্ঘ অ্যানিমেশন ফ্রেম এপিআইতে অন্তর্ভুক্ত রয়েছে।

দীর্ঘ অ্যানিমেশন ফ্রেমগুলি PerformanceObserver সাথে দীর্ঘ কাজের মতো একইভাবে পর্যবেক্ষণ করা যেতে পারে তবে পরিবর্তে long-animation-frame প্রকারের দিকে তাকানো:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'long-animation-frame', buffered: true });

পূর্ববর্তী দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পারফরম্যান্স টাইমলাইন থেকেও অনুসন্ধান করা যেতে পারে:

const loafs = performance.getEntriesByType('long-animation-frame');

যাইহোক, পারফরম্যান্স এন্ট্রিগুলির জন্য একটি maxBufferSize রয়েছে যার পরে আরও নতুন এন্ট্রিগুলি বাদ দেওয়া হয়, সুতরাং পারফরম্যান্সঅবসার্ভার পদ্ধতির প্রস্তাবিত পদ্ধতির। long-animation-frame বাফার আকার 200 এ সেট করা হয়েছে, long-tasks জন্য একই।

কাজের পরিবর্তে ফ্রেম দেখার সুবিধা

কার্য দৃষ্টিভঙ্গির পরিবর্তে ফ্রেমের দৃষ্টিকোণ থেকে এটিকে দেখার মূল সুবিধাটি হ'ল একটি দীর্ঘ অ্যানিমেশনটি যে কোনও সংখ্যক কাজ নিয়ে গঠিত হতে পারে যা দীর্ঘস্থায়ীভাবে একটি দীর্ঘ অ্যানিমেশন ফ্রেমের ফলস্বরূপ। এটি পূর্বে উল্লিখিত চূড়ান্ত পয়েন্টটিকে সম্বোধন করে, যেখানে অ্যানিমেশন ফ্রেমের আগে অনেকগুলি ছোট, রেন্ডার-ব্লকিং কার্যগুলির যোগফল দীর্ঘ টাস্ক এপিআই দ্বারা প্রকাশিত না হতে পারে।

দীর্ঘ কার্যগুলিতে এই বিকল্প দৃষ্টিভঙ্গির আরও একটি সুবিধা হ'ল পুরো ফ্রেমের সময় ভাঙ্গন সরবরাহ করার ক্ষমতা। দীর্ঘ টাস্ক এপিআইয়ের মতো কেবল একটি startTime এবং একটি duration অন্তর্ভুক্ত করার পরিবর্তে, লফের ফ্রেমের সময়কালের বিভিন্ন অংশের আরও অনেক বিশদ ভাঙ্গন অন্তর্ভুক্ত রয়েছে।

ফ্রেম টাইমস্ট্যাম্প এবং সময়সীমা

• startTime : নেভিগেশন শুরুর সময়ের সাথে সম্পর্কিত দীর্ঘ অ্যানিমেশন ফ্রেমের শুরুর সময়।
• duration : দীর্ঘ অ্যানিমেশন ফ্রেমের সময়কাল (উপস্থাপনার সময় সহ নয়)।
• renderStart : রেন্ডারিং চক্রের শুরুর সময়, যার মধ্যে requestAnimationFrame কলব্যাকস, স্টাইল এবং লেআউট গণনা অন্তর্ভুক্ত রয়েছে, পর্যবেক্ষক এবং ছেদ পর্যবেক্ষক কলব্যাকগুলি পুনরায় আকার দিন।
• styleAndLayoutStart : স্টাইল এবং লেআউট গণনায় ব্যয় করা সময়কালের সূচনা।
• firstUIEventTimestamp : এই ফ্রেমটি চলাকালীন প্রথম ইউআই ইভেন্টের (মাউস/কীবোর্ড এবং আরও) সময়টি পরিচালনা করা হবে।
• blockingDuration : মিলিসেকেন্ডে মোট সময়কাল যার জন্য অ্যানিমেশন ফ্রেম ইনপুট বা অন্যান্য উচ্চ অগ্রাধিকারের কার্যগুলির প্রক্রিয়াজাতকরণকে অবরুদ্ধ করবে।

blockingDuration এর ব্যাখ্যা

একটি দীর্ঘ অ্যানিমেশন ফ্রেম বেশ কয়েকটি কাজ নিয়ে গঠিত হতে পারে। blockingDuration হ'ল 50 মিলিসেকেন্ডের চেয়ে দীর্ঘ টাস্কের সময়কালের যোগফল (দীর্ঘতম কাজের মধ্যে চূড়ান্ত রেন্ডার সময়কাল সহ)।

উদাহরণস্বরূপ, যদি একটি দীর্ঘ অ্যানিমেশন ফ্রেমটি 55 মিলিসেকেন্ড এবং 65 মিলিসেকেন্ডের দুটি কাজ দিয়ে তৈরি করা হয় এবং তারপরে 20 মিলিসেকেন্ডের রেন্ডার থাকে তবে duration প্রায় 140 মিলিসেকেন্ডে (55 - 50) + (65 + 20 এর blockingDuration সহ হবে (65 + 20 - 50) = 40 মিলিসেকেন্ড। এই 140 মিলিসেকেন্ড দীর্ঘ অ্যানিমেশন ফ্রেমের সময় 40 মিলিসেকেন্ডের জন্য, ফ্রেমটি ইনপুট হ্যান্ডলিং থেকে অবরুদ্ধ হিসাবে বিবেচিত হয়েছিল।

duration বা blockingDuration দেখুন কিনা

সাধারণ 60 হার্টজ প্রদর্শনের জন্য, একটি ব্রাউজার কমপক্ষে প্রতি 16.66 মিলিসেকেন্ড (মসৃণ আপডেটগুলি নিশ্চিত করতে) বা ইনপুট হ্যান্ডলিংয়ের মতো উচ্চ অগ্রাধিকারের কার্য (প্রতিক্রিয়াশীল আপডেটগুলি নিশ্চিত করার জন্য) এর পরে একটি ফ্রেমের সময়সূচী করার চেষ্টা করবে। তবে, যদি কোনও ইনপুট না থাকে-বা অন্যান্য উচ্চ-অগ্রাধিকারের কাজগুলি-তবে অন্যান্য কাজের একটি সারি রয়েছে, তবে ব্রাউজারটি সাধারণত বর্তমান ফ্রেমটি 16.66 মিলিসেকেন্ডকে ভালভাবে চালিয়ে যাবে যেগুলি এর মধ্যে কাজগুলি যত ভালভাবে ভাঙা হোক না কেন। এটি হ'ল, ব্রাউজারটি সর্বদা ইনপুটগুলিকে অগ্রাধিকার দেওয়ার চেষ্টা করবে, তবে রেন্ডার আপডেটের তুলনায় কার্যগুলির একটি সারি মোকাবেলা করতে বেছে নিতে পারে। এটি একটি ব্যয়বহুল প্রক্রিয়া হিসাবে রেন্ডারিংয়ের কারণে তাই একাধিক কাজের জন্য সম্মিলিত রেন্ডারিং টাস্ক প্রক্রিয়াজাতকরণ সাধারণত কাজের সামগ্রিক হ্রাসের দিকে পরিচালিত করে।

অতএব, কম বা শূন্য blockingDuration সহ দীর্ঘ অ্যানিমেশন ফ্রেমগুলি এখনও ইনপুটটির প্রতি প্রতিক্রিয়াশীল বোধ করা উচিত। দীর্ঘ কাজগুলি ভেঙে blockingDuration হ্রাস বা নির্মূল করা তাই আইএনপি দ্বারা পরিমাপ করা প্রতিক্রিয়াশীলতা উন্নত করার মূল বিষয়।

যাইহোক, blockingDuration নির্বিশেষে প্রচুর দীর্ঘ অ্যানিমেশন ফ্রেমগুলি ইউআই আপডেটগুলি নির্দেশ করে যা বিলম্বিত হয় এবং তাই এখনও মসৃণতা প্রভাবিত করতে পারে এবং স্ক্রোলিং বা অ্যানিমেশনগুলির জন্য একটি ল্যাজি ইউজার ইন্টারফেসের অনুভূতির দিকে পরিচালিত করতে পারে, এমনকি যদি এগুলি প্রতিক্রিয়াশীলতার জন্য কম সমস্যা হয় তবে এগুলি যদি কম হয় আইএনপি দ্বারা পরিমাপ করা। এই অঞ্চলে সমস্যাগুলি বোঝার জন্য duration দেখুন, তবে এগুলি অনুকূলিতকরণ করা আরও জটিল হতে পারে যেহেতু আপনি কাজ ভেঙে এটি সমাধান করতে পারবেন না, তবে পরিবর্তে অবশ্যই কাজ হ্রাস করতে হবে।

ফ্রেম সময়

পূর্বে উল্লিখিত টাইমস্ট্যাম্পগুলি দীর্ঘ অ্যানিমেশন ফ্রেমটিকে সময়গুলিতে বিভক্ত করার অনুমতি দেয়:

আরও ভাল স্ক্রিপ্ট অ্যাট্রিবিউশন

long-animation-frame এন্ট্রি টাইপটিতে প্রতিটি স্ক্রিপ্টের আরও ভাল অ্যাট্রিবিউশন ডেটা অন্তর্ভুক্ত রয়েছে যা একটি দীর্ঘ অ্যানিমেশন ফ্রেমে অবদান রাখে (স্ক্রিপ্টগুলির জন্য 5 মিলিসেকেন্ডের চেয়ে বেশি দীর্ঘ)।

দীর্ঘ কার্য এপিআইয়ের মতো, এটি অ্যাট্রিবিউশন এন্ট্রিগুলির একটি অ্যারে সরবরাহ করা হবে, যার প্রতিটি বিশদ:

• একটি name এবং EntryType উভয়ই script ফিরিয়ে দেবে।
• স্ক্রিপ্টটিকে কীভাবে বলা হয়েছিল তা নির্দেশ করে একটি অর্থপূর্ণ invoker (উদাহরণস্বরূপ, 'IMG#id.onload' , 'Window.requestAnimationFrame' , বা 'Response.json.then' )।
• স্ক্রিপ্ট এন্ট্রি পয়েন্টের invokerType :
  • user-callback : একটি ওয়েব প্ল্যাটফর্ম এপিআই থেকে নিবন্ধিত একটি পরিচিত কলব্যাক (উদাহরণস্বরূপ, setTimeout , requestAnimationFrame )।
  • event-listener : একটি প্ল্যাটফর্ম ইভেন্টের শ্রোতা (উদাহরণস্বরূপ, click , load , keyup )।
  • resolve-promise : একটি প্ল্যাটফর্ম প্রতিশ্রুতির হ্যান্ডলার (উদাহরণস্বরূপ, fetch() । নোট করুন যে প্রতিশ্রুতিগুলির ক্ষেত্রে, একই প্রতিশ্রুতিগুলির সমস্ত হ্যান্ডলার একসাথে একটি "স্ক্রিপ্ট" হিসাবে মিশ্রিত করা হয়) .
  • reject-promise : resolve-promise অনুসারে, তবে প্রত্যাখ্যানের জন্য।
  • classic-script : স্ক্রিপ্ট মূল্যায়ন (উদাহরণস্বরূপ, <script> বা import() )
  • module-script : classic-script মতো, তবে মডিউল স্ক্রিপ্টগুলির জন্য।
• সেই স্ক্রিপ্টের জন্য পৃথক সময় ডেটা পৃথক করুন:
  • startTime : সময় এন্ট্রি ফাংশনটি অনুরোধ করা হয়েছিল।
  • duration : startTime এবং পরবর্তী সময়ে মাইক্রোটাস্ক সারিটি যখন প্রক্রিয়াজাতকরণ শেষ করে তখন সময়কাল।
  • executionStart : সংকলনের পরে সময়।
  • forcedStyleAndLayoutDuration : এই ফাংশনটির ভিতরে জোর করে লেআউট এবং স্টাইল প্রক্রিয়াজাতকরণ ব্যয় করা মোট সময় ব্যয় করে ( থ্র্যাশিং দেখুন)।
  • pauseDuration : "বিরতি" সিঙ্ক্রোনাস অপারেশনগুলিতে মোট সময় ব্যয় করা (সতর্কতা, সিঙ্ক্রোনাস এক্সএইচআর)।
• স্ক্রিপ্ট উত্স বিশদ:
  • sourceURL : স্ক্রিপ্ট রিসোর্সের নাম যেখানে পাওয়া যায় (বা যদি পাওয়া যায় না খালি)।
  • sourceFunctionName : স্ক্রিপ্ট ফাংশনের নাম যেখানে পাওয়া যায় (বা যদি না পাওয়া যায় তবে খালি)।
  • sourceCharPosition : স্ক্রিপ্ট চরিত্রের অবস্থান যেখানে পাওয়া যায় (বা -1 যদি পাওয়া যায় না)।
• windowAttribution : ধারকটি (শীর্ষ স্তরের নথি, বা একটি <iframe> >) দীর্ঘ অ্যানিমেশন ফ্রেমটি ঘটেছে।
• window : একই-উত্স উইন্ডোতে একটি রেফারেন্স।

যেখানে সরবরাহ করা হয়েছে, সোর্স এন্ট্রিগুলি বিকাশকারীদের ঠিক কীভাবে দীর্ঘ অ্যানিমেশন ফ্রেমের প্রতিটি স্ক্রিপ্টকে কলিং স্ক্রিপ্টে চরিত্রের অবস্থানে নামিয়ে দেওয়া হয়েছিল তা জানতে দেয়। এটি একটি জাভাস্ক্রিপ্ট রিসোর্সে সঠিক অবস্থান দেয় যা দীর্ঘ অ্যানিমেশন ফ্রেমের ফলস্বরূপ।

long-animation-frame পারফরম্যান্স এন্ট্রি উদাহরণ

একক স্ক্রিপ্টযুক্ত একটি সম্পূর্ণ long-animation-frame পারফরম্যান্স এন্ট্রি উদাহরণ, এটি:

{
  "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
}

যেমনটি দেখা যায়, এটি ওয়েবসাইটগুলির জন্য লেগি রেন্ডারিং আপডেটের কারণ বুঝতে সক্ষম হওয়ার জন্য একটি অভূতপূর্ব পরিমাণ ডেটা দেয়।

মাঠে দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই ব্যবহার করুন

ক্রোম ডেভটুলস এবং বাতিঘরগুলির মতো সরঞ্জামগুলি - সমস্যাগুলি আবিষ্কার ও পুনরুত্পাদন করার জন্য দরকারী - এমন ল্যাব সরঞ্জামগুলি যা ব্যবহারকারীর অভিজ্ঞতার গুরুত্বপূর্ণ দিকগুলি মিস করতে পারে যা কেবলমাত্র ক্ষেত্রের ডেটা সরবরাহ করতে পারে।

দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই ব্যবহারকারী ইন্টারঅ্যাকশনগুলির জন্য গুরুত্বপূর্ণ প্রাসঙ্গিক ডেটা সংগ্রহ করতে ক্ষেত্রটিতে ব্যবহার করার জন্য ডিজাইন করা হয়েছে যা দীর্ঘ কার্যগুলি এপিআই করতে পারেনি। এটি আপনাকে ইন্টারঅ্যাক্টিভিটির সাথে সমস্যাগুলি সনাক্ত করতে এবং পুনরুত্পাদন করতে সহায়তা করতে পারে যা আপনি অন্যথায় আবিষ্কার করতে পারেন নি।

দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই সমর্থন সনাক্তকরণ বৈশিষ্ট্য

আপনি যদি এপিআই সমর্থিত হয় তবে আপনি নিম্নলিখিত কোডটি ব্যবহার করতে পারেন:

if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
  // Monitor LoAFs
}

দীর্ঘতম আইএনপি ইন্টারঅ্যাকশন লিঙ্ক

দীর্ঘ অ্যানিমেশন ফ্রেম এপিআইয়ের জন্য সর্বাধিক সুস্পষ্ট ব্যবহারের কেসটি হ'ল পরবর্তী পেইন্ট (আইএনপি) ইস্যুতে ইন্টারঅ্যাকশন নির্ণয় এবং ঠিক করতে সহায়তা করা এবং ক্রোম টিম এই এপিআই বিকাশের অন্যতম মূল কারণ ছিল। একটি ভাল আইএনপি হ'ল যেখানে সমস্ত ইন্টারঅ্যাকশনগুলি 200 মিলিসেকেন্ডে প্রতিক্রিয়া জানায় যে ফ্রেমটি আঁকা না হওয়া পর্যন্ত ইন্টারঅ্যাকশন থেকে কম ইন্টারঅ্যাকশন থেকে কম হয় এবং যেহেতু দীর্ঘ অ্যানিমেশন ফ্রেমগুলি এপিআই 50 মিমি বা তার বেশি নেয় এমন সমস্ত ফ্রেমগুলি পরিমাপ করে, বেশিরভাগ সমস্যাযুক্ত আইএনপিগুলিতে আপনাকে ডায়াগনোসিসকে সহায়তা করার জন্য লফ ডেটা অন্তর্ভুক্ত করা উচিত যারা মিথস্ক্রিয়া.

"ইনপ লফ" হ'ল রুটি যা ইনপ ইন্টারঅ্যাকশন অন্তর্ভুক্ত করে, যেমনটি নিম্নলিখিত চিত্রটিতে দেখানো হয়েছে:

কিছু ক্ষেত্রে কোনও আইএনপি ইভেন্টের পক্ষে দুটি লফকে ছড়িয়ে দেওয়া সম্ভব - সাধারণত যদি ফ্রেমটি পূর্ববর্তী ফ্রেমের রেন্ডারিং অংশটি শুরু করার পরে মিথস্ক্রিয়া হয় তবে এবং তাই ইভেন্ট হ্যান্ডলারটি পরবর্তী ফ্রেমে প্রক্রিয়াজাত করা হয়:

এমনকি এটি সম্ভব যে এটি কিছু বিরল পরিস্থিতিতে দুটি লফের বেশি বিস্তৃত হতে পারে।

আইএনপি ইন্টারঅ্যাকশনটির সাথে সম্পর্কিত লফ (গুলি) ডেটা রেকর্ডিং আপনাকে এটি নির্ণয় করতে সহায়তা করার জন্য আইএনপি ইন্টারঅ্যাকশন সম্পর্কে আরও অনেক তথ্য পেতে দেয়। এটি ইনপুট বিলম্ব বুঝতে বিশেষভাবে সহায়ক: আপনি দেখতে পাচ্ছেন যে সেই ফ্রেমে অন্যান্য স্ক্রিপ্টগুলি কী চলছে।

আপনার ইভেন্টের হ্যান্ডলাররা যদি অন্য স্ক্রিপ্টগুলি আপনার ব্যবহারকারীদের জন্য চলমান হতে পারে যা আপনার নিজের পরীক্ষায় অন্তর্ভুক্ত নাও হতে পারে তবে তাদের জন্য দেখা মানগুলি পুনরুত্পাদন না করে যদি অব্যক্ত প্রক্রিয়াজাতকরণের সময়কাল এবং উপস্থাপনার বিলম্ব বুঝতে সহায়ক হতে পারে।

এর সাথে সম্পর্কিত লফ এন্ট্রি বা এন্ট্রিগুলির সাথে কোনও আইএনপি এন্ট্রি লিঙ্ক করার জন্য কোনও সরাসরি এপিআই নেই , যদিও প্রতিটিটির শুরু এবং শেষের সময়গুলির তুলনা করে কোডে এটি করা সম্ভব ( WHONP উদাহরণ স্ক্রিপ্টটি দেখুন)। web-vitals লাইব্রেরিতে ভি 4 থেকে আইএনপি অ্যাট্রিবিউশন ইন্টারফেসের longAnimationFramesEntries সম্পত্তিতে সমস্ত ছেদকারী লফ অন্তর্ভুক্ত রয়েছে।

একবার আপনি লফ এন্ট্রি বা এন্ট্রিগুলি লিঙ্ক করে ফেললে, আপনি আইএনপি অ্যাট্রিবিউশন সহ তথ্য অন্তর্ভুক্ত করতে পারেন। scripts অবজেক্টে কিছু মূল্যবান তথ্য রয়েছে কারণ এটি দেখাতে পারে যে সেই ফ্রেমগুলিতে আর কী চলছে তাই আপনার অ্যানালিটিক্স পরিষেবাতে ডেটা ব্যাকনিং করে আপনাকে কেন ইন্টারঅ্যাকশনগুলি ধীর ছিল সে সম্পর্কে আরও বুঝতে আপনাকে অনুমতি দেবে।

আইএনপি ইন্টারঅ্যাকশনটির জন্য লফগুলি প্রতিবেদন করা আপনার পৃষ্ঠায় সর্বাধিক চাপযুক্ত ইন্টারেক্টিভিটি সমস্যাগুলি কী তা খুঁজে পাওয়ার একটি ভাল উপায়। প্রতিটি ব্যবহারকারী আপনার পৃষ্ঠার সাথে এবং আইএনপি অ্যাট্রিবিউশন ডেটার পর্যাপ্ত পরিমাণের সাথে আলাদাভাবে ইন্টারঅ্যাক্ট করতে পারে, বেশ কয়েকটি সম্ভাব্য সমস্যা আইএনপি অ্যাট্রিবিউশন ডেটাতে অন্তর্ভুক্ত করা হবে। কোন স্ক্রিপ্টগুলি ধীর আইএনপি -র সাথে সম্পর্কিত করছে তা দেখতে এটি আপনাকে ভলিউম অনুসারে স্ক্রিপ্টগুলি বাছাই করতে দেয়।

আরও দীর্ঘ অ্যানিমেশন ডেটা একটি বিশ্লেষণ শেষ পয়েন্টে ফিরে রিপোর্ট করুন

কেবলমাত্র আইএনপি রুটি (গুলি) দেখার জন্য একটি নেতিবাচক দিক, আপনি কি ভবিষ্যতের আইএনপি সমস্যার কারণ হতে পারে এমন উন্নতির জন্য অন্যান্য সম্ভাব্য ক্ষেত্রগুলি মিস করতে পারেন। এটি আপনার লেজটি তাড়া করার অনুভূতির দিকে পরিচালিত করতে পারে যেখানে আপনি একটি আইএনপি ইস্যুটিকে একটি বিশাল উন্নতি দেখার প্রত্যাশা করে ঠিক করেন, কেবল পরবর্তী ধীরতম মিথস্ক্রিয়াটি খুঁজে পাওয়া তার চেয়ে সামান্য পরিমাণ ভাল তাই আপনার আইএনপি খুব বেশি উন্নতি না করে।

সুতরাং কেবল আইএনপি রুটি দেখার চেয়ে আপনি পৃষ্ঠায় সমস্ত লফগুলি আজীবন বিবেচনা করতে চাইতে পারেন:

যাইহোক, প্রতিটি লফ এন্ট্রিতে যথেষ্ট ডেটা রয়েছে, সুতরাং আপনি সম্ভবত আপনার বিশ্লেষণকে কেবল কিছু লফের মধ্যে সীমাবদ্ধ করতে চাইবেন। অতিরিক্তভাবে, দীর্ঘ অ্যানিমেশন ফ্রেম এন্ট্রিগুলি বেশ বড় হতে পারে, বিকাশকারীদের এন্ট্রি থেকে কোন ডেটা বিশ্লেষণে প্রেরণ করা উচিত তা সিদ্ধান্ত নেওয়া উচিত। উদাহরণস্বরূপ, প্রবেশের সংক্ষিপ্ত সময় এবং সম্ভবত স্ক্রিপ্টের নাম, বা প্রয়োজনীয় বলে মনে করা যেতে পারে এমন অন্যান্য প্রাসঙ্গিক ডেটার অন্য কোনও ন্যূনতম সেট।

দীর্ঘ অ্যানিমেশন ফ্রেম ডেটার পরিমাণ হ্রাস করার জন্য কিছু প্রস্তাবিত নিদর্শন অন্তর্ভুক্ত রয়েছে:

• ইন্টারঅ্যাকশন সহ দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন
• উচ্চ ব্লকিং সময়সীমার সাথে দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন
• মসৃণতা উন্নত করতে সমালোচনামূলক ইউআই আপডেটের সময় দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন
• সবচেয়ে খারাপ দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন
• দীর্ঘ অ্যানিমেশন ফ্রেমে সাধারণ নিদর্শনগুলি সনাক্ত করুন

এই নিদর্শনগুলির মধ্যে কোনটি আপনার পক্ষে সবচেয়ে ভাল কাজ করে, আপনার অপ্টিমাইজেশনের যাত্রা আপনি কতটা দূরে এবং দীর্ঘ অ্যানিমেশন ফ্রেমগুলি কতটা সাধারণ তা নির্ভর করে। এমন কোনও সাইটের জন্য যা আগে কখনও প্রতিক্রিয়াশীলতার জন্য অনুকূলিত হয়নি, এমন অনেকগুলি লফ থাকতে পারে যা আপনি কেবল ইন্টারঅ্যাকশন সহ কেবল রুটিতে সীমাবদ্ধ রাখতে পারেন, বা একটি উচ্চ প্রান্তিক সেট করতে পারেন বা কেবল সবচেয়ে খারাপের দিকে নজর দিতে পারেন।

আপনি আপনার সাধারণ প্রতিক্রিয়াশীলতার সমস্যাগুলি সমাধান করার সাথে সাথে আপনি কেবল মিথস্ক্রিয়া বা উচ্চ ব্লকিং সময়সীমার মধ্যে সীমাবদ্ধ না করে বা থ্রেশহোল্ডগুলি হ্রাস করে এটি প্রসারিত করতে পারেন।

ইন্টারঅ্যাকশন সহ দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন

কেবলমাত্র আইএনপি লং অ্যানিমেশন ফ্রেমের বাইরে অন্তর্দৃষ্টি পেতে, আপনি উচ্চ blockingDuration সহ ইন্টারঅ্যাকশন (যা firstUIEventTimestamp মানের উপস্থিতি দ্বারা সনাক্ত করা যায়) সহ সমস্ত লফগুলি দেখতে পারেন।

এটি দু'জনের সাথে সম্পর্ক স্থাপনের চেষ্টা না করে আইএনপি লফগুলি পর্যবেক্ষণ করার একটি সহজ পদ্ধতিও হতে পারে, যা আরও জটিল হতে পারে। বেশিরভাগ ক্ষেত্রে এটিতে প্রদত্ত দর্শনটির জন্য ইনপি লফ অন্তর্ভুক্ত করা হবে এবং বিরল ক্ষেত্রে যখন এটি এখনও দীর্ঘ মিথস্ক্রিয়াগুলিকে ঠিক করা গুরুত্বপূর্ণ যেগুলি ঠিক করা গুরুত্বপূর্ণ, কারণ তারা অন্যান্য ব্যবহারকারীদের জন্য আইএনপি ইন্টারঅ্যাকশন হতে পারে।

নিম্নলিখিত কোডটি 100 মিলিসেকেন্ডের চেয়ে বেশি blockingDuration সহ সমস্ত লফ এন্ট্রি লগ করে যেখানে ফ্রেমের সময় একটি মিথস্ক্রিয়া ঘটেছিল। 100 এখানে বেছে নেওয়া হয়েছে কারণ এটি 200 মিলিসেকেন্ড "ভাল" আইএনপি থ্রেশহোল্ডের চেয়ে কম। আপনি আপনার প্রয়োজনের উপর নির্ভর করে একটি উচ্চ বা নিম্ন মান চয়ন করতে পারেন।

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.blockingDuration > 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 });

উচ্চ ব্লকিং সময়সীমার সাথে দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন

ইন্টারঅ্যাকশনগুলির সাথে সমস্ত দীর্ঘ অ্যানিমেশন ফ্রেমগুলি দেখার উন্নতি হিসাবে, আপনি উচ্চ ব্লকিং সময়সীমার সাথে সমস্ত দীর্ঘ অ্যানিমেশন ফ্রেমগুলি দেখতে চাইতে পারেন। যদি কোনও ব্যবহারকারী এই দীর্ঘ অ্যানিমেশন ফ্রেমের সময় ইন্টারঅ্যাক্ট করে তবে এগুলি সম্ভাব্য আইএনপি সমস্যাগুলি নির্দেশ করে।

নিম্নলিখিত কোডটি 100 মিলিসেকেন্ডের চেয়ে বেশি ব্লকিং সময়কালের সাথে সমস্ত লফ এন্ট্রি লগ করে যেখানে ফ্রেমের সময় একটি মিথস্ক্রিয়া ঘটেছিল। 100 টি এখানে বেছে নেওয়া হয়েছে কারণ এটি সম্ভাব্য সমস্যার ফ্রেমগুলি সনাক্ত করতে সহায়তা করার জন্য 200 মিলিসেকেন্ড "ভাল" আইএনপি প্রান্তিকের চেয়ে কম, যখন ন্যূনতম অ্যানিমেশন ফ্রেমের পরিমাণ ন্যূনতম হিসাবে রিপোর্ট করে। আপনি আপনার প্রয়োজনের উপর নির্ভর করে একটি উচ্চ বা নিম্ন মান চয়ন করতে পারেন।

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.blockingDuration > 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 });

মসৃণতা উন্নত করতে সমালোচনামূলক ইউআই আপডেটের সময় দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন

পূর্বে উল্লিখিত হিসাবে, উচ্চ ব্লকিং সময়কাল দীর্ঘ অ্যানিমেশন ফ্রেমের দিকে তাকানো ইনপুট প্রতিক্রিয়াশীলতা মোকাবেলায় সহায়তা করতে পারে। তবে মসৃণতার জন্য আপনার দীর্ঘ duration সাথে সমস্ত দীর্ঘ অ্যানিমেশন ফ্রেমের দিকে নজর দেওয়া উচিত।

যেহেতু, এটি বেশ গোলমাল পেতে পারে আপনি এই জাতীয় প্যাটার্ন সহ মূল পয়েন্টগুলিতে এই পরিমাপগুলি সীমাবদ্ধ করতে চাইতে পারেন:

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  if (measureImportantUIupdate) {
    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 });

async function doUIUpdatesWithMeasurements() {
  measureImportantUIupdate = true;
  await doUIUpdates();
  measureImportantUIupdate = false;
}

সবচেয়ে খারাপ দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পর্যবেক্ষণ করুন

একটি সেট থ্রেশহোল্ড থাকার পরিবর্তে, সাইটগুলি বেকনড হওয়া দরকার এমন ডেটার পরিমাণ হ্রাস করতে দীর্ঘতম অ্যানিমেশন ফ্রেম (বা ফ্রেম) এ ডেটা সংগ্রহ করতে চাইতে পারে। সুতরাং কোনও পৃষ্ঠার অভিজ্ঞতা কত দীর্ঘ অ্যানিমেশন ফ্রেমগুলিই হোক না কেন, কেবলমাত্র সবচেয়ে খারাপের জন্য ডেটা, পাঁচ, দশ বা তবে অনেকগুলি দীর্ঘ অ্যানিমেশন ফ্রেম একেবারে প্রয়োজনীয়।

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 });

এই কৌশলগুলিও একত্রিত হতে পারে - কেবলমাত্র 10 টি সবচেয়ে খারাপ লফের দিকে নজর দেওয়া, 100 মিলিসেকেন্ডের চেয়ে বেশি ইন্টারঅ্যাকশন সহ।

উপযুক্ত সময়ে ( আদর্শভাবে visibilitychange ইভেন্টে ) বীকন বিশ্লেষণে ফিরে যান। স্থানীয় পরীক্ষার জন্য আপনি console.table ব্যবহার করতে পারেন। পর্যায়ক্রমে টেবিল:

console.table(longestBlockingLoAFs);

দীর্ঘ অ্যানিমেশন ফ্রেমে সাধারণ নিদর্শনগুলি সনাক্ত করুন

একটি বিকল্প কৌশল হ'ল দীর্ঘ অ্যানিমেশন ফ্রেম এন্ট্রিগুলিতে সর্বাধিক প্রদর্শিত সাধারণ স্ক্রিপ্টগুলি দেখার জন্য। পুনরাবৃত্তি অপরাধীদের সনাক্ত করতে ডেটা কোনও স্ক্রিপ্ট এবং চরিত্রের অবস্থানের স্তরে ফিরে রিপোর্ট করা যেতে পারে।

এটি কাস্টমাইজযোগ্য প্ল্যাটফর্মগুলির জন্য বিশেষত ভাল কাজ করতে পারে যেখানে থিম বা প্লাগইনগুলি পারফরম্যান্সের সমস্যাগুলির কারণ হিসাবে চিহ্নিত করা যেতে পারে বেশ কয়েকটি সাইট জুড়ে চিহ্নিত করা যেতে পারে।

দীর্ঘ অ্যানিমেশন ফ্রেমে সাধারণ স্ক্রিপ্টগুলির কার্যকর করার সময়-বা তৃতীয় পক্ষের উত্সগুলি-কোনও সাইট বা সাইটের সংগ্রহের দীর্ঘ অ্যানিমেশন ফ্রেমে সাধারণ অবদানকারীদের সনাক্ত করতে ফিরে রিপোর্ট করা যেতে পারে। উদাহরণস্বরূপ ইউআরএলগুলি দেখার জন্য:

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});

এবং এই আউটপুট উদাহরণ:

টুলিংয়ে দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই ব্যবহার করুন

এপিআই স্থানীয় ডিবাগিংয়ের জন্য অতিরিক্ত বিকাশকারী সরঞ্জামিংয়ের অনুমতি দেয়। বাতিঘর এবং ক্রোম ডেভটুলের মতো কিছু সরঞ্জামাদি নিম্ন-স্তরের ট্রেসিংয়ের বিশদ ব্যবহার করে এই ডেটার বেশিরভাগ সংগ্রহ করতে সক্ষম হয়েছে, এই উচ্চ-স্তরের এপিআই থাকা অন্যান্য সরঞ্জামগুলি এই ডেটা অ্যাক্সেস করতে পারে।

সারফেস লং অ্যানিমেশন ফ্রেমগুলি ডেভটুলগুলিতে

আপনি performance.measure() এপিআই ব্যবহার করে ডেভটুলগুলিতে দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পৃষ্ঠত্যাগ করতে পারেন, যা তারপরে পারফরম্যান্সের উন্নতির জন্য আপনার প্রচেষ্টাগুলিকে কোথায় ফোকাস করতে হবে তা দেখানোর জন্য পারফরম্যান্স ট্রেসগুলিতে ডিভটুলস ব্যবহারকারী টাইমিং ট্র্যাকগুলিতে প্রদর্শিত হয়। ডেভটুলস এক্সটেনসিবিলিটি এপিআই ব্যবহার করে এগুলি তাদের নিজস্ব ট্র্যাকেও দেখানো যেতে পারে:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    performance.measure('LoAF', {
      start: entry.startTime,
      end: entry.startTime + entry.duration,
      detail: {
        devtools: {
          dataType: "track-entry",
          track: "Long animation frames",
          trackGroup: "Performance Timeline",
          color: "tertiary-dark",
          tooltipText: 'LoAF'
        }
      }
    });
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

দীর্ঘমেয়াদী, দীর্ঘ অ্যানিমেশন ফ্রেমগুলি সম্ভবত নিজেই ডিভটুলগুলিতে অন্তর্ভুক্ত করা হবে, তবে পূর্ববর্তী কোড স্নিপেটটি এর মধ্যে এটি সেখানে প্রকাশিত হতে দেয়।

পূর্ববর্তী চিত্রের প্রথম এন্ট্রিটিও প্রমাণ করে যে ব্রাউজারটি তাদের মধ্যে রেন্ডার না করে একই দীর্ঘ অ্যানিমেশন ফ্রেমে একসাথে বেশ কয়েকটি কাজ প্রক্রিয়াজাত করেছে। পূর্বে উল্লিখিত হিসাবে এটি ঘটতে পারে যখন উচ্চ-অগ্রাধিকারের ইনপুট কার্যগুলি না থাকে তবে কার্যগুলির একটি সারি থাকে। প্রথম দীর্ঘ টাস্কটি সম্পূর্ণ করার জন্য কিছু রেন্ডার আপডেট রয়েছে (অন্যথায় বর্তমান দীর্ঘ অ্যানিমেশন ফ্রেমটি এর পরে পুনরায় সেট করা হবে এবং পরবর্তী কাজটি দিয়ে একটি নতুন শুরু হবে), তবে অবিলম্বে এই রেন্ডার করার পরিবর্তে, ব্রাউজারটি বেশ কয়েকটি প্রক্রিয়া করেছে অতিরিক্ত কাজগুলি এবং কেবল তখনই দীর্ঘ রেন্ডার টাস্কটি ক্রিয়া করে এবং দীর্ঘ অ্যানিমেশন ফ্রেমটি শেষ করে। এটি বিলম্বিত রেন্ডারগুলি সনাক্ত করতে সহায়তা করার জন্য কেবল দীর্ঘ কাজগুলির পরিবর্তে ডিভটুলগুলিতে দীর্ঘ অ্যানিমেশন ফ্রেমগুলি দেখার কার্যকারিতা প্রদর্শন করে।

অন্যান্য বিকাশকারী টুলিংয়ে দীর্ঘ অ্যানিমেশন ফ্রেম ডেটা ব্যবহার করুন

ওয়েব ভাইটালস এক্সটেনশনটি পারফরম্যান্সের সমস্যাগুলি নির্ণয়ের জন্য লগিং সংক্ষিপ্তসার ডিবাগের তথ্যের মান দেখিয়েছে ।

এটি এখন প্রতিটি আইএনপি কলব্যাক এবং প্রতিটি মিথস্ক্রিয়াটির জন্য দীর্ঘ অ্যানিমেশন ফ্রেমের ডেটাও সারফেস করে:

স্বয়ংক্রিয় পরীক্ষার সরঞ্জামগুলিতে দীর্ঘ অ্যানিমেশন ফ্রেম ডেটা ব্যবহার করুন

একইভাবে সিআই/সিডি পাইপলাইনগুলিতে স্বয়ংক্রিয় পরীক্ষার সরঞ্জামগুলি বিভিন্ন পরীক্ষার স্যুট চালানোর সময় দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পরিমাপ করে সম্ভাব্য পারফরম্যান্স ইস্যুতে বিশদগুলি পৃষ্ঠ করতে পারে।

FAQ

এই এপিআই -তে প্রায়শই জিজ্ঞাসিত কিছু প্রশ্নের মধ্যে রয়েছে:

কেন কেবল দীর্ঘ কার্য এপিআইতে প্রসারিত বা পুনরাবৃত্তি করবেন না?

এটি সম্ভাব্য প্রতিক্রিয়াশীল ইস্যুগুলির একই রকম - তবে শেষ পর্যন্ত আলাদা reporting প্রতিবেদন করার বিকল্প চেহারা। বিদ্যমান দীর্ঘ কার্যগুলির উপর নির্ভরশীল সাইটগুলি এপিআই বিদ্যমান ব্যবহারের ক্ষেত্রে ব্যাহত হওয়া এড়াতে কাজ চালিয়ে যাওয়া নিশ্চিত করা গুরুত্বপূর্ণ।

যদিও দীর্ঘ কার্যগুলি এপিআই লফের কয়েকটি বৈশিষ্ট্য (যেমন আরও ভাল অ্যাট্রিবিউশন মডেল) থেকে উপকৃত হতে পারে, আমরা বিশ্বাস করি যে ফ্রেমগুলিতে ফোকাস করা কাজগুলির পরিবর্তে অনেকগুলি সুবিধা দেয় যা এটি বিদ্যমান দীর্ঘ টাস্ক এপিআইতে মৌলিকভাবে আলাদা এপিআই করে তোলে।

আমার কাছে স্ক্রিপ্ট এন্ট্রি নেই কেন?

এটি ইঙ্গিত দিতে পারে যে দীর্ঘ অ্যানিমেশন ফ্রেমটি জাভাসিপ্টের কারণে নয়, পরিবর্তে বড় রেন্ডার কাজের কারণে ছিল।

দীর্ঘ অ্যানিমেশন ফ্রেমটি জাভাস্ক্রিপ্টের কারণে হলে এটিও ঘটতে পারে তবে যেখানে পূর্বে উল্লিখিত বিভিন্ন গোপনীয়তার কারণে স্ক্রিপ্ট অ্যাট্রিবিউশন সরবরাহ করা যায় না (মূলত সেই জাভাস্ক্রিপ্ট পৃষ্ঠার মালিকানাধীন নয়)।

আমার কাছে কেন স্ক্রিপ্ট এন্ট্রি রয়েছে তবে উত্সের তথ্য নেই বা সীমিত?

এটি বেশ কয়েকটি কারণে ঘটতে পারে, যার দিকে ইঙ্গিত করার মতো ভাল উত্স না রয়েছে ।

স্ক্রিপ্টের তথ্য no-cors cross-origin স্ক্রিপ্টগুলির জন্যও সীমাবদ্ধ থাকবে, যদিও এটি <script> কলটিতে crossOrigin = "anonymous" যুক্ত করে সিওআরএস ব্যবহার করে এই স্ক্রিপ্টগুলি আনার মাধ্যমে সমাধান করা যেতে পারে।

উদাহরণস্বরূপ, পৃষ্ঠায় যুক্ত করতে ডিফল্ট গুগল ট্যাগ ম্যানেজার স্ক্রিপ্ট:

<!-- 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 -->

জিটিএমের জন্য সম্পূর্ণ অ্যাট্রিবিউশন বিশদ সরবরাহ করার জন্য j.crossOrigin = "anonymous" যুক্ত করতে বাড়ানো যেতে পারে

এটি কি দীর্ঘ কাজগুলি এপিআই প্রতিস্থাপন করবে?

যদিও আমরা বিশ্বাস করি যে দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই দীর্ঘ কাজগুলি পরিমাপের জন্য আরও ভাল, আরও সম্পূর্ণ এপিআই, এই মুহুর্তে, দীর্ঘ কার্যগুলি এপিআই হ্রাস করার কোনও পরিকল্পনা নেই।

প্রতিক্রিয়া চেয়েছিল

গিটহাব ইস্যু তালিকায় প্রতিক্রিয়া সরবরাহ করা যেতে পারে, বা ক্রোমের এপিআই বাস্তবায়নের বাগগুলি ক্রোমের ইস্যু ট্র্যাকারে দায়ের করা যেতে পারে।

উপসংহার

দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই হ'ল একটি উত্তেজনাপূর্ণ নতুন এপিআই যা পূর্ববর্তী দীর্ঘ কার্যগুলি এপিআইয়ের অনেক সম্ভাব্য সুবিধা রয়েছে।

এটি আইএনপি দ্বারা পরিমাপকৃত প্রতিক্রিয়াশীলতার সমস্যাগুলি সমাধান করার জন্য একটি মূল সরঞ্জাম হিসাবে প্রমাণিত হচ্ছে। আইএনপি হ'ল একটি চ্যালেঞ্জিং মেট্রিক যা অনুকূলিতকরণ এবং এই এপিআই হ'ল ক্রোম টিম বিকাশকারীদের জন্য সমস্যাগুলি চিহ্নিতকরণ এবং সম্বোধন করার চেষ্টা করছে।

দীর্ঘ অ্যানিমেশন ফ্রেমের এপিআইয়ের সুযোগটি যদিও কেবল আইএনপি ছাড়িয়ে যায় এবং এটি ধীর আপডেটের অন্যান্য কারণগুলি সনাক্ত করতে সহায়তা করতে পারে যা কোনও ওয়েবসাইটের ব্যবহারকারীর অভিজ্ঞতার সামগ্রিক মসৃণতা প্রভাবিত করতে পারে।

স্বীকৃতি

হেনরি দ্বারা থাম্বনেইল চিত্রটি আনস্প্ল্যাশে থাকুন।

Barry Pollard

Noam Rosenthal

লং অ্যানিমেশন ফ্রেম এপিআই (লফ-প্রমোনড লো-এএফ) স্লো ইউজার ইন্টারফেস (ইউআই) আপডেটের আরও ভাল বোঝার জন্য দীর্ঘ কার্য এপিআইয়ের একটি আপডেট। এটি ধীর অ্যানিমেশন ফ্রেমগুলি সনাক্ত করতে কার্যকর হতে পারে যা সম্ভবত পরবর্তী পেইন্ট (আইএনপি) কোর ওয়েব ভাইটাল মেট্রিকের সাথে মিথস্ক্রিয়াকে প্রভাবিত করতে পারে যা প্রতিক্রিয়াশীলতা পরিমাপ করে বা মসৃণতা প্রভাবিত করে এমন অন্যান্য ইউআই জ্যাঙ্ক সনাক্ত করতে পারে।

এপিআই এর স্থিতি

ক্রোম 116 থেকে ক্রোম 122 পর্যন্ত একটি উত্স পরীক্ষার পরে, লফ এপিআই ক্রোম 123 থেকে প্রেরণ করেছে।

পটভূমি: দীর্ঘ কার্য এপিআই

লং অ্যানিমেশন ফ্রেম এপিআই হ'ল দীর্ঘ কার্য এপিআইয়ের বিকল্প যা কিছু সময়ের জন্য ক্রোমে উপলব্ধ ছিল (যেহেতু ক্রোম 58)। এর নাম অনুসারে, দীর্ঘ টাস্ক এপিআই আপনাকে দীর্ঘ কাজের জন্য পর্যবেক্ষণ করতে দেয়, যা এমন কাজ যা 50 মিলিসেকেন্ড বা তার বেশি সময় ধরে মূল থ্রেড দখল করে। একটি PeformanceObserver সহ PerformanceLongTaskTiming ইন্টারফেস ব্যবহার করে দীর্ঘ কাজগুলি পর্যবেক্ষণ করা যেতে পারে:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'longtask', buffered: true });

দীর্ঘ কাজগুলি প্রতিক্রিয়াশীলতার সমস্যাগুলির কারণ হতে পারে। যদি কোনও ব্যবহারকারী কোনও পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করার চেষ্টা করে example উদাহরণস্বরূপ, একটি বোতাম ক্লিক করুন, বা একটি মেনু খুলুন - তবে মূল থ্রেডটি ইতিমধ্যে একটি দীর্ঘ কাজ নিয়ে কাজ করছে, তবে ব্যবহারকারীর ইন্টারঅ্যাকশনটি সেই কাজটি শেষ হওয়ার অপেক্ষায় বিলম্বিত হয় ।

প্রতিক্রিয়াশীলতার উন্নতি করতে, এটি প্রায়শই দীর্ঘ কাজগুলি ভেঙে দেওয়ার পরামর্শ দেওয়া হয়। যদি প্রতিটি দীর্ঘ কার্যটি পরিবর্তে একাধিক, ছোট কাজগুলির একটি সিরিজে বিভক্ত হয়ে যায় তবে ইন্টারঅ্যাকশনগুলিতে প্রতিক্রিয়া জানাতে উল্লেখযোগ্য বিলম্ব এড়াতে এটি আরও গুরুত্বপূর্ণ কাজগুলি তাদের মধ্যে কার্যকর করার অনুমতি দিতে পারে।

সুতরাং প্রতিক্রিয়াশীলতার উন্নতি করার চেষ্টা করার সময়, প্রথম প্রচেষ্টাটি প্রায়শই একটি পারফরম্যান্স ট্রেস চালানো এবং দীর্ঘ কাজগুলি দেখার জন্য। এটি ল্যাব-ভিত্তিক নিরীক্ষণের সরঞ্জামের মাধ্যমে লাইটহাউস (যা দীর্ঘ মূল-থ্রেড টাস্ক অডিট এড়াতে ) বা ক্রোম ডেভটুলগুলিতে দীর্ঘ কাজগুলি দেখার মাধ্যমে হতে পারে।

ল্যাব-ভিত্তিক পরীক্ষাটি প্রায়শই প্রতিক্রিয়াশীলতার সমস্যাগুলি চিহ্নিত করার জন্য একটি দুর্বল শুরুর জায়গা , কারণ এই সরঞ্জামগুলিতে মিথস্ক্রিয়া অন্তর্ভুক্ত নাও থাকতে পারে-যখন তারা করে, তারা সম্ভবত মিথস্ক্রিয়াগুলির একটি ছোট উপসেট। আদর্শভাবে, আপনি ক্ষেত্রের ধীর মিথস্ক্রিয়তার কারণগুলি পরিমাপ করবেন।

দীর্ঘ কার্যগুলির ত্রুটিগুলি এপিআই

পারফরম্যান্স পর্যবেক্ষক ব্যবহার করে ক্ষেত্রের দীর্ঘ কার্যগুলি পরিমাপ করা কিছুটা কার্যকর। বাস্তবে, এটি একটি দীর্ঘ কাজ ঘটেছে এবং এটি কতক্ষণ সময় নিয়েছে তার বাইরে এত বেশি তথ্য দেয় না।

রিয়েল ইউজার মনিটরিং (রম) সরঞ্জামগুলি প্রায়শই দীর্ঘ কার্যগুলির সংখ্যা বা সময়কাল বা তারা কোন পৃষ্ঠাগুলি ঘটে তা সনাক্ত করতে এটি ব্যবহার করে - তবে দীর্ঘ কার্যটি কী কারণে ঘটেছে তার অন্তর্নিহিত বিবরণ ছাড়াই এটি কেবল সীমিত ব্যবহারের। দীর্ঘ টাস্কস এপিআইয়ের কেবল একটি প্রাথমিক অ্যাট্রিবিউশন মডেল রয়েছে, যা আপনাকে কেবলমাত্র ধারকটি দীর্ঘ টাস্কে (শীর্ষ স্তরের নথি বা একটি <iframe> >) ঘটেছিল তা বলে দেয়, তবে স্ক্রিপ্ট বা ফাংশনটি নয় যা এটিকে দেখানো হয়েছে, যেমনটি দেখানো হয়েছে একটি সাধারণ এন্ট্রি:

{
  "name": "unknown",
  "entryType": "longtask",
  "startTime": 31.799999997019768,
  "duration": 136,
  "attribution": [
    {
      "name": "unknown",
      "entryType": "taskattribution",
      "startTime": 0,
      "duration": 0,
      "containerType": "window",
      "containerSrc": "",
      "containerId": "",
      "containerName": ""
    }
  ]
}

দীর্ঘ কার্যগুলি এপিআইও একটি অসম্পূর্ণ দৃশ্য, কারণ এটি কিছু গুরুত্বপূর্ণ কাজও বাদ দিতে পারে। কিছু আপডেট - যেমন রেন্ডারিং - পৃথক কার্যগুলিতে সহায়তা করে যা আদর্শভাবে পূর্ববর্তী মৃত্যুদন্ডের সাথে একত্রে অন্তর্ভুক্ত করা উচিত যা সেই আপডেটটির জন্য সেই আপডেটটির জন্য "মোট কাজ" সঠিকভাবে পরিমাপ করার জন্য সেই আপডেটটি তৈরি করেছিল। কাজের উপর নির্ভর করার সীমাবদ্ধতার আরও তথ্যের জন্য, ব্যাখ্যাকারীর "যেখানে দীর্ঘ কার্যগুলি সংক্ষিপ্ত হয়ে যায়" বিভাগটি দেখুন।

চূড়ান্ত বিষয়টি হ'ল দীর্ঘ কার্যগুলি পরিমাপ করা কেবলমাত্র পৃথক কার্যগুলিতে প্রতিবেদন করে যা 50 মিলিসেকেন্ড সীমা থেকে বেশি সময় নেয়। একটি অ্যানিমেশন ফ্রেম এই 50 মিলিসেকেন্ড সীমা থেকে ছোট কয়েকটি কাজ দিয়ে তৈরি হতে পারে, তবুও সম্মিলিতভাবে এখনও ব্রাউজারের রেন্ডার করার ক্ষমতা অবরুদ্ধ করে।

দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই

লং অ্যানিমেশন ফ্রেমস এপিআই (এলএএফ) একটি নতুন এপিআই যা বিকাশকারীদের প্রতিক্রিয়াশীলতার সমস্যাগুলি সমাধান করতে এবং আইএনপি উন্নত করতে আরও কার্যকরভাবে অন্তর্দৃষ্টি পেতে সক্ষম করার জন্য দীর্ঘ কার্যগুলি এপিআইয়ের কিছু ত্রুটিগুলি সমাধান করার চেষ্টা করে, পাশাপাশি মসৃণতার সমস্যাগুলির অন্তর্দৃষ্টি পেতে সক্ষম করে তোলে .

ভাল প্রতিক্রিয়াশীলতার অর্থ একটি পৃষ্ঠা এটির সাথে তৈরি মিথস্ক্রিয়ায় দ্রুত সাড়া দেয়। এর মধ্যে একটি সময় মতো ব্যবহারকারীর দ্বারা প্রয়োজনীয় কোনও আপডেট আঁকতে সক্ষম হওয়া এবং এই আপডেটগুলি ঘটতে বাধা দেওয়া এড়ানো জড়িত। আইএনপির জন্য, 200 মিলিসেকেন্ড বা তারও কম সময়ে প্রতিক্রিয়া জানানোর পরামর্শ দেওয়া হয় তবে অন্যান্য আপডেটের জন্য (উদাহরণস্বরূপ, অ্যানিমেশন) এমনকি 200 মিলিসেকেন্ডও খুব দীর্ঘ হতে পারে।

দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই ব্লকিং কাজ পরিমাপের একটি বিকল্প পন্থা। পৃথক কাজগুলি পরিমাপ করার পরিবর্তে, দীর্ঘ অ্যানিমেশন ফ্রেম এপিআই - এর নাম হিসাবে প্রস্তাবিত - দীর্ঘ অ্যানিমেশন ফ্রেমগুলি নির্ধারণ করে। একটি দীর্ঘ অ্যানিমেশন ফ্রেম হ'ল যখন একটি রেন্ডারিং আপডেট 50 মিলিসেকেন্ডের বাইরে বিলম্বিত হয় (দীর্ঘ কার্য এপিআইয়ের প্রান্তিকের সমান)।

দীর্ঘ অ্যানিমেশন ফ্রেমগুলি এমন কাজগুলির শুরু থেকে পরিমাপ করা হয় যার জন্য একটি রেন্ডার প্রয়োজন। যেখানে সম্ভাব্য দীর্ঘ অ্যানিমেশন ফ্রেমের প্রথম কাজটি কোনও রেন্ডার প্রয়োজন হয় না, সেখানে দীর্ঘ অ্যানিমেশন ফ্রেমটি অ-রেন্ডারিং টাস্কটি শেষ হওয়ার পরে শেষ হয় এবং পরবর্তী কাজটি দিয়ে একটি নতুন সম্ভাব্য দীর্ঘ অ্যানিমেশন ফ্রেম শুরু করা হয়। সম্ভাব্য অবরুদ্ধ কাজের পরিমাপের অনুমতি দেওয়ার জন্য 50 মিলিসেকেন্ড (0 এর renderStart সময় সহ) এর চেয়ে বেশি সময় এ জাতীয় নন-রেন্ডারিং দীর্ঘ অ্যানিমেশন ফ্রেম এখনও দীর্ঘ অ্যানিমেশন ফ্রেম এপিআইতে অন্তর্ভুক্ত রয়েছে।

দীর্ঘ অ্যানিমেশন ফ্রেমগুলি PerformanceObserver সাথে দীর্ঘ কাজের মতো একইভাবে পর্যবেক্ষণ করা যেতে পারে তবে পরিবর্তে long-animation-frame প্রকারের দিকে তাকানো:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'long-animation-frame', buffered: true });

পূর্ববর্তী দীর্ঘ অ্যানিমেশন ফ্রেমগুলি পারফরম্যান্স টাইমলাইন থেকেও অনুসন্ধান করা যেতে পারে:

const loafs = performance.getEntriesByType('long-animation-frame');

যাইহোক, পারফরম্যান্স এন্ট্রিগুলির জন্য একটি maxBufferSize রয়েছে যার পরে আরও নতুন এন্ট্রিগুলি বাদ দেওয়া হয়, সুতরাং পারফরম্যান্সঅবসার্ভার পদ্ধতির প্রস্তাবিত পদ্ধতির। long-animation-frame বাফার আকার 200 এ সেট করা হয়েছে, long-tasks জন্য একই।

কাজের পরিবর্তে ফ্রেম দেখার সুবিধা

কার্য দৃষ্টিভঙ্গির পরিবর্তে ফ্রেমের দৃষ্টিকোণ থেকে এটিকে দেখার মূল সুবিধাটি হ'ল একটি দীর্ঘ অ্যানিমেশনটি যে কোনও সংখ্যক কাজ নিয়ে গঠিত হতে পারে যা দীর্ঘস্থায়ীভাবে একটি দীর্ঘ অ্যানিমেশন ফ্রেমের ফলস্বরূপ। এটি পূর্বে উল্লিখিত চূড়ান্ত পয়েন্টটিকে সম্বোধন করে, যেখানে অ্যানিমেশন ফ্রেমের আগে অনেকগুলি ছোট, রেন্ডার-ব্লকিং কার্যগুলির যোগফল দীর্ঘ টাস্ক এপিআই দ্বারা প্রকাশিত না হতে পারে।

দীর্ঘ কার্যগুলিতে এই বিকল্প দৃষ্টিভঙ্গির আরও একটি সুবিধা হ'ল পুরো ফ্রেমের সময় ভাঙ্গন সরবরাহ করার ক্ষমতা। দীর্ঘ টাস্ক এপিআইয়ের মতো কেবল একটি startTime এবং একটি duration অন্তর্ভুক্ত করার পরিবর্তে, লফের ফ্রেমের সময়কালের বিভিন্ন অংশের আরও অনেক বিশদ ভাঙ্গন অন্তর্ভুক্ত রয়েছে।

ফ্রেম টাইমস্ট্যাম্প এবং সময়সীমা

• startTime : নেভিগেশন শুরুর সময়ের সাথে সম্পর্কিত দীর্ঘ অ্যানিমেশন ফ্রেমের শুরুর সময়।
• duration : দীর্ঘ অ্যানিমেশন ফ্রেমের সময়কাল (উপস্থাপনার সময় সহ নয়)।
• renderStart : রেন্ডারিং চক্রের শুরুর সময়, যার মধ্যে requestAnimationFrame কলব্যাকস, স্টাইল এবং লেআউট গণনা অন্তর্ভুক্ত রয়েছে, পর্যবেক্ষক এবং ছেদ পর্যবেক্ষক কলব্যাকগুলি পুনরায় আকার দিন।
• styleAndLayoutStart : স্টাইল এবং লেআউট গণনায় ব্যয় করা সময়কালের সূচনা।
• firstUIEventTimestamp : এই ফ্রেমটি চলাকালীন প্রথম ইউআই ইভেন্টের (মাউস/কীবোর্ড এবং আরও) সময়টি পরিচালনা করা হবে।
• blockingDuration : মিলিসেকেন্ডে মোট সময়কাল যার জন্য অ্যানিমেশন ফ্রেম ইনপুট বা অন্যান্য উচ্চ অগ্রাধিকারের কার্যগুলির প্রক্রিয়াজাতকরণকে অবরুদ্ধ করবে।

blockingDuration এর ব্যাখ্যা

একটি দীর্ঘ অ্যানিমেশন ফ্রেম বেশ কয়েকটি কাজ নিয়ে গঠিত হতে পারে। The blockingDuration is the sum of task durations longer than 50 milliseconds (including the final render duration within the longest task).

For example, if a long animation frame was made up of two tasks of 55 milliseconds and 65 milliseconds followed by a render of 20 milliseconds, then the duration would be approximately 140 milliseconds with a blockingDuration of (55 - 50) + (65 + 20 - 50) = 40 milliseconds. For 40 milliseconds during this 140 millisecond long animation frame, the frame was considered blocked from handling input.

Whether to look at duration or blockingDuration

For the common 60 hertz display, a browser will try to schedule a frame at least every 16.66 milliseconds (to ensure smooth updates), or after a high priority task like input handling (to ensure responsive updates). However, if there is no input—nor other high-priority tasks—but there is a queue of other tasks, the browser will typically continue the current frame well past 16.66 milliseconds no matter how well broken up the tasks are within it. That is, the browser will always try to prioritise inputs, but may choose to tackle a queue of tasks over render updates. This is due to rendering being an expensive process so processing a combined rendering task for multiple tasks usually leads to an overall reduction of work.

Therefore, long animation frames with a low or zero blockingDuration should still feel responsive to input. Reducing or eliminating blockingDuration by breaking up long tasks is therefore key to improving responsiveness as measured by INP.

However, a lot of long animation frames, regardless of blockingDuration indicates UI updates that are delayed and so can still affect smoothness and lead to a feeling of a laggy user interface for scrolling or animations, even if these are less of an issue for responsiveness as measured by INP. To understand issues in this area look at the duration , but these can be more tricky to optimize for since you cannot solve this by breaking up work, but instead must reduce work.

Frame timings

The previously mentioned timestamps allow the long animation frame to be divided into timings:

Better script attribution

The long-animation-frame entry type includes better attribution data of each script that contributed to a long animation frame (for scripts longer than 5 milliseconds).

Similar to the Long Tasks API, this will be provided in an array of attribution entries, each of which details:

• A name and EntryType both will return script .
• A meaningful invoker , indicating how the script was called (for example, 'IMG#id.onload' , 'Window.requestAnimationFrame' , or 'Response.json.then' ).
• The invokerType of the script entry point:
  • user-callback : A known callback registered from a web platform API (for example, setTimeout , requestAnimationFrame ).
  • event-listener : A listener to a platform event (for example, click , load , keyup ).
  • resolve-promise : Handler of a platform promise (for example, fetch() . Note that in the case of promises, all the handlers of the same promises are mixed together as one "script") .
  • reject-promise : As per resolve-promise , but for the rejection.
  • classic-script : Script evaluation (for example, <script> or import() )
  • module-script : Same as classic-script , but for module scripts.
• Separate timing data for that script:
  • startTime : Time the entry function was invoked.
  • duration : The duration between startTime and when the subsequent microtask queue has finished processing.
  • executionStart : The time after compilation.
  • forcedStyleAndLayoutDuration : The total time spent processing forced layout and style inside this function (see thrashing ).
  • pauseDuration : Total time spent in "pausing" synchronous operations (alert, synchronous XHR).
• Script source details:
  • sourceURL : The script resource name where available (or empty if not found).
  • sourceFunctionName : The script function name where available (or empty if not found).
  • sourceCharPosition : The script character position where available (or -1 if not found).
• windowAttribution : The container (the top-level document, or an <iframe> ) the long animation frame occurred in.
• window : A reference to the same-origin window.

Where provided, the source entries allows developers to know exactly how each script in the long animation frame was called, down to the character position in the calling script. This gives the exact location in a JavaScript resource that resulted in the long animation frame.

Example of a long-animation-frame performance entry

A complete long-animation-frame performance entry example, containing a single script, is:

{
  "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
}

As can be seen, this gives an unprecedented amount of data for websites to be able to understand the cause of laggy rendering updates.

Use the Long Animation Frames API in the field

Tools like Chrome DevTools and Lighthouse—while useful for discovering and reproducing issues—are lab tools that may miss important aspects of the user experience that only field data can provide.

The Long Animation Frames API is designed to be used in the field to gather important contextual data for user interactions that the Long Tasks API couldn't. This can help you to identify and reproduce issues with interactivity that you might not have otherwise discovered.

Feature detecting Long Animation Frames API support

You can use the following code to test if the API is supported:

if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
  // Monitor LoAFs
}

Link to the longest INP interaction

The most obvious use case for the Long Animation Frames API is to to help diagnose and fix Interaction to Next Paint (INP) issues, and that was one of the key reasons the Chrome team developed this API. A good INP is where all interactions are responded to in 200 milliseconds or less from interaction until the frame is painted, and since the Long Animation Frames API measures all frames that take 50ms or more, most problematic INPs should include LoAF data to help you diagnose যারা মিথস্ক্রিয়া.

The "INP LoAF" is the LoAF which includes the INP interaction, as shown in the following diagram:

In some cases it's possible for an INP event to span two LoAFs—typically if the interaction happens after the frame has started the rendering part of the previous frame, and so the event handler is processed in the next frame:

It's even possible that it may span more than two LoAFs in some rare circumstances.

Recording the LoAF(s) data associated with the INP interaction lets you to get much more information about the INP interaction to help diagnose it. This is particularly helpful to understand input delay : as you can see what other scripts were running in that frame.

It can also be helpful to understand unexplained processing duration and presentation delay if your event handlers are not reproducing the values seen for those as other scripts may be running for your users which may not be included in your own testing.

There is no direct API to link an INP entry with its related LoAF entry or entries , though it is possible to do so in code by comparing the start and end times of each (see the WhyNp example script ). The web-vitals library includes all intersecting LoAFs in the longAnimationFramesEntries property of the INP attribution interface from v4.

Once you have linked the LoAF entry or entries, you can include information with INP attribution. The scripts object contains some of the most valuable information as it can show what else was running in those frames so beaconing back that data to your analytics service will allow you to understand more about why interactions were slow.

Reporting LoAFs for the INP interaction is a good way to find the what is the most pressing interactivity issues on your page. Each user may interact differently with your page and with enough volume of INP attribution data, a number of potential issues will be included in INP attribution data. This lets you to sort scripts by volume to see which scripts are correlating with slow INP.

Report more long animation data back to an analytics endpoint

One downside to only looking at the INP LoAF(s), is you may miss other potential areas for improvements that may cause future INP issues. This can lead to a feeling of chasing your tail where you fix an INP issue expecting to see a huge improvement, only to find the next slowest interaction is only a small amount better than that so your INP doesn't improve much.

So rather than only looking at the INP LoAF, you may want to consider all LoAFs across the page lifetime:

However, each LoAF entry contains considerable data, so you will likely want to restrict your analysis to only some LoAFs. Additionally, as the long animation frame entries can be quite large, developers should decide what data from the entry should be sent to analytics. For example, the summary times of the entry and perhaps the script names, or some other minimum set of other contextual data that may be deemed necessary.

Some suggested patterns to reduce the amount of long animation frame data includes:

• Observe long animation frames with interactions
• Observe long animation frames with high blocking durations
• Observe long animation frames during critical UI updates to improve smoothness
• Observe the worst long animation frames
• Identify common patterns in long animation frames

Which of these patterns works best for you, depends on how far along your optimization journey you are, and how common long animation frames are. For a site that has never optimized for responsiveness before, there may be many LoAFs do you may want to limit to just LoAFs with interactions, or set a high threshold, or only look at the worst ones.

As you resolve your common responsiveness issues, you may expand this by not limiting to just interactions or high blocking durations or by lowering thresholds.

Observe long animation frames with interactions

To gain insights beyond just the INP long animation frame, you can look at all LoAFs with interactions (which can be detected by the presence of a firstUIEventTimestamp value) with a high blockingDuration .

This can also be an easier method of monitoring INP LoAFs rather than trying to correlate the two, which can be more complex. In most cases this will include the INP LoAF for a given visit, and in rare cases when it doesn't it still surfaces long interactions that are important to fix, as they may be the INP interaction for other users.

The following code logs all LoAF entries with a blockingDuration greater than 100 milliseconds where an interaction occurred during the frame. The 100 is chosen here because it is less than the 200 millisecond "good" INP threshold. You could choose a higher or lower value depending on your needs.

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.blockingDuration > 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 });

Observe long animation frames with high blocking durations

As an improvement to looking at all long animation frames with interactions, you may want to look at all long animation frames with high blocking durations. These indicate potential INP problems if a user does interact during these long animation frames.

The following code logs all LoAF entries with a blocking duration greater than 100 milliseconds where an interaction occurred during the frame. The 100 is chosen here because it is less than the 200 millisecond "good" INP threshold to help identify potential problem frames, while keeping the amount of long animation frames reported to a minimum. You could choose a higher or lower value depending on your needs.

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.blockingDuration > 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 });

Observe long animation frames during critical UI updates to improve smoothness

As mentioned previously, looking at high blocking duration long animation frames can help to address input responsiveness. But for smoothness you should look at all long animation frames with a long duration .

Since, this can get quite noisy you may want to restrict measurements of these to key points with a pattern like this:

const REPORTING_THRESHOLD_MS = 100;

const observer = new PerformanceObserver(list => {
  if (measureImportantUIupdate) {
    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 });

async function doUIUpdatesWithMeasurements() {
  measureImportantUIupdate = true;
  await doUIUpdates();
  measureImportantUIupdate = false;
}

Observe the worst long animation frames

Rather than having a set threshold, sites may want to collect data on the longest animation frame (or frames), to reduce the volume of data that needs to be beaconed. So no matter how many long animation frames a page experiences, only data for the worst on, five, ten, or however many long animation frames absolutely necessary is beaconed back.

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 });

These strategies can also be combined—only look at the 10 worst LoAFs, with interactions, longer than 100 milliseconds.

At the appropriate time ( ideally on the visibilitychange event ) beacon back to analytics. For local testing you can use console.table periodically:

console.table(longestBlockingLoAFs);

Identify common patterns in long animation frames

An alternative strategy would be to look at common scripts appearing the most in long animation frame entries. Data could be reported back at a script and character position level to identify repeat offenders.

This may work particularly well for customizable platforms where themes or plugins causing performance issues could be identified across a number of sites.

The execution time of common scripts—or third-party origins—in long animation frames could be summed up and reported back to identify common contributors to long animation frames across a site or a collection of sites. For example to look at URLs:

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});

And example of this output is:

Use the Long Animation Frames API in tooling

The API also allows additional developer tooling for local debugging. While some tooling like Lighthouse and Chrome DevTools have been able to gather much of this data using lower-level tracing details, having this higher-level API could allow other tools to access this data.

Surface long animation frames data in DevTools

You can surface long animation frames in DevTools using the performance.measure() API, which are then displayed in the DevTools user timings track in performance traces to show where to focus your efforts for performance improvements. Using the DevTools Extensibility API these can even be shown in their own track:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    performance.measure('LoAF', {
      start: entry.startTime,
      end: entry.startTime + entry.duration,
      detail: {
        devtools: {
          dataType: "track-entry",
          track: "Long animation frames",
          trackGroup: "Performance Timeline",
          color: "tertiary-dark",
          tooltipText: 'LoAF'
        }
      }
    });
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Longer term, long animation frames will likely be incorporated into DevTools itself, but the previous code snippet allows it to be surfaced there in the meantime.

The first entry in the previous figure also demonstrates where the browser has processed several tasks together in the same long animation frame rather than render between them. As mentioned previously this can happen when there are no high-priority input tasks, but there is a queue of tasks. The first long task has some render updates to complete (otherwise the current long animation frame would be reset after it, and a new one would start with the next task), but instead of actioning that render immediately, the browser has processed a number of additional tasks and only then actioned the long render task and ended the long animation frame. This demonstrates the usefulness of looking at long animation frames in DevTools, rather than just long tasks, to help identify delayed renders.

Use long animation frames data in other developer tooling

The Web Vitals extension has shown the value in logging summary debug information to diagnose performance issues.

It now also surfaces long animation frame data for each INP callback and each interaction:

Use long animation frames data in automated testing tools

Similarly automated testing tools in CI/CD pipelines can surface details on potential performance issues by measuring long animation frames while running various test suites.

FAQ

Some of the frequently asked questions on this API include:

Why not just extend or iterate on the Long Tasks API?

This is an alternative look at reporting a similar—but ultimately different—measurement of potential responsiveness issues. It's important to ensure sites relying on the existing Long Tasks API continue to function to avoid disrupting existing use cases.

While the Long Tasks API may benefit from some of the features of LoAF (such as a better attribution model), we believe that focusing on frames rather than tasks offers many benefits that make this a fundamentally different API to the existing Long Tasks API.

Why do I not have script entries?

This may indicate that the long animation frame was not due to JavaScipt, but instead due to large render work.

This can also happen when the long animation frame is due to JavaScript but where the script attribution cannot be provided for various privacy reasons as noted previously (primarily that JavaScript not owned by the page).

Why do I have script entries but no, or limited, source information?

This can happen for a number of reasons, including there not being a good source to point to .

Script information will also be limited for no-cors cross-origin scripts, though this can be resolved by fetching those scripts using CORS by adding crossOrigin = "anonymous" to the <script> call.

For example, the default Google Tag Manager script to add to the page:

<!-- 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 -->

Can be enhanced to add j.crossOrigin = "anonymous" to allow full attribution details to be provided for GTM

Will this replace the Long Tasks API?

While we believe the Long Animation Frames API is a better, more complete API for measuring long tasks, at this time, there are no plans to deprecate the Long Tasks API.

Feedback wanted

Feedback can be provided at the GitHub Issues list , or bugs in Chrome's implementation of the API can be filed in Chrome's issue tracker .

উপসংহার

The Long Animation Frames API is an exciting new API with many potential advantages over the previous Long Tasks API.

It is proving to be a key tool for addressing responsiveness issues as measured by INP. INP is a challenging metric to optimize and this API is one way the Chrome team is seeking to make identifying and addressing issues easier for developers.

The scope of the Long Animation Frames API extends beyond just INP though, and it can help identify other causes of slow updates which can affect the overall smoothness of a website's user experience.

স্বীকৃতি

Thumbnail image by Henry Be on Unsplash .