কোড পরিবর্তন করার আগে একটি কাস্টমার জার্নি প্রোফাইল করুন
একটি গুরুত্বপূর্ণ রুট এবং ইন্টারঅ্যাকশন নির্বাচন করুন—যেমন ন্যাভিগেশন খোলা, রেজাল্ট ফিল্টার করা, বা একটি ফর্ম সাবমিট করা। Chrome DevTools-এর Performance প্যানেলে ক্লিন ব্রাউজার স্টেটে এটি রেকর্ড করুন। অ্যাকশনটি পুনরাবৃত্তি করুন এবং একটি থ্রটল করা CPU রান ও একটি ডেভেলপমেন্ট-মেশিন রান দুইই ক্যাপচার করুন; ডেস্কটপ ট্রেসগুলো স্বল্পক্ষম ফোনে বিঘ্ন ঘটানো কাজ লুকিয়ে রাখতে পারে।
ট্রেসটি ব্যবহার করুন একটি সংকীর্ণ হাইপোথিসিস পরীক্ষা করার জন্য—বাণ্ডল রিপোর্ট থেকে কোনো কম্পোনেন্টকে দোষারোপ করতে নয়। Main flame chart-এ, বড় বারগুলি বেশি সময় নেয় এবং stacked বারগুলো কল স্ট্যাক দেখায়। কোনো Task-এ লাল ত্রিভুজ একটি সম্ভাব্য long task নির্দেশ করে; সেটি নির্বাচন করে initiating-code লিঙ্কটি অনুসরণ করুন। অর্থময় পরিবর্তনের জন্য আগে-ও-পরের ট্রেস সংরক্ষণ করুন।
অ্যাকশন শুরুর ঠিক আগে রেকর্ড শুরু করুন এবং দৃশ্যমান ফলাফল পাওয়ার পর থামান।
রুট, অ্যাকাউন্ট স্টেট এবং অ্যাকশন সিরিয়াল ধারাবাহিক রাখুন।
প্রতিটি শীর্ষ খরচ সেই দলের বা ভেন্ডরের কাছে আনুন যে এটি পরিবর্তন করতে পারে।
ট্রেসকে কাজের একটি কিউ হিসাবে পড়ুন
একটি long task হলো তদন্ত শুরু করার থ্রেশহোল্ড, সম্পূর্ণ ডায়াগনসিস নয়। W3C Long Tasks specification 50 মিলিসেকেন্ড বা তার বেশি সময়ের টাস্ক রিপোর্ট করে। একটি টাস্কের নীচে JavaScript evaluation, ইভেন্ট হ্যান্ডলার, স্টাইল পুনঃহিসাব, লেআউট, বা পেইন্ট থাকতে পারে—এসব দেখুন। কল স্ট্যাক কোথা থেকে তদন্ত শুরু করবেন তা দেখায়; সময়ের বিন্যাস বলে দেয় সমস্যাটি কোড, রেন্ডারিং, নাকি তৃতীয়-পক্ষের ফ্রেমে।
গুরুত্বপূর্ণ ইন্টারঅ্যাকশনের সময় বারবার ঘটে এমন খরচকে অগ্রাধিকার দিন। ছোট একটি হ্যান্ডলারও ধীর মনে হতে পারে, যদি তা লেআউট ট্রিগার করে বা আগের কাজের পেছনে অপেক্ষা করে। ট্রেস হলো ল্যাবের পরিমাপ; তাই প্রতিনিধিত্বমূলক ডিভাইসে এবং যেখানে সম্ভব, গোপনীয়তা-সচেতন ফিল্ড টেলিমেট্রির মাধ্যমে সমাধানটি যাচাই করুন।
স্টার্টআপ পার্সিংয়ের জন্য আলাদা সমাধান দরকার, পোস্ট-ট্যাপ হ্যান্ডলারের জন্য আলাদা।
রিফ্যাক্টরিংয়ের আগে পুনরাবৃত্ত স্টাইল-লিখা এবং লেআউট-পড়ার প্যাটার্ন খুঁজে বের করুন।
ট্রেস, সিনারিও এবং শীর্ষ খরচ কাজ আইটেমে সংযুক্ত রাখুন।
যেখানে তা জরুরি সেখানে কম কোড পাঠান
রুট ও উদ্দেশ্য অনুযায়ী স্ক্রিপ্টগুলোর ইনভেন্টরি করুন। অপ্রয়োজনীয় প্যাকেজ, ডুপ্লিকেট, অবসরপ্রাপ্ত পরীক্ষা, এবং শেষ হওয়া ফিচারের কোড মুছে ফেলুন। তারপর রুট-নির্দিষ্ট বা বিরলভাবে ব্যবহৃত ফিচারগুলো আলাদা করে লোড করুন—তাই সেগুলো ইনিশিয়াল পাথে নয়, প্রয়োজনের সময় লোড হবে। ডায়নামিক লোডিং স্টার্টআপ কাজ কমাতে পারে, কিন্তু ব্যবহারকারী যদি অবিলম্বে ফিচারটি চায় তবে দৃশ্যমান বিলম্ব তৈরি করতে পারে।
কোনো কম্পোনেন্টে কি সম্পূর্ণ ক্লায়েন্ট-সাইড ফ্রেমওয়ার্ক দরকার, কোনো ইউটিলিটি কি বিদ্যমান সক্ষমতার পুনরাবৃত্তি করছে, এবং স্ট্যাটিক HTML-এর সঙ্গে ছোট কোনো উন্নতি কি যথেষ্ট হবে—এসব প্রশ্ন করুন। বিলম্বিত মডিউলের ফলব্যাক অবস্থা পরীক্ষা করুন। পেজটি ঐচ্ছিক সক্ষমতা সুচারুভাবে পিছিয়ে দেবে, অচল কন্ট্রোল দেখাবে না।
কোন রুটে কোন স্ক্রিপ্ট অনুমোদিত এবং কেন তা ডকুমেন্ট করুন।
অপশনাল এডিটর, ম্যাপ, প্লেয়ার, বা রিপোর্টিং ভিউগুলোর জন্য এটি বিবেচনা করুন।
অথেনটিকেশন, অ্যাক্সেসিবিলিটি, পেমেন্ট, এবং ফর্ম সম্পন্নতা পরীক্ষা করুন; যেখানে কন্ট্রোল প্রভাবিত হয় সেখানে যোগ্য পর্যালোচনা চান।
কাজ ভাগ করুন যাতে ব্রাউজার প্রতিক্রিয়া জানাতে পারে
ছোট ফাংশন নামকরণ করা স্বয়ংক্রিয়ভাবে আলাদা ব্রাউজার টাস্ক তৈরি করে না যদি সেগুলো সমসাময়িকভাবে চালানো হয়। একটি দীর্ঘ লুপের ক্ষেত্রে কাজ ব্যাচ করুন, প্রথমে ব্যবহারকারীর দৃশ্যমান অবস্থা আপডেট করুন, তারপর চালিয়ে যাওয়ার আগে yield দিন। এতে ব্রাউজার ব্যাচগুলোর মধ্যে ইনপুট ও রেন্ডারিং প্রক্রিয়া করতে পারে।
সমর্থিত ক্ষেত্রে, scheduler.yield() মেইন থ্রেডকে yield করে পরে কাজ চালিয়ে যায়; এটি ফিচার-ডিটেক্ট করে ব্যবহার করুন এবং অনর্থক ব্রাউজারের জন্য একটি ফোলব্যাক রাখুন। প্রতিটি ক্ষুদ্র অপারেশনের পর yield করবেন না—তার ওভারহেড আছে এবং সম্পন্ন সময় বাড়াতে পারে। মাপ থেকে সীমানা চয়ন করুন, ক্যানসেলেশন বজায় রাখুন, এবং পুরনো ফলাফল নতুন স্টেট প্রতিস্থাপন না করার ব্যবস্থা নিশ্চিত করুন।
অদৃশ্য পরবর্তী কাজ শুরু করার আগে স্বীকৃতি বা অগ্রগতির সংকেত দেখান।
একটি আইটেমের জন্য নয়, বরং পরিমাপিত কাজ দীর্ঘ হওয়ার আগেই yield দিন।
বর্তমান web.dev নির্দেশিকা isInputPending()-ভিত্তিক একটি নতুন কৌশলকে সুপারিশ করে না।
কম্পিউটেশন সরান, ইন্টারফেস নয়, একটি ওয়ার্কার-এ
Web Worker একটি ব্যাকগ্রাউন্ড থ্রেডে স্ক্রিপ্ট চালায় যা মেইন এক্সিকিউশন থ্রেড থেকে আলাদা। এটি ব্যয়বহুল পার্সিং, ডেটা ট্রান্সফর্মেশন, সার্চ ইনডেক্সিং এবং এমন অন্যান্য কাজের জন্য উপযুক্ত যা সরাসরি ইন্টারফেস অ্যাক্সেস করে না। পরিষ্কার ইনপুট পাঠান, নির্দিষ্ট রেজাল্ট ফিরিয়ে নিন, এবং রেন্ডারিং ও দৃশ্যমান স্টেট পরিবর্তন মেইন থ্রেডেই রাখুন।
ওয়ার্কার সবত্র সহায়ক নয়। এরা সরাসরি DOM ম্যানিপুলেট করতে পারে না এবং Window ব্যবহার করতে পারে না, এবং সাধারণ মেসেজ কমিউনিকেশন ডেটা কপি করে। ওয়ার্কার নির্মাণ, ডেটা স্থানান্তর, এবং ত্রুটি সমন্বয় একটি ছোট হিসাবের উপরে ওভারহেড নিয়ে আসতে পারে। সম্পূর্ণ ইন্টারঅ্যাকশন মাপুন, অপ্রয়োজনীয় ওয়ার্কারগুলি টার্মিনেট করুন, এবং ওয়ার্কার ব্যর্থ হলে ফলব্যাক ডিজাইন করুন।
শুরু করুন এমন ক্যালকুলেশন দিয়ে যার ইনপুট ও আউটপুট সিরিয়ালাইজেবল এবং টেস্টযোগ্য।
পুরনো ফিল্টার, রুট, বা অ্যাকশনের জন্য তৈরি ফলাফল বাতিল করুন।
সাধারণ ইন্টারফেসের মাধ্যমে তাৎপর্যপূর্ণ প্রোগ্রেস যোগাযোগ করুন।
তৃতীয়-পক্ষ JavaScript-কে প্রোডাকশন ডিপেনডেন্সি হিসেবে গভর্ন করুন
অ্যানালিটিক্স, বিজ্ঞাপন, এক্সপেরিমেন্ট, সোশ্যাল এমবেড, ভিডিও প্লেয়ার এবং সাপোর্ট উইজেট অনুরোধ, JavaScript evaluation, iframe, এবং নির্ভরতাসমূহ যোগ করতে পারে। একটি ভেন্ডর স্ক্রিপ্ট প্রয়োজনীয় হতে পারে, কিন্তু এটি অ্যাপ্লিকেশন দলের সরাসরি নিয়ন্ত্রণের বাইরে এবং পারফরম্যান্স, প্রাইভেসি, সিকিউরিটি, এবং কন্টিনিউটিতে প্রভাব ফেলতে পারে। এর উদ্দেশ্য, রুটসমূহ, লোডিং কন্ডিশন, অনুমোদক, সম্মতি (consent) প্রয়োজনীয়তা এবং অপসারণের মালিক ইনভেন্টরিতে রাখুন।
শর্ত ও চুক্তি অনুমতি দিলে, প্রতিনিধিত্বমূলক পেজটি একটি তৃতীয়-পক্ষ অরিজিনসহ এবং ছাড়া তুলনা করুন। পারফরম্যান্স টুলগুলো ব্যয়বহুল ইভ্যালুয়েশন, পে-লোড এবং long-task attribution দেখাতে পারে। নথিভুক্ত উপকারিতা যদি মাপা খরচকে ন্যায্যতা দেয়, তবেই হালকা বা বিলম্বিত ইন্টিগ্রেশন রাখুন। ঐচ্ছিক কোনো নির্ভরশীলতা ধীর বা অনুপলব্ধ হলে মূল কনটেন্ট ও প্রধান লেনদেনের কাজ নিশ্চিত করুন।
একটি ট্যাগ শুধুই সেই রুট ও শর্তে লোড করুন যেগুলো সেটি প্রয়োজন।
ট্যাগ-ম্যানেজার পরিবর্তনগুলোকে পারফরম্যান্স, প্রাইভেসি, সিকিউরিটি এবং রোলব্যাক পর্যালোচনায় অন্তর্ভুক্ত করুন।
একটি অ-গুরুত্বপূর্ণ ইন্টিগ্রেশন নিষ্ক্রিয় করার উপায় নথিভুক্ত ও পরীক্ষা করুন।
রেসপন্সিভনেসকে রিলিজ নিরাপত্তা হিসেবে বানান
জয়ী ট্রেসটিকে একটি ছোট রিগ্রেশন চেক-এ পরিণত করুন গুরুত্বপূর্ণ জার্নির জন্য। অন্তর্ভুক্ত ইন্টারঅ্যাকশনের পরিধি, ডিভাইস বা CPU সীমা, প্রত্যাশিত প্রতিক্রিয়া, এবং রিভিউয়ার নির্ধারণ করুন। এটিকে বাণ্ডল ও তৃতীয়-পক্ষ ইনভেন্টরি পর্যালোচনার সাথে জোড়া দিন যাতে একটি নতুন প্যাকেজ বা ট্যাগ নীরবে মেইন-থ্রেড কাজ পুনরায় যোগ করতে না পারে।
Status Is UP এই প্রমাণটি প্রোঅ্যাক্টিভ অপ্টিমাইজেশন ও নিরাপদ রেমিডিয়েশনের জন্য ব্যবহার করে, লাইভ অ্যাভেইলিবিলিটি মনিটরিংকে বদলায় না। উচ্চ-ঝুঁকিপূর্ণ পরিবর্তনের আগে রোলব্যাক প্রস্তুত করুন এবং রিলিজের পরে ক্রিটিক্যাল ফ্লো যাচাই করুন। ফলাফল ডিভাইস, নেটওয়ার্ক, ব্রাউজার, কনটেন্ট এবং অ্যাকাউন্ট স্টেট অনুযায়ী ভিন্ন হবে; থ্রেশহোল্ডগুলো গ্যার্ডরেল হিসেবে বিবেচনা করুন, গ্যারান্টি হিসেবে নয়।
শেয়ার্ড ন্যাভিগেশন, চেকআউট, সার্চ, বা বড় বাণ্ডলের জন্য আগে-ও-পরের ট্রেস দাবি করুন।
কোন ফিচার ফ্ল্যাগ, ট্যাগ সেটিং, বা ডিপ্লয়মেন্ট ভেরশনে পরিচিত-ভালো আচরণ পুনরুদ্ধার হয় তা জানুন।
মেজর রিলিজ, ভেন্ডর পরিবর্তন, বা ডিভাইস-মিক্স শিফটে পুনরায় প্রোফাইল করুন।