Google IO 2018-এ, আমরা টুল, লাইব্রেরি এবং অপ্টিমাইজেশন টেকনিকের একটি রাউন্ডআপ উপস্থাপন করেছি যা ওয়েব পারফর্ম্যান্স উন্নত করা সহজ করে তোলে। এখানে আমরা The Oodles Theater অ্যাপ ব্যবহার করে সেগুলি ব্যাখ্যা করি। আমরা প্রেডিক্টিভ লোডিং এবং নতুন Guess.js উদ্যোগের সাথে আমাদের পরীক্ষাগুলি সম্পর্কেও কথা বলি।
আমরা গত বছর ধরে ওয়েবকে কীভাবে আরও দ্রুত এবং আরও পারফর্ম্যান্ট করা যায় তা বোঝার চেষ্টা করে বেশ ব্যস্ত ছিলাম। এর ফলে নতুন টুল, পদ্ধতি ও লাইব্রেরি তৈরি হয়েছে, যেগুলি আমরা এই নিবন্ধে আপনার সাথে শেয়ার করতে চাই। প্রথম অংশে, আমরা আপনাকে কিছু অপ্টিমাইজেশন টেকনিক দেখাব যা আমরা The Oodles Theater অ্যাপ ডেভেলপ করার সময় ব্যবহার করেছি। দ্বিতীয় অংশে, আমরা প্রেডিক্টিভ লোডিং এবং নতুন Guess.js উদ্যোগ নিয়ে আমাদের এক্সপেরিমেন্ট সম্পর্কে কথা বলব।
পারফর্ম্যান্সের প্রয়োজনীয়তা
ইন্টারনেট প্রতি বছর আরও বেশি ভারী হয়ে উঠছে। আমরা যদি ওয়েবের অবস্থা চেক করি, তাহলে দেখতে পাব যে মোবাইলে একটি মিডিয়ান পেজের সাইজ প্রায় ১.৫ এমবি, যার বেশিরভাগই জাভাস্ক্রিপ্ট এবং ছবি।
ওয়েবসাইটের ক্রমবর্ধমান সাইজ, নেটওয়ার্ক লেটেন্সি, CPU-এর সীমাবদ্ধতা, রেন্ডার-ব্লকিং প্যাটার্ন বা অপ্রয়োজনীয় থার্ড-পার্টি কোডের মতো অন্যান্য বিষয়ের সাথে মিলে পারফর্ম্যান্সের জটিল ধাঁধা তৈরি করে।
অধিকাংশ ব্যবহারকারী তাদের প্রয়োজনীয় UX-এর ক্রমতালিকায় স্পিডকে সবচেয়ে উপরে রাখেন। এটি খুব একটা আশ্চর্যজনক নয়, কারণ কোনও পৃষ্ঠা লোড হওয়া সম্পূর্ণ না হওয়া পর্যন্ত আপনি সত্যিই অনেক কিছু করতে পারবেন না। আপনি পৃষ্ঠা থেকে কোনও ভ্যালু পাবেন না, আপনি এর নান্দনিকতার প্রশংসা করতে পারবেন না।
আমরা জানি যে ব্যবহারকারীদের কাছে পারফর্ম্যান্স গুরুত্বপূর্ণ, তবে অপ্টিমাইজ করা কোথা থেকে শুরু করতে হবে তা খুঁজে বের করা একটি গোপন রহস্য আবিষ্কার করার মতো মনে হতে পারে। আশার কথা হল, এই কাজে সাহায্য করার জন্য টুল রয়েছে।
Lighthouse - পারফর্ম্যান্স ওয়ার্কফ্লোর জন্য একটি বেস
Lighthouse হল Chrome DevTools-এর একটি অংশ যা আপনাকে নিজের ওয়েবসাইট অডিট করতে দেয় এবং কীভাবে এটিকে আরও ভালো করা যায় সেই বিষয়ে ইঙ্গিত দেয়।
আমরা সম্প্রতি বেশ কিছু নতুন পারফর্ম্যান্স অডিট লঞ্চ করেছি যা প্রতিদিনের ডেভেলপমেন্ট ওয়ার্কফ্লোতে খুবই উপযোগী।
আসুন, একটি বাস্তব উদাহরণের মাধ্যমে দেখে নেওয়া যাক যে আপনি কীভাবে এগুলির সুবিধা নিতে পারেন: Oodles Theater অ্যাপ। এটি একটি ছোট ডেমো ওয়েব অ্যাপ, যেখানে আপনি আমাদের কিছু প্রিয় ইন্টার্যাক্টিভ Google Doodle ব্যবহার করে দেখতে পারেন এবং এমনকি এক বা দুটি গেমও খেলতে পারেন।
অ্যাপটি তৈরি করার সময়, আমরা নিশ্চিত করতে চেয়েছিলাম যে এটি যেন যতটা সম্ভব পারফর্ম্যান্ট হয়। অপ্টিমাইজেশনের শুরুতে 'লাইটহাউস' রিপোর্ট ব্যবহার করা হয়েছিল।
Lighthouse রিপোর্টে আমাদের অ্যাপের প্রাথমিক পারফর্ম্যান্স খুবই খারাপ ছিল। 3G নেটওয়ার্কে, ফার্স্ট মিনিংফুল পেন্টের জন্য ব্যবহারকারীকে ১৫ সেকেন্ড অপেক্ষা করতে হয়েছে অথবা অ্যাপটি ইন্টার্যাক্টিভ হয়েছে। Lighthouse আমাদের সাইটের অনেক সমস্যা হাইলাইট করেছে এবং ২৩-এর সামগ্রিক পারফর্ম্যান্স স্কোর ঠিক সেটাই প্রতিফলিত করেছে।
পৃষ্ঠার সাইজ ছিল প্রায় ৩.৪ এমবি - আমাদের কিছু অপ্রয়োজনীয় জিনিস বাদ দিতেই হত।
এর ফলে আমাদের প্রথম পারফর্ম্যান্স চ্যালেঞ্জ শুরু হয়: এমন জিনিস খুঁজে বের করা যা সামগ্রিক অভিজ্ঞতাকে প্রভাবিত না করেই আমরা সহজেই সরিয়ে দিতে পারি।
পারফর্ম্যান্স অপ্টিমাইজ করার সুযোগ
অপ্রয়োজনীয় রিসোর্স সরিয়ে দিন
কিছু জিনিস আছে যা নিরাপদে সরানো যেতে পারে: হোয়াইটস্পেস এবং কমেন্ট।
Lighthouse আনমিনিফায়েড CSS ও জাভাস্ক্রিপ্ট অডিট-এ এই সুযোগ হাইলাইট করে। আমরা বিল্ড প্রসেসের জন্য webpack ব্যবহার করছিলাম, তাই ছোট করার জন্য আমরা শুধু Uglify JS প্লাগ-ইন ব্যবহার করেছি।
ছোট করা একটি সাধারণ কাজ, তাই আপনি যে বিল্ড প্রসেসই ব্যবহার করুন না কেন, তার জন্য আপনার একটি রেডিমেড সমাধান খুঁজে পাওয়া উচিত।
সেই স্পেসে আরেকটি উপযোগী অডিট হল টেক্সট কম্প্রেশন চালু করুন। আনকমপ্রেসড ফাইল পাঠানোর কোনও কারণ নেই এবং বেশিরভাগ CDN আজকাল এই সুবিধা প্রদান করে।
আমাদের কোড হোস্ট করার জন্য আমরা Firebase হোস্টিং ব্যবহার করছিলাম, এবং Firebase ডিফল্ট হিসেবে gzipping চালু করে, তাই একটি উপযুক্ত CDN-এ আমাদের কোড হোস্ট করার কারণে আমরা এটি ফ্রিতে পেয়েছি।
gzip কম্প্রেস করার খুব জনপ্রিয় পদ্ধতি হলেও, Zopfli ও Brotli-এর মতো অন্যান্য পদ্ধতিও জনপ্রিয় হয়ে উঠছে। Brotli বেশিরভাগ ব্রাউজারে কাজ করে এবং সার্ভারে পাঠানোর আগে আপনার অ্যাসেট প্রি-কম্প্রেস করতে আপনি বাইনারি ব্যবহার করতে পারেন।
কার্যকর ক্যাশে নীতি ব্যবহার করুন
আমাদের পরবর্তী পদক্ষেপ ছিল, অপ্রয়োজনীয় হলে আমরা যাতে দুবার রিসোর্স না পাঠাই তা নিশ্চিত করা।
Lighthouse-এ অদক্ষ ক্যাশে নীতি অডিট আমাদের লক্ষ্য করতে সাহায্য করেছে যে আমরা ঠিক এটি অর্জন করার জন্য আমাদের ক্যাশিং কৌশলগুলি অপ্টিমাইজ করতে পারি। আমাদের সার্ভারে max-age expiration হেডার সেট করে আমরা নিশ্চিত করেছি যে ব্যবহারকারী বারবার ভিজিট করলে, আগে ডাউনলোড করা রিসোর্স আবার ব্যবহার করতে পারবেন।
আদর্শ পরিস্থিতিতে, আপনার লক্ষ্য হওয়া উচিত যতটা সম্ভব রিসোর্স ক্যাশে করা এবং যত বেশি সময়ের জন্য সম্ভব তা করা। এছাড়াও, আপডেট করা রিসোর্সগুলি দক্ষতার সাথে পুনরায় যাচাই করার জন্য যাচাইকরণের টোকেন প্রদান করা উচিত।
ব্যবহার না করা কোড সরিয়ে দিন
এখনও পর্যন্ত আমরা অপ্রয়োজনীয় ডাউনলোডের স্পষ্ট অংশগুলি সরিয়ে দিয়েছি, কিন্তু যে অংশগুলি ততটা স্পষ্ট নয়, সেগুলির কী হবে? যেমন, অব্যবহৃত কোড।
কখনও কখনও আমরা আমাদের অ্যাপে এমন কোড অন্তর্ভুক্ত করি যা সত্যিই প্রয়োজনীয় নয়। এটি বিশেষ করে তখনই ঘটে যখন আপনি দীর্ঘ সময় ধরে আপনার অ্যাপে কাজ করেন, আপনার টিম বা আপনার ডিপেন্ডেন্সি পরিবর্তন হয়, এবং কখনও কখনও একটি অনাথ লাইব্রেরি পিছনে ফেলে দেওয়া হয়। আমাদের সাথেও ঠিক এটাই ঘটেছে।
শুরুতে আমরা আমাদের অ্যাপের দ্রুত প্রোটোটাইপ তৈরি করতে মেটেরিয়াল কম্পোনেন্ট লাইব্রেরি ব্যবহার করছিলাম। সময়ের সাথে সাথে আমরা আরও কাস্টম লুক এবং ফিল-এ চলে এসেছি এবং আমরা সেই লাইব্রেরির কথা সম্পূর্ণ ভুলে গেছি। ভাগ্যক্রমে, কোড কভারেজ চেক আমাদের বান্ডেলে এটি আবার খুঁজে পেতে সাহায্য করেছে।
আপনি DevTools-এ আপনার কোড কভারেজ পরিসংখ্যান চেক করতে পারেন, রানটাইম এবং আপনার অ্যাপ্লিকেশনের লোড টাইম উভয়ের জন্যই। আপনি নিচের স্ক্রিনশটে দুটি বড় লাল স্ট্রাইপ দেখতে পাবেন - আমাদের CSS-এর ৯৫%-এর বেশি অব্যবহৃত ছিল এবং জাভাস্ক্রিপ্টের একটি বড় অংশও ছিল।
Lighthouse-ও অব্যবহৃত CSS নিয়ম অডিটে এই সমস্যাটি শনাক্ত করেছে। এটি ৪০০ কেবির বেশি সম্ভাব্য সেভিংস দেখিয়েছে। তাই আমরা কোডে ফিরে গিয়ে সেই লাইব্রেরি থেকে JavaScript ও CSS, দুটি অংশই সরিয়ে দিয়েছি।
এর ফলে আমাদের CSS বান্ডেল ২০ গুণ কমে গেছে, যা একটি ছোট, দুই লাইনের কমিটের জন্য বেশ ভালো।
অবশ্যই, এটি আমাদের পারফর্ম্যান্স স্কোর বাড়িয়ে দিয়েছে এবং ইন্টার্যাক্টিভ হওয়ার সময় অনেক ভালো হয়েছে।
তবে, এই ধরনের পরিবর্তনের ক্ষেত্রে, শুধু আপনার মেট্রিক ও স্কোর চেক করাই যথেষ্ট নয়। আসল কোড সরিয়ে দেওয়া কখনই ঝুঁকিমুক্ত নয়, তাই সম্ভাব্য রিগ্রেশনের ব্যাপারে আপনাকে সবসময় সতর্ক থাকতে হবে।
আমাদের কোড ৯৫% ক্ষেত্রে ব্যবহার করা হয়নি - এখনও এই ৫% কোথাও না কোথাও আছে। আমাদের একটি কম্পোনেন্ট এখনও সেই লাইব্রেরির স্টাইল ব্যবহার করছিল - ডুডল স্লাইডারের ছোট তীরচিহ্ন। তবে, এটি খুব ছোট ছিল বলে, আমরা শুধু গিয়ে ম্যানুয়ালি সেই স্টাইলগুলি আবার বোতামে অন্তর্ভুক্ত করতে পেরেছি।
তাই আপনি কোড সরিয়ে দিলে, সম্ভাব্য ভিজ্যুয়াল রিগ্রেশন থেকে সুরক্ষিত থাকতে, আপনার কাছে সঠিক টেস্টিং ওয়ার্কফ্লো আছে কিনা তা ভাল করে দেখে নিন।
বিশাল নেটওয়ার্ক পে-লোড এড়িয়ে চলুন
আমরা জানি যে বড় রিসোর্স ওয়েব পেজ লোড হওয়ার গতি কমিয়ে দিতে পারে। এতে আমাদের ব্যবহারকারীদের টাকা খরচ হতে পারে এবং তাদের ডেটা প্ল্যানের উপর বড় প্রভাব পড়তে পারে, তাই এই বিষয়ে সতর্ক থাকা খুবই গুরুত্বপূর্ণ।
Lighthouse শনাক্ত করতে পেরেছে যে আমাদের কিছু নেটওয়ার্ক পেলোডে সমস্যা ছিল। এটি বিশাল নেটওয়ার্ক পেলোড অডিট ব্যবহার করে করা হয়েছে।
আমরা দেখেছি যে ৩ এমবি-র বেশি কোড শিপ করা হচ্ছে – যা বিশেষ করে মোবাইলের ক্ষেত্রে অনেক বেশি।
এই তালিকার একদম উপরে, Lighthouse হাইলাইট করেছে যে আমাদের কাছে একটি জাভাস্ক্রিপ্ট ভেন্ডর বান্ডেল ছিল যা ছিল ২ এমবি আনকমপ্রেসড কোড। এটিও webpack-এর হাইলাইট করা একটি সমস্যা।
কথায় বলে: যে অনুরোধ করা হয়নি সেটিই সবচেয়ে দ্রুত পূরণ হয়।
আপনার ব্যবহারকারীদের দেখানো প্রতিটি অ্যাসেটের ভ্যালু পরিমাপ করা, সেই অ্যাসেটের পারফর্ম্যান্স পরিমাপ করা এবং প্রাথমিক অভিজ্ঞতার সাথে সেটি শিপ করা উচিত কিনা তা নির্ধারণ করা উচিত। কারণ কখনও কখনও এইসব অ্যাসেট স্থগিত করা হতে পারে বা ধীরে ধীরে লোড করা হতে পারে, অথবা আইডল টাইমে প্রসেস করা হতে পারে।
আমাদের ক্ষেত্রে, যেহেতু আমরা প্রচুর জাভাস্ক্রিপ্ট বান্ডেল নিয়ে কাজ করছি, তাই আমরা ভাগ্যবান ছিলাম কারণ জাভাস্ক্রিপ্ট কমিউনিটিতে জাভাস্ক্রিপ্ট বান্ডেল অডিটিং টুলের একটি সমৃদ্ধ সেট রয়েছে।
আমরা webpack বান্ডেল অ্যানালাইজার দিয়ে শুরু করেছিলাম, যা আমাদের জানিয়েছিল যে আমরা unicode নামের একটি ডিপেন্ডেন্সি অন্তর্ভুক্ত করছিলাম, যা ছিল ১.৬ এমবি পার্স করা জাভাস্ক্রিপ্ট, অর্থাৎ বেশ বড়।
তারপর আমরা এডিটরে গিয়ে Visual code-এর জন্য ইমপোর্ট কস্ট প্লাগ-ইন ব্যবহার করে ইমপোর্ট করা প্রতিটি মডিউলের খরচ দেখতে পেয়েছি। এর ফলে আমরা জানতে পেরেছি যে কোন কম্পোনেন্টে এমন কোড আছে যা এই মডিউলকে রেফার করছে।
তারপর আমরা অন্য একটি টুল, BundlePhobia-তে সুইচ করেছি। এটি এমন একটি টুল যা আপনাকে যেকোনও NPM প্যাকেজের নাম লিখতে এবং আসলে এর ছোট করা এবং gzipped সাইজ কত হতে পারে তা দেখতে দেয়। আমরা যে স্লাগ মডিউল ব্যবহার করছিলাম তার একটি চমৎকার বিকল্প খুঁজে পেয়েছি যার ওজন মাত্র ২.২ কেবি, তাই আমরা সেটি পরিবর্তন করেছি।
আমাদের পারফর্ম্যান্সে এর বড় প্রভাব পড়েছে। এই পরিবর্তন এবং আমাদের JavaScript বান্ডেলের সাইজ কমানোর অন্যান্য সুযোগ খুঁজে পাওয়ার মধ্যে, আমরা ২.১ এমবি কোড সেভ করেছি।
আপনি এই বান্ডেলের gzipped ও ছোট করা সাইজ বিবেচনা করলে, আমরা সামগ্রিকভাবে ৬৫% উন্নতি দেখেছি। এবং আমরা দেখেছি যে এটি একটি প্রক্রিয়া হিসাবে সত্যিই মূল্যবান।
তাই, সাধারণভাবে, আপনার সাইট এবং অ্যাপে অপ্রয়োজনীয় ডাউনলোড বাদ দেওয়ার চেষ্টা করুন। আপনার অ্যাসেটের ইনভেনটরি তৈরি করা এবং সেগুলির পারফর্ম্যান্সের প্রভাব পরিমাপ করা সত্যিই একটি বড় পার্থক্য তৈরি করতে পারে, তাই নিশ্চিত করুন যে আপনি নিয়মিতভাবে আপনার অ্যাসেট অডিট করছেন।
কোড স্প্লিটিংয়ের মাধ্যমে জাভাস্ক্রিপ্ট বুট-আপের সময় কমানো
যদিও বড় নেটওয়ার্ক পেলোড আমাদের অ্যাপে বড় প্রভাব ফেলতে পারে, তবে আরেকটি জিনিস আছে যা সত্যিই বড় প্রভাব ফেলতে পারে এবং তা হল জাভাস্ক্রিপ্ট।
জাভাস্ক্রিপ্ট হল আপনার সবচেয়ে ব্যয়বহুল অ্যাসেট। মোবাইলে, আপনি যদি জাভাস্ক্রিপ্টের বড় বান্ডেল পাঠান, তাহলে আপনার ব্যবহারকারীরা কত তাড়াতাড়ি আপনার ইউজার ইন্টারফেস কম্পোনেন্টের সাথে ইন্টারঅ্যাক্ট করতে পারবেন তা বিলম্বিত হতে পারে। এর অর্থ হল, তারা কোনও অর্থপূর্ণ কিছু না করেই UI-তে ট্যাপ করতে পারে। তাই জাভাস্ক্রিপ্ট কেন এত বেশি খরচ করে তা বোঝা আমাদের জন্য গুরুত্বপূর্ণ।
ব্রাউজার এইভাবে জাভাস্ক্রিপ্ট প্রসেস করে।
আমাদের প্রথমে সেই স্ক্রিপ্ট ডাউনলোড করতে হবে, আমাদের একটি জাভাস্ক্রিপ্ট ইঞ্জিন আছে যা পরে সেই কোড পার্স করতে হবে, এটি কম্পাইল এবং এক্সিকিউট করতে হবে।
এখন এই ফেজগুলি এমন কিছু যা ডেস্কটপ মেশিন বা ল্যাপটপ, এমনকি হাই-এন্ড ফোনের মতো হাই-এন্ড ডিভাইসে অনেক বেশি সময় নেয় না। কিন্তু, একটি মাঝারি মানের মোবাইল ফোনে এই প্রক্রিয়াটি পাঁচ থেকে দশ গুণ বেশি সময় নিতে পারে। এর ফলে ইন্টার্যাক্টিভিটিতে দেরি হয়, তাই এটি কমানোর চেষ্টা করা আমাদের জন্য গুরুত্বপূর্ণ।
আপনার অ্যাপে এইসব সমস্যা খুঁজে পেতে সাহায্য করার জন্য, আমরা Lighthouse-এ একটি নতুন JavaScript বুট-আপ টাইম অডিট চালু করেছি।
Oodle অ্যাপের ক্ষেত্রে, এটি আমাদের জানিয়েছে যে জাভাস্ক্রিপ্ট বুট-আপে ১.৮ সেকেন্ড সময় লেগেছে। যা হচ্ছিল তা হল, আমরা আমাদের সমস্ত রুট এবং কম্পোনেন্ট একটি মনোলিথিক জাভাস্ক্রিপ্ট বান্ডেলে স্ট্যাটিক্যালি ইমপোর্ট করছিলাম এবং
এই সমস্যা সমাধানের একটি উপায় হল কোড স্প্লিটিং ব্যবহার করা।
কোড স্প্লিটিং হল আপনার ব্যবহারকারীদের পুরো পিজ্জার মতো জাভাস্ক্রিপ্ট দেওয়ার পরিবর্তে, তাদের প্রয়োজন অনুযায়ী একবারে একটি স্লাইস দেওয়ার মতো ধারণা।
কোড স্প্লিটিং রুট লেভেল বা কম্পোনেন্ট লেভেলে প্রয়োগ করা যেতে পারে। এটি React এবং React Loadable, Vue.js, Angular, Polymer, Preact এবং অন্যান্য একাধিক লাইব্রেরির সাথে খুব ভালো কাজ করে।
আমরা আমাদের অ্যাপ্লিকেশনে কোড স্প্লিটিং অন্তর্ভুক্ত করেছি, আমরা স্ট্যাটিক ইম্পোর্ট থেকে ডাইনামিক ইম্পোর্টে স্যুইচ করেছি, যা আমাদের প্রয়োজন অনুযায়ী অ্যাসিঙ্ক্রোনাসভাবে ধীরে ধীরে লোড কোড করার অনুমতি দেয়।
এর ফলে আমাদের বান্ডেলের সাইজ যেমন কমেছে, তেমনই JavaScript বুট আপ টাইমও কমেছে। এটি সময় কমিয়ে ০.৭৮ সেকেন্ড করে দেয়, যার ফলে অ্যাপ ৫৬% দ্রুত কাজ করে।
সাধারণত, আপনি যদি জাভাস্ক্রিপ্ট-হেভি অভিজ্ঞতা তৈরি করেন, তাহলে ব্যবহারকারীকে শুধুমাত্র তার প্রয়োজনীয় কোড পাঠাতে ভুলবেন না।
কোড স্প্লিটিংয়ের মতো ধারণার সুবিধা নিন, ট্রি শেকিংয়ের মতো আইডিয়া এক্সপ্লোর করুন এবং আপনি যদি ওয়েবপ্যাক ব্যবহার করেন, তাহলে আপনার লাইব্রেরির সাইজ কীভাবে কমাতে পারেন সেই বিষয়ে কিছু আইডিয়ার জন্য webpack-libs-optimizations রেপো চেক করুন।
ছবি অপ্টিমাইজ করুন
Oodle অ্যাপে আমরা অনেক ছবি ব্যবহার করছি। দুর্ভাগ্যবশত, Lighthouse এই বিষয়ে আমাদের মতো ততটা উৎসাহী ছিল না। আসলে, আমরা ছবি-সম্পর্কিত তিনটি অডিটেই ব্যর্থ হয়েছি।
আমরা ছবি অপ্টিমাইজ করতে ভুলে গিয়েছিলাম, ছবির সাইজ ঠিক ছিল না এবং অন্য ছবির ফর্ম্যাট ব্যবহার করলে আরও ভাল ফল পেতাম।
আমরা ছবি অপ্টিমাইজ করার মাধ্যমে শুরু করেছি।
একবার অপ্টিমাইজ করার জন্য আপনি ImageOptim বা XNConvert-এর মতো ভিজ্যুয়াল টুল ব্যবহার করতে পারেন।
আরও অটোমেটিক পদ্ধতি হল, আপনার বিল্ড প্রসেসে ছবি অপ্টিমাইজ করার ধাপ যোগ করা, imagemin-এর মতো লাইব্রেরির সাহায্যে।
এইভাবে আপনি নিশ্চিত করতে পারবেন যে ভবিষ্যতে যোগ করা ছবিগুলি অটোমেটিক অপ্টিমাইজ করা হবে। কিছু CDN, যেমন Akamai বা থার্ড-পার্টি সমাধান যেমন Cloudinary, Fastly বা Uploadcare আপনাকে ব্যাপক ইমেজ অপ্টিমাইজেশন সমাধান অফার করে। তাই আপনি সেইসব পরিষেবাতেও আপনার ছবি হোস্ট করতে পারেন।
খরচ বা লেটেন্সি সংক্রান্ত সমস্যার কারণে আপনি যদি তা করতে না চান, তাহলে Thumbor বা Imageflow-এর মতো প্রোজেক্ট সেল্ফ-হোস্টেড বিকল্প অফার করে।
আমাদের ব্যাকগ্রাউন্ড PNG-কে ওয়েবপ্যাকে বড় হিসেবে ফ্ল্যাগ করা হয়েছিল এবং তা ঠিকই ছিল। ভিউপোর্টের সাথে সঠিকভাবে সাইজ করার পরে এবং ImageOptim-এর মাধ্যমে রান করার পরে, আমরা ১০০ কেবিতে নেমে এসেছি, যা গ্রহণযোগ্য।
আমাদের সাইটে একাধিক ছবির জন্য এটি বারবার করার ফলে আমরা সামগ্রিক পৃষ্ঠার সাইজ উল্লেখযোগ্যভাবে কমাতে পেরেছি।
অ্যানিমেটেড কন্টেন্টের জন্য সঠিক ফর্ম্যাট ব্যবহার করা
GIF-এর দাম অনেক বেশি হতে পারে। আশ্চর্যের বিষয় হল, GIF ফর্ম্যাটকে কখনও অ্যানিমেশন প্ল্যাটফর্ম হিসেবে ব্যবহার করার কথা ভাবা হয়নি। তাই, আরও উপযুক্ত ভিডিও ফর্ম্যাটে পরিবর্তন করলে, আপনি ফাইলের সাইজের ক্ষেত্রে অনেক সাশ্রয় করতে পারবেন।
Oodle অ্যাপে, আমরা হোম পেজে ইন্ট্রো সিকোয়েন্স হিসেবে একটি GIF ব্যবহার করছিলাম। Lighthouse-এর মতে, আরও কার্যকর ভিডিও ফর্ম্যাটে পরিবর্তন করে আমরা ৭ এমবির বেশি সাশ্রয় করতে পারি। আমাদের ক্লিপের সাইজ ছিল প্রায় ৭.৩ এমবি, যা যেকোনও ওয়েবসাইটের পক্ষে অনেক বেশি, তাই আমরা এটিকে ভিডিও এলিমেন্টে পরিবর্তন করেছি, যার মধ্যে দুটি সোর্স ফাইল আছে - একটি mp4 এবং অন্যটি WebM, যাতে আরও বেশি ব্রাউজারে এটি কাজ করে।
আমরা FFmpeg টুল ব্যবহার করে আমাদের অ্যানিমেশন GIF-কে mp4 ফাইলে কনভার্ট করেছি। WebM ফর্ম্যাট আপনাকে আরও বেশি সাশ্রয় করতে সাহায্য করে - ImageOptim API আপনার জন্য এই ধরনের কনভার্সন করতে পারে।
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
এই কনভার্সনের জন্য আমরা সামগ্রিক ওজনের ৮০%-এর বেশি বাঁচাতে পেরেছি। এর ফলে আমরা প্রায় ১ এমবিতে নেমে এসেছি।
তবুও, ১ এমবি হল একটি বড় রিসোর্স যা ওয়্যার ডাউন পুশ করে, বিশেষ করে সীমিত ব্যান্ডউইথ ব্যবহারকারীর জন্য। ভাগ্যক্রমে, আমরা Effective Type API ব্যবহার করে বুঝতে পেরেছি যে তারা স্লো ব্যান্ডউইথ ব্যবহার করছেন এবং তাদের অনেক ছোট JPEG দিয়েছি।
ব্যবহারকারী কোন ধরনের নেটওয়ার্ক ব্যবহার করছেন তা অনুমান করতে এই ইন্টারফেস কার্যকর রাউন্ড-ট্রিপ টাইম এবং ডাউনলিঙ্ক ভ্যালু ব্যবহার করে। এটি শুধু একটি স্ট্রিং, স্লো 2G, 2G, 3G বা 4G রিটার্ন করে। তাই এই মানের উপর নির্ভর করে, ব্যবহারকারী 4G-এর নিচে থাকলে আমরা ভিডিও এলিমেন্টকে ছবি দিয়ে পরিবর্তন করতে পারি।
if (navigator.connection.effectiveType) { ... }
এটি অভিজ্ঞতা থেকে কিছুটা সরিয়ে দেয়, তবে অন্তত সাইটটি ধীরগতির কানেকশনে ব্যবহারযোগ্য হয়।
অফ-স্ক্রিন ছবি ধীরে ধীরে লোড করুন
ক্যারোজেল, স্লাইডার বা খুব বড় পৃষ্ঠায় প্রায়ই ছবি লোড হয়, যদিও ব্যবহারকারী পৃষ্ঠায় সরাসরি সেগুলি দেখতে পান না।
Lighthouse এই আচরণকে অফ-স্ক্রিন ইমেজ অডিটে ফ্ল্যাগ করবে এবং আপনি নিজেও DevTools-এর নেটওয়ার্ক প্যানেলে এটি দেখতে পাবেন। আপনি যদি দেখেন যে অনেক ছবি আসছে, কিন্তু পৃষ্ঠায় মাত্র কয়েকটি দেখা যাচ্ছে, তাহলে এর অর্থ হল আপনি সেগুলিকে ধীরে ধীরে লোড করার কথা বিবেচনা করতে পারেন।
ব্রাউজারে ধীরে ধীরে লোড করার সুবিধা এখনও কাজ করে না, তাই এই সুবিধা যোগ করতে আমাদের জাভাস্ক্রিপ্ট ব্যবহার করতে হবে। আমাদের Oodle কভারে ধীরে ধীরে লোড হওয়ার আচরণ যোগ করতে আমরা Lazysizes লাইব্রেরি ব্যবহার করেছি।
<!-- Import library -->
import lazysizes from 'lazysizes' <!-- or -->
<script src="lazysizes.min.js"></script>
<!-- Use it -->
<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w"/>
Lazysizes স্মার্ট কারণ এটি শুধু এলিমেন্টের দৃশ্যমানতার পরিবর্তন ট্র্যাক করে না, তার সাথে
ব্যবহারকারীর অভিজ্ঞতা অপ্টিমাইজ করার জন্য ভিউয়ের কাছাকাছি থাকা এলিমেন্টও প্রোঅ্যাক্টিভভাবে প্রিফেচ করে।
এছাড়াও, এটি IntersectionObserver-এর ঐচ্ছিক ইন্টিগ্রেশন অফার করে, যা আপনাকে খুব
দক্ষ দৃশ্যমানতা লুকআপ দেয়।
এই পরিবর্তনের পরে, আমাদের ছবি অন-ডিমান্ড ফেচ করা হচ্ছে। আপনি যদি সেই বিষয়ে আরও গভীরে যেতে চান, তাহলে images.guide দেখুন - এটি একটি খুব সহজ এবং বিস্তারিত রিসোর্স।
ব্রাউজারকে গুরুত্বপূর্ণ রিসোর্স আগে ডেলিভার করতে সাহায্য করুন
ব্রাউজারে পাঠানো প্রতিটি বাইট সমান গুরুত্বপূর্ণ নয় এবং ব্রাউজার এটি জানে। অনেক ব্রাউজারে হিউরিস্টিকস থাকে যা সিদ্ধান্ত নেয় যে প্রথমে কী ফেচ করা উচিত। তাই কখনও কখনও তারা ছবি বা স্ক্রিপ্টের আগে CSS ফেচ করবে।
পৃষ্ঠার লেখক হিসেবে, আমাদের কাছে আসলে কী গুরুত্বপূর্ণ তা ব্রাউজারকে জানানো আমাদের জন্য উপযোগী হতে পারে। তবে, গত কয়েক বছর ধরে ব্রাউজার ভেন্ডররা
এই বিষয়ে আমাদের সাহায্য করার জন্য বেশ কিছু ফিচার যোগ করেছে, যেমন
link rel=preconnect,
বা preload বা prefetch-এর মতো রিসোর্স হিন্ট।
ওয়েব প্ল্যাটফর্মে নিয়ে আসা এইসব ক্ষমতা ব্রাউজারকে সঠিক সময়ে সঠিক জিনিস নিয়ে আসতে সাহায্য করে এবং স্ক্রিপ্ট ব্যবহার করে করা কিছু কাস্টম লোডিং, লজিক-ভিত্তিক অ্যাপ্রোচের চেয়ে এগুলি কিছুটা বেশি দক্ষ হতে পারে।
আসুন, Lighthouse কীভাবে আমাদের এই ফিচারগুলির মধ্যে কিছু কার্যকরভাবে ব্যবহার করার জন্য গাইড করে তা দেখি।
Lighthouse আমাদের প্রথমে যে কাজটি করতে বলে তা হল, কোনও অরিজিনে একাধিকবার যাওয়া-আসা এড়ানো।
Oodle অ্যাপের ক্ষেত্রে, আমরা আসলে Google Fonts ব্যাপকভাবে ব্যবহার করছি। আপনি যখনই আপনার পৃষ্ঠায় Google Font স্টাইলশিট ড্রপ করবেন, এটি দুটি সাবডোমেন পর্যন্ত কানেক্ট করবে। এবং Lighthouse আমাদের যা বলছে তা হল, আমরা যদি সেই কানেকশনটি ওয়ার্ম আপ করতে পারি, তাহলে আমরা আমাদের প্রাথমিক কানেকশন টাইমে ৩০০ মিলিসেকেন্ড পর্যন্ত বাঁচাতে পারব।
লিঙ্ক rel প্রি-কানেক্টের সুবিধা নিয়ে, আমরা কার্যকরভাবে সেই কানেকশন লেটেন্সি মাস্ক করতে পারি।
বিশেষ করে Google Fonts-এর মতো কিছুর ক্ষেত্রে যেখানে আমাদের ফন্ট ফেস CSS googleapis.com-এ হোস্ট করা হয় এবং আমাদের ফন্ট রিসোর্স Gstatic-এ হোস্ট করা হয়, এটি সত্যিই বড় প্রভাব ফেলতে পারে। তাই আমরা এই অপ্টিমাইজেশন প্রয়োগ করেছি এবং কয়েকশো মিলিসেকেন্ড সময় বাঁচিয়েছি।
Lighthouse-এর পরবর্তী সাজেশন হল, আমরা যেন গুরুত্বপূর্ণ অনুরোধ প্রিলোড করি।
<link rel=preload> সত্যিই শক্তিশালী, এটি ব্রাউজারকে জানায় যে বর্তমান নেভিগেশনের অংশ হিসেবে একটি রিসোর্স প্রয়োজন
এবং এটি ব্রাউজারকে যত তাড়াতাড়ি সম্ভব এটি ফেচ করার চেষ্টা করে।
এখন এখানে Lighthouse আমাদের বলছে যে আমাদের মূল ওয়েব ফন্ট রিসোর্সগুলি প্রিলোড করা উচিত, কারণ আমরা দুটি ওয়েব ফন্ট লোড করছি।
ওয়েব ফন্টে প্রিলোড করা এইরকম দেখায় - rel=preload উল্লেখ করে, আপনি ফন্টের ধরন সহ as পাস করেন এবং তারপরে আপনি যে ধরনের ফন্ট লোড করার চেষ্টা করছেন তা উল্লেখ করেন, যেমন woff2।
আপনার পৃষ্ঠায় এর প্রভাব বেশ স্পষ্ট।
সাধারণত, লিঙ্ক rel প্রিলোড ব্যবহার না করে, আপনার পৃষ্ঠার জন্য ওয়েব ফন্ট গুরুত্বপূর্ণ হলে, ব্রাউজারকে প্রথমে আপনার HTML আনতে হবে, আপনার CSS পার্স করতে হবে এবং অনেক পরে, এটি অবশেষে আপনার ওয়েব ফন্ট নিয়ে আসবে।
লিঙ্ক rel প্রিলোড ব্যবহার করে, ব্রাউজার আপনার HTML পার্স করার সাথে সাথেই এটি আসলে অনেক আগেই সেই ওয়েব ফন্টগুলি আনা শুরু করতে পারে। আমাদের অ্যাপের ক্ষেত্রে, এটি আমাদের ওয়েব ফন্ট ব্যবহার করে টেক্সট রেন্ডার করতে যে সময় লেগেছিল তার থেকে এক সেকেন্ড কমিয়ে দিতে সক্ষম হয়েছে।
Google Fonts ব্যবহার করে ফন্ট প্রিলোড করার চেষ্টা করলে, সেটি খুব একটা সহজ নয়।
আমাদের স্টাইলশিটে ফন্ট ফেসে আমরা যে Google Font URL উল্লেখ করি, তা এমন কিছু যা ফন্ট টিম নিয়মিত আপডেট করে। এই URL-এর মেয়াদ শেষ হয়ে যেতে পারে অথবা নিয়মিত আপডেট করা হতে পারে, তাই ফন্ট লোড করার অভিজ্ঞতা সম্পূর্ণভাবে নিয়ন্ত্রণ করতে চাইলে, আমরা সাজেস্ট করব যে আপনি নিজের ওয়েব ফন্ট নিজেই হোস্ট করুন। এটি দারুণ হতে পারে কারণ এটি আপনাকে লিঙ্ক rel প্রিলোডের মতো জিনিসগুলিতে অ্যাক্সেস দেয়।
আমাদের ক্ষেত্রে আমরা দেখেছি যে Google Web Fonts Helper টুলটি সত্যিই খুব উপযোগী। এটি আমাদের কিছু ওয়েব ফন্ট অফলাইন করতে এবং স্থানীয়ভাবে সেট আপ করতে সাহায্য করে। তাই এই টুলটি ব্যবহার করে দেখুন।
আপনি গুরুত্বপূর্ণ রিসোর্সের অংশ হিসেবে ওয়েব ফন্ট ব্যবহার করছেন অথবা এটি জাভাস্ক্রিপ্ট, ব্রাউজার যাতে যত তাড়াতাড়ি সম্ভব আপনার গুরুত্বপূর্ণ রিসোর্স ডেলিভার করতে পারে সেই ব্যাপারে সাহায্য করার চেষ্টা করুন।
এক্সপেরিমেন্টাল: প্রায়োরিটি হিন্ট
আজ আপনার সাথে শেয়ার করার জন্য আমাদের কাছে বিশেষ কিছু আছে। রিসোর্স হিন্ট ও প্রিলোডের মতো ফিচারের পাশাপাশি, আমরা ব্রাউজারের একটি সম্পূর্ণ নতুন পরীক্ষামূলক ফিচার নিয়ে কাজ করছি, যেটিকে আমরা প্রায়োরিটি হিন্ট বলি।
এটি একটি নতুন ফিচার যা আপনাকে ব্রাউজারকে ইঙ্গিত করতে দেয় যে কোনও রিসোর্স কতটা গুরুত্বপূর্ণ। এটি একটি নতুন অ্যাট্রিবিউট প্রকাশ করে - গুরুত্ব - কম, বেশি বা অটো ভ্যালু সহ।
এটি আমাদের কম গুরুত্বপূর্ণ রিসোর্সের অগ্রাধিকার কমানোর কথা জানাতে দেয়, যেমন নন-ক্রিটিক্যাল স্টাইল, ছবি বা কন্টেনশন কমাতে API কল ফেচ করা। এছাড়াও, আমরা আরও গুরুত্বপূর্ণ জিনিস, যেমন আমাদের হিরো ইমেজের অগ্রাধিকার বাড়াতে পারি।
আমাদের Oodle অ্যাপের ক্ষেত্রে, এটি আসলে একটি ব্যবহারিক জায়গায় নিয়ে গেছে যেখানে আমরা অপ্টিমাইজ করতে পারি।
আমরা আমাদের ছবিতে ধীরে ধীরে লোড করার সুবিধা যোগ করার আগে, ব্রাউজার যা করছিল তা হল, আমাদের কাছে আমাদের সমস্ত ডুডল সহ এই ছবির ক্যারোজেল ছিল এবং ব্রাউজারটি ক্যারোজেলের একেবারে শুরুতে উচ্চ অগ্রাধিকার সহ সমস্ত ছবি আনছিল। দুর্ভাগ্যবশত, ক্যারোজেলের মাঝখানে থাকা ছবিগুলিই ব্যবহারকারীর কাছে সবচেয়ে গুরুত্বপূর্ণ ছিল। তাই আমরা যা করেছি তা হল, আমরা ব্যাকগ্রাউন্ডের ছবিগুলির গুরুত্ব খুব কম এবং ফোরগ্রাউন্ডের ছবিগুলির গুরুত্ব খুব বেশি সেট করেছি। এর ফলে স্লো 3G-তে দুই সেকেন্ডের প্রভাব পড়েছে এবং আমরা কত দ্রুত সেই ছবিগুলি আনতে এবং রেন্ডার করতে পেরেছি। তাই এটি একটি সুন্দর ইতিবাচক অভিজ্ঞতা।
আমরা আশা করছি যে কয়েক সপ্তাহের মধ্যে এই ফিচার Canary-তে নিয়ে আসতে পারব, তাই সেই দিকে নজর রাখুন।
ওয়েব ফন্ট লোড করার স্ট্র্যাটেজি আছে
ভাল ডিজাইনের জন্য টাইপোগ্রাফি হল মৌলিক বিষয় এবং আপনি ওয়েব ফন্ট ব্যবহার করলে, আদর্শগতভাবে আপনার টেক্সটের রেন্ডারিং ব্লক করতে চাইবেন না এবং আপনি অবশ্যই অদৃশ্য টেক্সট দেখাতে চাইবেন না।
আমরা এখন Lighthouse-এ এটি হাইলাইট করি, ওয়েব ফন্ট লোড হওয়ার সময় অদৃশ্য টেক্সট এড়িয়ে চলুন অডিট সহ।
আপনি যদি ফন্ট ফেস ব্লক ব্যবহার করে আপনার ওয়েব ফন্ট লোড করেন, তাহলে সেই ওয়েব ফন্ট আনতে অনেক সময় লাগলে কী করতে হবে তা আপনি ব্রাউজারকে সিদ্ধান্ত নিতে দিচ্ছেন। কিছু ব্রাউজার সিস্টেম ফন্টে ফিরে আসার আগে তিন সেকেন্ড পর্যন্ত অপেক্ষা করবে এবং ফন্ট ডাউনলোড হয়ে গেলে সেটি পরিবর্তন করে দেবে।
আমরা এই অদৃশ্য টেক্সট এড়ানোর চেষ্টা করছি, তাই এই ক্ষেত্রে ওয়েব ফন্ট খুব বেশি সময় নিলে আমরা এই সপ্তাহের ক্লাসিক ডুডল দেখতে পেতাম না। তবে, font-display নামক নতুন ফিচারের মাধ্যমে,
আপনি এই প্রসেসের উপর অনেক বেশি নিয়ন্ত্রণ পাবেন।
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-display: swap;
font-weight: 400;
src: local('Montserrat Regular'), local('Montserrat-Regular'),
/* Chrome 26+, Opera 23+, Firefox 39+ */
url('montserrat-v12-latin-regular.woff2') format('woff2'),
/* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
url('montserrat-v12-latin-regular.woff') format('woff');
}
ফন্ট ডিসপ্লে আপনাকে সিদ্ধান্ত নিতে সাহায্য করে যে ওয়েব ফন্টগুলি অদলবদল করতে কত সময় লাগে তার উপর ভিত্তি করে কীভাবে রেন্ডার বা ফলব্যাক হবে।
এই ক্ষেত্রে আমরা ফন্ট ডিসপ্লে সোয়াপ ব্যবহার করছি। সোয়াপ ফন্ট ফেসকে শূন্য সেকেন্ডের ব্লক পিরিয়ড এবং অসীম সোয়াপ পিরিয়ড দেয়। এর অর্থ হল, ফন্ট লোড হতে সময় লাগলে, ব্রাউজার অবিলম্বে ফলব্যাক ফন্ট ব্যবহার করে আপনার টেক্সট দেখাবে। এবং ফন্ট ফেস উপলভ্য হলে এটি একবার অদলবদল করতে চলেছে।
আমাদের অ্যাপের ক্ষেত্রে, এটি দুর্দান্ত ছিল কারণ এটি আমাদের খুব তাড়াতাড়ি কিছু অর্থপূর্ণ টেক্সট প্রদর্শন করতে এবং এটি প্রস্তুত হয়ে গেলে ওয়েব ফন্টে ট্রানজিশন করতে দেয়।
সাধারণত, আপনি যদি ওয়েব ফন্ট ব্যবহার করেন, যেমন ওয়েবের একটি বড় শতাংশ করে, তাহলে একটি ভাল ওয়েব ফন্ট লোডিং কৌশল আছে।
ফন্ট লোড করার অভিজ্ঞতা অপ্টিমাইজ করার জন্য আপনি অনেক ওয়েব প্ল্যাটফর্ম ফিচার ব্যবহার করতে পারেন, তবে Zach Leatherman-এর Web Font Recipes রেপো চেক করে দেখুন, কারণ এটি সত্যিই দারুণ।
রেন্ডার-ব্লকিং স্ক্রিপ্ট কমানো
আমাদের অ্যাপ্লিকেশনের অন্যান্য অংশ রয়েছে যা আমরা ডাউনলোড চেইনে আগে পুশ করতে পারি যাতে অন্তত কিছু প্রাথমিক ব্যবহারকারীর অভিজ্ঞতা একটু আগে প্রদান করা যায়।
Lighthouse টাইমলাইন স্ট্রিপে আপনি দেখতে পাবেন যে প্রথম কয়েক সেকেন্ডে যখন সব রিসোর্স লোড হচ্ছে, তখন ব্যবহারকারী কোনও কন্টেন্ট দেখতে পাচ্ছেন না।
এক্সটার্নাল স্টাইলশিট ডাউনলোড ও প্রসেস করার ফলে আমাদের রেন্ডারিং প্রসেস কোনও উন্নতি করতে পারছে না।
কিছু স্টাইল একটু আগে ডেলিভার করে আমরা ক্রিটিক্যাল রেন্ডারিং পাথ অপ্টিমাইজ করার চেষ্টা করতে পারি।
আমরা যদি এই প্রাথমিক রেন্ডারের জন্য দায়ী স্টাইলগুলি এক্সট্র্যাক্ট করি এবং আমাদের HTML-এ ইনলাইন করি, তাহলে ব্রাউজার এক্সটার্নাল স্টাইলশিট আসার জন্য অপেক্ষা না করেই সরাসরি সেগুলি রেন্ডার করতে পারবে।
আমাদের ক্ষেত্রে, আমরা Critical নামক একটি NPM মডিউল ব্যবহার করেছি যাতে বিল্ড স্টেপের সময় index.html-এ আমাদের গুরুত্বপূর্ণ কন্টেন্ট ইনলাইন করা যায়।
এই মডিউলটি আমাদের জন্য বেশিরভাগ ভারী কাজ করলেও, বিভিন্ন রুটে এটি মসৃণভাবে কাজ করার জন্য এটি এখনও কিছুটা জটিল ছিল।
আপনি যদি সতর্ক না হন বা আপনার সাইটের স্ট্রাকচার যদি খুব জটিল হয়, তাহলে অ্যাপ শেল আর্কিটেকচার শুরু থেকে প্ল্যান না করলে এই ধরনের প্যাটার্ন প্রয়োগ করা খুব কঠিন হতে পারে।
এই কারণেই পারফর্ম্যান্স সংক্রান্ত বিষয়গুলি আগে থেকেই বিবেচনা করা অত্যন্ত গুরুত্বপূর্ণ। আপনি যদি শুরু থেকেই পারফর্ম্যান্সের জন্য ডিজাইন না করেন, তাহলে পরে তা করার সময় আপনার সমস্যায় পড়ার সম্ভাবনা বেশি থাকে।
শেষ পর্যন্ত আমাদের ঝুঁকি কাজে লেগেছে, আমরা এটি কাজ করাতে পেরেছি এবং অ্যাপটি অনেক আগেই কন্টেন্ট ডেলিভার করা শুরু করেছে, যা আমাদের ফার্স্ট মিনিংফুল পেন্ট টাইম উল্লেখযোগ্যভাবে উন্নত করেছে।
ফলাফল
আমাদের সাইটে পারফর্ম্যান্স অপ্টিমাইজ করার জন্য আমরা অনেক কিছু করেছি। ফলাফলটি দেখে নেওয়া যাক। অপ্টিমাইজেশনের আগে ও পরে 3G নেটওয়ার্কে মাঝারি মোবাইল ডিভাইসে আমাদের অ্যাপ কীভাবে লোড হয়েছে তা এখানে দেখানো হয়েছে।
Lighthouse পারফর্ম্যান্স স্কোর ২৩ থেকে ৯১-এ পৌঁছে গেছে। স্পিডের দিক থেকে বেশ ভালোই উন্নতি হয়েছে। Lighthouse রিপোর্ট ক্রমাগত চেক ও ফলো করার মাধ্যমে আমরা এই সব পরিবর্তন করেছি। আমরা কীভাবে প্রযুক্তিগতভাবে সব উন্নতি করেছি তা দেখতে চাইলে, আমাদের রেপো, বিশেষ করে সেখানে থাকা PR-এ একবার চোখ বুলিয়ে নিন।
প্রেডিক্টিভ পারফর্ম্যান্স - ডেটা-চালিত ব্যবহারকারীর অভিজ্ঞতা
আমরা বিশ্বাস করি যে মেশিন লার্নিং অনেক ক্ষেত্রে ভবিষ্যতের জন্য একটি উত্তেজনাপূর্ণ সুযোগের প্রতিনিধিত্ব করে। একটি ধারণা যা আমরা আশা করি ভবিষ্যতে আরও পরীক্ষা-নিরীক্ষার জন্ম দেবে, তা হল আসল ডেটা সত্যিই আমাদের তৈরি করা ব্যবহারকারীর অভিজ্ঞতাকে গাইড করতে পারে।
আজ, ব্যবহারকারী কী চাইতে বা প্রয়োজন বোধ করতে পারেন, সেই সম্পর্কে আমরা অনেক স্বেচ্ছাচারী সিদ্ধান্ত নিই এবং তাই কোনটি প্রিফেচ, প্রিলোড বা প্রি-ক্যাশ করার যোগ্য। আমরা যদি সঠিকভাবে অনুমান করতে পারি, তাহলে আমরা অল্প পরিমাণ রিসোর্সকে অগ্রাধিকার দিতে পারি, কিন্তু পুরো ওয়েবসাইটে এটি স্কেল করা সত্যিই কঠিন।
আজকে আমাদের অপ্টিমাইজেশন আরও ভালোভাবে জানানোর জন্য আমাদের কাছে আসলে ডেটা উপলভ্য আছে। Google Analytics রিপোর্টিং API ব্যবহার করে আমরা আমাদের সাইটের যেকোনও URL-এর জন্য পরবর্তী সেরা পৃষ্ঠা এবং এক্সিট শতাংশ দেখতে পারি এবং তাই কোন রিসোর্সকে আমাদের অগ্রাধিকার দেওয়া উচিত সেই বিষয়ে সিদ্ধান্ত নিতে পারি।
আমরা যদি এটিকে একটি ভাল সম্ভাব্যতা মডেলের সাথে একত্রিত করি, তাহলে আমরা আগ্রাসীভাবে কন্টেন্ট প্রি-ফেচ করে আমাদের ব্যবহারকারীর ডেটা নষ্ট করা এড়াতে পারি। আমরা Google Analytics ডেটা থেকে সুবিধা নিতে পারি এবং এই ধরনের মডেল প্রয়োগ করার জন্য মেশিন লার্নিং এবং Markov chains বা নিউরাল নেটওয়ার্ক-এর মতো মডেল ব্যবহার করতে পারি।
এই এক্সপেরিমেন্ট সহজ করতে, আমরা একটি নতুন উদ্যোগের ঘোষণা করতে পেরে আনন্দিত, যেটিকে আমরা Guess.js বলছি।
Guess.js হল এমন একটি প্রোজেক্ট যা ওয়েবের জন্য ডেটা-চালিত ব্যবহারকারীর অভিজ্ঞতার উপর ফোকাস করে। আমরা আশা করি যে এটি ওয়েব পারফর্ম্যান্স উন্নত করতে এবং তার বাইরেও ডেটা ব্যবহার করার অন্বেষণকে অনুপ্রাণিত করবে। এটি সম্পূর্ণ ওপেন সোর্স এবং আজ GitHub-এ উপলভ্য। এটি ওপেন সোর্স কমিউনিটির সাথে কোলাবরেশনে তৈরি করা হয়েছে। এর সাথে যুক্ত ছিলেন মিঙ্কো গেচেভ, গ্যাটসবি থেকে কাইল ম্যাথিউস, কেটি হেম্পেনিয়াস এবং আরও অনেকে।
Guess.js চেক করে দেখুন, আপনার মতামত আমাদের জানান।
সারাংশ
স্কোর ও মেট্রিক ওয়েবের স্পিড উন্নত করার ক্ষেত্রে সহায়ক হলেও, সেগুলি শুধু উপায়, লক্ষ্য নয়।
আমরা সবাই চলতে চলতে স্লো পৃষ্ঠা লোড হওয়ার অভিজ্ঞতা পেয়েছি, তবে এখন আমাদের কাছে সুযোগ আছে ব্যবহারকারীদের আরও আনন্দদায়ক অভিজ্ঞতা প্রদান করার যা সত্যিই দ্রুত লোড হয়।
পারফর্ম্যান্স উন্নত করা একটি দীর্ঘ প্রক্রিয়া। অনেক ছোট ছোট পরিবর্তন করলে বড় লাভ হতে পারে। সঠিক অপ্টিমাইজেশন টুল ব্যবহার করে এবং Lighthouse রিপোর্টের উপর নজর রেখে, আপনি ব্যবহারকারীদের আরও ভালো এবং আরও বেশি ইনক্লুসিভ অভিজ্ঞতা প্রদান করতে পারবেন।
বিশেষ ধন্যবাদ: ওয়ার্ড পিটার্স, মিঙ্কো গেচেভ, কাইল ম্যাথিউস, কেটি হেম্পেনিয়াস, ডম ফারোলিনো, ইয়োভ ওয়েইস, সুজি লু, ইউসুকে উতসুনোমিয়া, টম অ্যাঙ্কার্স, Lighthouse ও Google ডুডল।