কারাউসেল লোডিং-এ ফ্রন্ট-এন্ড মেমরি ব্যবহার ৩০ গুণ উন্নত করা

২০২০ সালের দ্বিতীয় ত্রৈমাসিকে, আমরা এক্সপেরিয়েন্স পেজে একটি টেক রিফ্যাক্টর করেছিলাম, React-এ পুনঃলিখন করে এবং REST API ব্যবহার করেছিলাম। কিন্তু বাস্তবায়নের সময়, আমরা একটি আকর্ষণীয় সমস্যা খুঁজে পেয়েছিলাম।

এক্সপেরিয়েন্স পেজে প্রায় ২০টি ক্যারোজেল আছে, প্রতিটিতে অন্তত ৬০টি টাইলস রয়েছে। তাই পেজটি ১,২০০টিরও বেশি এক্সপেরিয়েন্স রেন্ডার করবে, যার মধ্যে রয়েছে তাদের শিরোনাম, ব্যবহারকারীর রেটিং, সমসাময়িক ব্যবহারকারী এবং থাম্বনেইল-এর মতো প্রাসঙ্গিক তথ্য। প্রতিটি ক্যারোজেলের ডানদিকে স্ক্রল করলে, যদি আরও এক্সপেরিয়েন্স থাকে, পরবর্তী ব্যাচ লোড করার জন্য একটি রিকোয়েস্ট পাঠানো হবে। তারপর অনুরোধ থেকে প্রাপ্ত নতুন ডেটা কারাউসেলের শেষে যুক্ত হবে, যার ফলে DOM-এ আরও নোড যোগ হবে এবং ব্রাউজারে আরও থাম্বনেইল রেন্ডার হবে। ব্যবহারকারীরা আরও ডেটা আনতে স্ক্রল করার সাথে সাথে ব্রাউজারের মেমরি ব্যবহার বৃদ্ধি পাবে, এবং UX ধীর হয়ে লেগ করতে শুরু করবে।

মেমোরি প্রোফাইল

আমরা Chrome Developer Tools ব্যবহার করে এই সমস্যার প্রোফাইল করতে পারি। প্রথম স্ন্যাপশটটি পৃষ্ঠা প্রথমবার লোড হওয়ার সময় নেওয়া হয়, এবং দ্বিতীয়টি ব্যবহারকারী একটি ক্যারাউসেলের পরবর্তী স্ক্রোল ১২ বার ক্লিক করার পর নেওয়া হয়। আমরা দেখছি 100+ স্ট্রিং নোড এবং বাড়তি থাম্বনেইল রেন্ডারিংয়ের কারণে মেমরি ব্যবহার প্রায় 9.7MB বৃদ্ধি পেয়েছে।

সমাধান

কারাউসেল স্ক্রল করার সময়, ব্যবহারকারীরা শুধুমাত্র কারাউসেল উইন্ডো থেকে আইটেমগুলোই দেখতে পান। উদাহরণস্বরূপ, 1920×1080 রেজোলিউশনের একটি ল্যাপটপে ফুল স্ক্রিন ব্রাউজারে প্রতিবার প্রায় ৯টি আইটেম দৃশ্যমান হবে। অতএব, সব অদৃশ্য নোড এবং থাম্বনেইল একসঙ্গে রেন্ডার করা বা অনুরোধ থেকে ফেরত আসা অতিরিক্ত ডেটা DOM-এ রাখা অপ্রয়োজনীয়।

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

মেমোরি প্রোফাইল

আবার Chrome Developer Tools-এ নজর দিই। আগের মতোই, প্রথম স্ন্যাপশটটি ইনিশিয়ালাইজেশনের সময় নেওয়া হয় এবং দ্বিতীয়টি ডানদিকে ১২ বার স্ক্রোল করার পর নেওয়া হয়। এখন ১০০+ আইটেম লোড করতে মাত্র 0.3MB মেমোরি বৃদ্ধি হয়, যেখানে আগে তা ছিল 9.7MB।

পরবর্তী কী?

কারাউসেল উপাদানকে বড় ডেটা উইন্ডো সামলাতে উন্নত করার পাশাপাশি, যখন আমরা কোনো ফিচার/পৃষ্ঠা রিফ্যাক্টর করি, তখন পারফরম্যান্সের তথ্য সংগ্রহ করতে আরও বেঞ্চমার্ক যোগ করতে হয়।

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