Google IO 2018-এ, আমরা টুল, লাইব্রেরি এবং অপ্টিমাইজেশন কৌশলগুলির একটি রাউন্ডআপ উপস্থাপন করেছি যা ওয়েব পারফরম্যান্সকে আরও সহজ করে তোলে। এখানে আমরা দ্য ওডলস থিয়েটার অ্যাপ ব্যবহার করে তাদের ব্যাখ্যা করি। আমরা ভবিষ্যদ্বাণীমূলক লোডিং এবং নতুন Guess.js উদ্যোগ নিয়ে আমাদের পরীক্ষাগুলি সম্পর্কেও কথা বলি৷
আমরা গত এক বছর ধরে ওয়েবকে কীভাবে দ্রুত এবং আরও বেশি পারফরম্যান্স করা যায় তা বের করার চেষ্টায় বেশ ব্যস্ত ছিলাম। এটি নতুন সরঞ্জাম, পদ্ধতি এবং লাইব্রেরির দিকে পরিচালিত করেছে যা আমরা এই নিবন্ধে আপনার সাথে ভাগ করতে চাই। প্রথম অংশে, আমরা আপনাকে কিছু অপ্টিমাইজেশান কৌশল দেখাব যা আমরা দ্য ওডলস থিয়েটার অ্যাপ তৈরি করার সময় অনুশীলনে ব্যবহার করেছি। দ্বিতীয় অংশে, আমরা ভবিষ্যদ্বাণীমূলক লোডিং এবং নতুন Guess.js উদ্যোগ নিয়ে আমাদের পরীক্ষা-নিরীক্ষার বিষয়ে কথা বলব।
কর্মক্ষমতা জন্য প্রয়োজন
ইন্টারনেট প্রতি বছর ভারী এবং ভারী হয়ে ওঠে। আমরা যদি ওয়েবের অবস্থা পরীক্ষা করি তাহলে আমরা দেখতে পাব যে মোবাইলের একটি মধ্যক পৃষ্ঠার ওজন প্রায় 1.5MB, যার বেশিরভাগই জাভাস্ক্রিপ্ট এবং ছবি।
নেটওয়ার্ক লেটেন্সি, CPU সীমাবদ্ধতা, রেন্ডার ব্লকিং প্যাটার্ন বা অতিরিক্ত থার্ড-পার্টি কোডের মতো অন্যান্য কারণের সাথে ওয়েবসাইটগুলির ক্রমবর্ধমান আকার জটিল কর্মক্ষমতা ধাঁধায় অবদান রাখে।
বেশিরভাগ ব্যবহারকারী তাদের প্রয়োজনের UX শ্রেণীবিন্যাসের একেবারে শীর্ষে থাকায় গতিকে রেট দেন। এটি খুব আশ্চর্যজনক নয়, কারণ একটি পৃষ্ঠা লোড করা শেষ না হওয়া পর্যন্ত আপনি সত্যিই অনেক কিছু করতে পারবেন না। আপনি পৃষ্ঠা থেকে মূল্য আহরণ করতে পারবেন না, আপনি এর নান্দনিকতার প্রশংসা করতে পারবেন না।
আমরা জানি যে পারফরম্যান্স ব্যবহারকারীদের কাছে গুরুত্বপূর্ণ, তবে এটি একটি গোপন আবিষ্কারের মতোও মনে হতে পারে যেখানে অপ্টিমাইজ করা শুরু করতে হবে৷ সৌভাগ্যবশত, এমন সরঞ্জাম রয়েছে যা আপনাকে পথে সাহায্য করতে পারে।
বাতিঘর - কর্মক্ষমতা কর্মপ্রবাহ জন্য একটি ভিত্তি
Lighthouse হল Chrome DevTools-এর একটি অংশ যা আপনাকে আপনার ওয়েবসাইটের একটি অডিট করতে দেয় এবং এটিকে কীভাবে আরও ভাল করা যায় সে সম্পর্কে আপনাকে ইঙ্গিত দেয়৷
আমরা সম্প্রতি একগুচ্ছ নতুন পারফরম্যান্স অডিট চালু করেছি যা দৈনন্দিন উন্নয়ন কর্মপ্রবাহে সত্যিই দরকারী।
আসুন একটি ব্যবহারিক উদাহরণে আপনি কীভাবে তাদের সুবিধা নিতে পারেন তা অন্বেষণ করি: The Oodles Theater অ্যাপ । এটি একটি ছোট ডেমো ওয়েব অ্যাপ, যেখানে আপনি আমাদের প্রিয় কিছু ইন্টারেক্টিভ Google ডুডল ব্যবহার করে দেখতে পারেন এবং এমনকি একটি বা দুটি গেম খেলতে পারেন৷
অ্যাপটি তৈরি করার সময়, আমরা নিশ্চিত করতে চেয়েছিলাম যে এটি যতটা সম্ভব কার্যকরী ছিল। অপ্টিমাইজেশনের সূচনা বিন্দু ছিল একটি বাতিঘর রিপোর্ট।
লাইটহাউস রিপোর্টে দেখা আমাদের অ্যাপের প্রাথমিক কর্মক্ষমতা বেশ ভয়ঙ্কর ছিল। একটি 3G নেটওয়ার্কে, ব্যবহারকারীকে প্রথম অর্থপূর্ণ পেইন্টের জন্য 15 সেকেন্ড অপেক্ষা করতে হবে, বা অ্যাপটি ইন্টারেক্টিভ হওয়ার জন্য। লাইটহাউস আমাদের সাইটের অনেক সমস্যা হাইলাইট করেছে এবং 23 এর সামগ্রিক পারফরম্যান্স স্কোর ঠিক সেটাই প্রতিফলিত করেছে।
পৃষ্ঠাটির ওজন প্রায় 3.4MB - আমাদের কিছু চর্বি কাটতে হবে।
এটি আমাদের প্রথম পারফরম্যান্স চ্যালেঞ্জ শুরু করেছে: সামগ্রিক অভিজ্ঞতাকে প্রভাবিত না করেই আমরা সহজেই সরাতে পারি এমন জিনিসগুলি খুঁজুন।
কর্মক্ষমতা অপ্টিমাইজেশান সুযোগ
অপ্রয়োজনীয় সম্পদ সরান
কিছু সুস্পষ্ট জিনিস আছে যা নিরাপদে সরানো যেতে পারে: হোয়াইটস্পেস এবং মন্তব্য।
Lighthouse Unminified CSS এবং JavaScript অডিটে এই সুযোগটিকে হাইলাইট করে। আমরা আমাদের বিল্ড প্রসেসের জন্য ওয়েবপ্যাক ব্যবহার করছিলাম, তাই মিনিফিকেশন পাওয়ার জন্য আমরা সহজভাবে Uglify JS প্লাগইন ব্যবহার করেছি।
মিনিফিকেশন একটি সাধারণ কাজ, তাই আপনি যে কোনও বিল্ড প্রক্রিয়া ব্যবহার করবেন তার জন্য একটি প্রস্তুত সমাধান খুঁজে পেতে সক্ষম হওয়া উচিত।
সেই স্থানের আরেকটি দরকারী অডিট হল টেক্সট কম্প্রেশন সক্ষম করুন । অসংকুচিত ফাইল পাঠানোর কোন কারণ নেই, এবং বেশিরভাগ CDN এই দিনগুলিকে বাক্সের বাইরে সমর্থন করে।
আমরা আমাদের কোড হোস্ট করার জন্য ফায়ারবেস হোস্টিং ব্যবহার করছিলাম, এবং ফায়ারবেস ডিফল্টভাবে জিজিপিং সক্ষম করে, তাই যুক্তিসঙ্গত CDN-এ আমাদের কোড হোস্ট করার নিছক গুণে আমরা এটি বিনামূল্যে পেয়েছি।
যদিও gzip কম্প্রেস করার একটি খুব জনপ্রিয় উপায়, অন্যান্য মেকানিজম যেমন Zopfli এবং Brotli ও ট্র্যাকশন পাচ্ছে। ব্রোটলি বেশিরভাগ ব্রাউজারে সমর্থন উপভোগ করে এবং আপনি সার্ভারে পাঠানোর আগে আপনার সম্পদগুলিকে প্রাক-সংকুচিত করতে একটি বাইনারি ব্যবহার করতে পারেন।
দক্ষ ক্যাশে নীতি ব্যবহার করুন
অপ্রয়োজনীয় হলে আমরা দুবার রিসোর্স না পাঠাই তা নিশ্চিত করা আমাদের পরবর্তী পদক্ষেপ ছিল।
লাইটহাউসের অদক্ষ ক্যাশে নীতি নিরীক্ষা আমাদের লক্ষ্য করতে সাহায্য করেছে যে আমরা ঠিক এটি অর্জন করার জন্য আমাদের ক্যাশিং কৌশলগুলি অপ্টিমাইজ করতে পারি। আমাদের সার্ভারে একটি সর্বোচ্চ-বয়স মেয়াদ শেষ হওয়ার শিরোনাম সেট করে, আমরা নিশ্চিত করেছি যে বারবার ভিজিট করলে ব্যবহারকারী তাদের আগে ডাউনলোড করা সংস্থানগুলি পুনরায় ব্যবহার করতে পারে।
আদর্শভাবে আপনার লক্ষ্য হওয়া উচিত যতটা সম্ভব দীর্ঘতম সময়ের জন্য নিরাপদে যতটা সম্ভব সম্পদ ক্যাশে করা এবং আপডেট হওয়া সংস্থানগুলির কার্যকরী পুনর্বিবেচনার জন্য বৈধতা টোকেন প্রদান করা।
অব্যবহৃত কোড সরান
এখন পর্যন্ত আমরা অপ্রয়োজনীয় ডাউনলোডের সুস্পষ্ট অংশগুলি সরিয়ে ফেলেছি, তবে কম স্পষ্ট অংশগুলির কী হবে? উদাহরণস্বরূপ, অব্যবহৃত কোড।
কখনও কখনও আমরা আমাদের অ্যাপস কোডে অন্তর্ভুক্ত করি যা সত্যিই প্রয়োজনীয় নয়। এটি বিশেষত যদি আপনি আপনার অ্যাপে দীর্ঘ সময়ের জন্য কাজ করেন, আপনার দল বা আপনার নির্ভরতা পরিবর্তিত হয় এবং কখনও কখনও একটি অনাথ লাইব্রেরি পিছনে পড়ে যায়। আমাদের ক্ষেত্রে ঠিক তাই হয়েছে।
শুরুতে আমরা আমাদের অ্যাপটিকে দ্রুত প্রোটোটাইপ করার জন্য ম্যাটেরিয়াল কম্পোনেন্ট লাইব্রেরি ব্যবহার করছিলাম। সময়ের সাথে সাথে আমরা আরও কাস্টম চেহারা এবং অনুভূতিতে চলে এসেছি এবং আমরা সেই লাইব্রেরি সম্পর্কে সম্পূর্ণ ভুলে গেছি। সৌভাগ্যবশত, কোড কভারেজ চেক আমাদের বান্ডেলে এটি পুনরায় আবিষ্কার করতে সাহায্য করেছে।
আপনি DevTools-এ আপনার কোড কভারেজ পরিসংখ্যান পরীক্ষা করতে পারেন, আপনার অ্যাপ্লিকেশনের রানটাইম এবং লোড সময়ের জন্য। আপনি নীচের স্ক্রিনশটে দুটি বড় লাল স্ট্রাইপ দেখতে পাচ্ছেন - আমাদের সিএসএসের 95% এরও বেশি অব্যবহৃত ছিল এবং জাভাস্ক্রিপ্টের একটি বড় গুচ্ছও ছিল।
Lighthouse এছাড়াও অব্যবহৃত CSS নিয়ম নিরীক্ষা এই সমস্যা বাছাই. এটি 400kb এর বেশি সম্ভাব্য সঞ্চয় দেখিয়েছে। তাই আমরা আমাদের কোডে ফিরে এসেছি এবং আমরা সেই লাইব্রেরির জাভাস্ক্রিপ্ট এবং সিএসএস উভয় অংশই সরিয়ে দিয়েছি।
এটি আমাদের CSS বান্ডেলকে 20-গুণ নিচে নিয়ে এসেছে, যা একটি ছোট, দুই-লাইন-দীর্ঘ কমিটের জন্য বেশ ভাল।
অবশ্যই, এটি আমাদের পারফরম্যান্সের স্কোরকে বাড়িয়ে দিয়েছে, এবং টাইম টু ইন্টারঅ্যাকটিভও অনেক ভালো হয়েছে।
যাইহোক, এই ধরনের পরিবর্তনের সাথে, শুধুমাত্র আপনার মেট্রিক্স এবং স্কোর পরীক্ষা করা যথেষ্ট নয়। প্রকৃত কোড সরানো কখনই ঝুঁকিমুক্ত নয়, তাই আপনার সর্বদা সম্ভাব্য রিগ্রেশনের দিকে নজর দেওয়া উচিত।
আমাদের কোড 95% অব্যবহৃত ছিল - এখনও এই 5% কোথাও আছে। দৃশ্যত আমাদের উপাদানগুলির মধ্যে একটি এখনও সেই লাইব্রেরির শৈলীগুলি ব্যবহার করছে - ডুডল স্লাইডারে ছোট তীরগুলি৷ যদিও এটি এত ছোট ছিল, আমরা কেবল যেতে পারি এবং ম্যানুয়ালি সেই শৈলীগুলিকে বোতামগুলিতে অন্তর্ভুক্ত করতে পারি।
তাই আপনি যদি কোডটি সরিয়ে দেন, তবে নিশ্চিত করুন যে আপনার কাছে সম্ভাব্য ভিজ্যুয়াল রিগ্রেশন থেকে রক্ষা পেতে সাহায্য করার জন্য সঠিক পরীক্ষার ওয়ার্কফ্লো রয়েছে।
বিশাল নেটওয়ার্ক পেলোড এড়িয়ে চলুন
আমরা জানি যে বৃহৎ সম্পদ ওয়েব পৃষ্ঠার লোড কমিয়ে দিতে পারে। তারা আমাদের ব্যবহারকারীদের অর্থ ব্যয় করতে পারে এবং তারা তাদের ডেটা প্ল্যানগুলিতে একটি বড় প্রভাব ফেলতে পারে, তাই এটি সম্পর্কে সচেতন হওয়া সত্যিই গুরুত্বপূর্ণ।
লাইটহাউস শনাক্ত করতে সক্ষম হয়েছিল যে আমাদের কিছু নেটওয়ার্ক পেলোডের সাথে আমাদের সমস্যা ছিল এনরমাস নেটওয়ার্ক পেলোড অডিট ব্যবহার করে।
এখানে আমরা দেখেছি যে আমাদের কাছে 3mb-এর বেশি মূল্যের কোড রয়েছে যা নীচে পাঠানো হচ্ছে – যা অনেক বেশি, বিশেষ করে মোবাইলে।
এই তালিকার একেবারে শীর্ষে, Lighthouse হাইলাইট করেছে যে আমাদের কাছে একটি জাভাস্ক্রিপ্ট বিক্রেতা বান্ডিল ছিল যা 2mb কম্প্রেসড কোড ছিল। এটি ওয়েবপ্যাক দ্বারা হাইলাইট করা একটি সমস্যা।
প্রবাদটি হিসাবে: দ্রুততম অনুরোধটি হল যা তৈরি করা হয়নি।
আদর্শভাবে আপনার প্রতিটি একক সম্পদের মূল্য পরিমাপ করা উচিত যা আপনি আপনার ব্যবহারকারীদের কাছে পরিবেশন করছেন, সেই সম্পদগুলির কার্যকারিতা পরিমাপ করা এবং প্রাথমিক অভিজ্ঞতার সাথে এটি আসলে শিপিং করা মূল্যবান কিনা তা নিয়ে একটি কল করা উচিত। কারণ কখনও কখনও এই সম্পদগুলি স্থগিত করা যেতে পারে, বা অলসভাবে লোড করা যেতে পারে, বা নিষ্ক্রিয় সময়ে প্রক্রিয়া করা যেতে পারে।
আমাদের ক্ষেত্রে, যেহেতু আমরা প্রচুর জাভাস্ক্রিপ্ট বান্ডিল নিয়ে কাজ করছি, আমরা ভাগ্যবান ছিলাম কারণ জাভাস্ক্রিপ্ট সম্প্রদায়ের জাভাস্ক্রিপ্ট বান্ডিল অডিটিং টুলগুলির একটি সমৃদ্ধ সেট রয়েছে।
আমরা ওয়েবপ্যাক বান্ডেল বিশ্লেষক দিয়ে শুরু করেছি, যা আমাদের জানিয়েছিল যে আমরা ইউনিকোড নামক একটি নির্ভরতা অন্তর্ভুক্ত করছি যা পার্স করা জাভাস্ক্রিপ্টের 1.6mb, তাই অনেক বেশি।
তারপরে আমরা আমাদের সম্পাদকের কাছে গিয়েছিলাম এবং ভিজ্যুয়াল কোডের জন্য আমদানি খরচ প্লাগইন ব্যবহার করে আমরা আমদানি করা প্রতিটি মডিউলের খরচ কল্পনা করতে সক্ষম হয়েছি। এটি আমাদের এই মডিউলটি উল্লেখ করে এমন কোড সহ কোন উপাদানটি আবিষ্কার করার অনুমতি দিয়েছে।
তারপরে আমরা অন্য একটি টুল, BundlePhobia- এ চলে যাই। এটি এমন একটি টুল যা আপনাকে যেকোনো NPM প্যাকেজের নামে প্রবেশ করতে দেয় এবং প্রকৃতপক্ষে এটির ছোট এবং জিজিপড আকার অনুমান করা হয় তা দেখতে দেয়। আমরা যে স্লাগ মডিউলটি ব্যবহার করছিলাম তার জন্য আমরা একটি চমৎকার বিকল্প খুঁজে পেয়েছি যার ওজন ছিল মাত্র 2.2kb, এবং তাই আমরা সেটিকে পরিবর্তন করেছি।
এটি আমাদের পারফরম্যান্সে একটি বড় প্রভাব ফেলেছিল। এই পরিবর্তন এবং আমাদের জাভাস্ক্রিপ্ট বান্ডেলের আকার ছোট করার অন্যান্য সুযোগ আবিষ্কার করার মধ্যে, আমরা 2.1mb কোড সংরক্ষণ করেছি।
আপনি একবার এই বান্ডেলগুলির জিজিপড এবং ছোট আকারের উপর ভিত্তি করে আমরা সামগ্রিকভাবে 65% উন্নতি দেখেছি। এবং আমরা খুঁজে পেয়েছি যে এটি একটি প্রক্রিয়া হিসাবে সত্যিই মূল্যবান ছিল।
সুতরাং, সাধারণভাবে, আপনার সাইট এবং অ্যাপগুলিতে অপ্রয়োজনীয় ডাউনলোডগুলি দূর করার চেষ্টা করুন। আপনার সম্পদের একটি ইনভেন্টরি তৈরি করুন এবং তাদের কার্যক্ষমতার প্রভাব পরিমাপ করলে তা সত্যিই একটি বড় পার্থক্য আনতে পারে, তাই নিশ্চিত করুন যে আপনি নিয়মিতভাবে আপনার সম্পদের অডিট করছেন।
কোড বিভাজন সহ নিম্ন জাভাস্ক্রিপ্ট বুট-আপ সময়
যদিও বড় নেটওয়ার্ক পেলোডগুলি আমাদের অ্যাপে একটি বড় প্রভাব ফেলতে পারে, তবে আরেকটি জিনিস রয়েছে যা সত্যিই বড় প্রভাব ফেলতে পারে, এবং সেটি হল জাভাস্ক্রিপ্ট৷
জাভাস্ক্রিপ্ট আপনার সবচেয়ে ব্যয়বহুল সম্পদ । মোবাইলে, আপনি যদি জাভাস্ক্রিপ্টের বড় বান্ডিল পাঠান, তাহলে আপনার ব্যবহারকারীরা কত তাড়াতাড়ি আপনার ব্যবহারকারী ইন্টারফেস উপাদানগুলির সাথে ইন্টারঅ্যাক্ট করতে পারবে তা বিলম্বিত করতে পারে। এর মানে তারা বাস্তবে অর্থপূর্ণ কিছু না ঘটিয়ে UI-তে ট্যাপ করতে পারে। সুতরাং জাভাস্ক্রিপ্টের এত দাম কেন তা বোঝা আমাদের জন্য গুরুত্বপূর্ণ।
এইভাবে একটি ব্রাউজার জাভাস্ক্রিপ্ট প্রক্রিয়া করে।
আমাদের সবার আগে সেই স্ক্রিপ্টটি ডাউনলোড করতে হবে, আমাদের একটি জাভাস্ক্রিপ্ট ইঞ্জিন আছে যা তারপর সেই কোডটি পার্স করতে হবে, এটিকে কম্পাইল করতে হবে এবং এটি কার্যকর করতে হবে।
এখন এই পর্যায়গুলি এমন কিছু যা একটি ডেস্কটপ মেশিন বা একটি ল্যাপটপের মতো একটি উচ্চ-সম্পদ ডিভাইসে, এমনকি একটি উচ্চ-সম্পন্ন ফোনেও সম্পূর্ণ সময় নেয় না। কিন্তু একটি মিডিয়ান মোবাইল ফোনে এই প্রক্রিয়াটি পাঁচ থেকে দশ গুণ বেশি সময় নিতে পারে। এটিই ইন্টারঅ্যাক্টিভিটি বিলম্বিত করে, তাই এটি কমানোর চেষ্টা করা আমাদের জন্য গুরুত্বপূর্ণ।
আপনার অ্যাপের সাথে এই সমস্যাগুলি আবিষ্কার করতে আপনাকে সাহায্য করার জন্য, আমরা Lighthouse-এ একটি নতুন JavaScript বুট-আপ টাইম অডিট চালু করেছি।
এবং Oodle অ্যাপের ক্ষেত্রে, এটি আমাদের বলেছিল যে আমাদের জাভাস্ক্রিপ্ট বুট-আপে 1.8 সেকেন্ড সময় ব্যয় হয়েছে। যা ঘটছিল তা হল যে আমরা আমাদের সমস্ত রুট এবং উপাদানগুলিকে একটি একচেটিয়া জাভাস্ক্রিপ্ট বান্ডিলে স্থিতিশীলভাবে আমদানি করছিলাম।
এটির চারপাশে কাজ করার একটি কৌশল হল কোড বিভাজন ব্যবহার করা।
কোড স্প্লিটিং হল আপনার ব্যবহারকারীদের পুরো পিজ্জার মূল্যের জাভাস্ক্রিপ্ট দেওয়ার পরিবর্তে এই ধারণাটি, আপনি যদি তাদের প্রয়োজন অনুসারে একবারে একটি স্লাইস দেন?
কোড বিভাজন একটি রুট স্তর বা একটি উপাদান স্তরে প্রয়োগ করা যেতে পারে। এটি React এবং React Loadable, Vue.js, Angular, Polymer, Preact এবং অন্যান্য একাধিক লাইব্রেরির সাথে দারুণ কাজ করে।
আমরা আমাদের অ্যাপ্লিকেশনে কোড স্প্লিটিং অন্তর্ভুক্ত করেছি, আমরা স্ট্যাটিক ইম্পোর্ট থেকে ডাইনামিক ইম্পোর্টে সুইচ ওভার করেছি, আমাদের প্রয়োজন অনুযায়ী অ্যাসিঙ্ক্রোনাসভাবে অলসভাবে লোড কোড করার অনুমতি দিয়েছি।
এটির প্রভাব উভয়ই আমাদের বান্ডেলের আকারকে সঙ্কুচিত করছে, কিন্তু আমাদের জাভাস্ক্রিপ্ট বুট আপের সময়ও কমিয়েছে। এটি এটিকে 0.78 সেকেন্ডে নিয়ে গেছে, অ্যাপটিকে 56% দ্রুততর করেছে।
সাধারণভাবে, আপনি যদি একটি জাভাস্ক্রিপ্ট-ভারী অভিজ্ঞতা তৈরি করেন, তবে নিশ্চিত করুন যে শুধুমাত্র ব্যবহারকারীর কাছে তাদের প্রয়োজনীয় কোড পাঠান।
কোড স্প্লিটিং এর মত ধারণার সুবিধা নিন, গাছ কাঁপানোর মত ধারনাগুলি অন্বেষণ করুন এবং ওয়েবপ্যাক-লিবস-অপ্টিমাইজেশন রেপো দেখুন আপনি যদি ওয়েবপ্যাক ব্যবহার করে থাকেন তবে কীভাবে আপনি আপনার লাইব্রেরির আকার ছোট করতে পারেন সে সম্পর্কে কয়েকটি ধারণার জন্য।
ইমেজ অপ্টিমাইজ করুন
Oodle অ্যাপে আমরা অনেক ছবি ব্যবহার করছি। দুর্ভাগ্যবশত, লাইটহাউস আমাদের তুলনায় অনেক কম উত্সাহী ছিল। প্রকৃতপক্ষে, আমরা তিনটি চিত্র-সম্পর্কিত অডিটে ব্যর্থ হয়েছি।
আমরা আমাদের ছবিগুলি অপ্টিমাইজ করতে ভুলে গেছি, আমরা সেগুলিকে সঠিকভাবে আকার দিচ্ছিলাম না, এবং এছাড়াও আমরা অন্যান্য ইমেজ ফরম্যাট ব্যবহার করে কিছু লাভ পেতে পারি।
আমরা আমাদের ইমেজ অপ্টিমাইজ করা সঙ্গে শুরু.
ওয়ান-অফ অপ্টিমাইজেশন রাউন্ডের জন্য আপনি ImageOptim বা XNConvert এর মত ভিজ্যুয়াল টুল ব্যবহার করতে পারেন।
একটি আরো স্বয়ংক্রিয় পদ্ধতি হল আপনার বিল্ড প্রক্রিয়াতে ইমেজমিনের মতো লাইব্রেরি সহ একটি ইমেজ অপ্টিমাইজেশান ধাপ যুক্ত করা।
এইভাবে আপনি নিশ্চিত করুন যে ভবিষ্যতে যোগ করা ছবিগুলি স্বয়ংক্রিয়ভাবে অপ্টিমাইজ করা হবে। কিছু CDN, যেমন Akamai বা তৃতীয় পক্ষের সমাধান যেমন Cloudinary , Fastly বা Uploadcare আপনাকে ব্যাপক ইমেজ অপ্টিমাইজেশান সমাধান অফার করে। তাই আপনি কেবল সেই পরিষেবাগুলিতে আপনার ছবিগুলি হোস্ট করতে পারেন৷
আপনি যদি খরচ, বা লেটেন্সি সমস্যার কারণে এটি করতে না চান, তাহলে Thumbor বা Imageflow এর মতো প্রকল্পগুলি স্ব-হোস্ট করা বিকল্পগুলি অফার করে৷
আমাদের ব্যাকগ্রাউন্ড PNG ওয়েবপ্যাকে বড় হিসাবে পতাকাঙ্কিত ছিল, এবং ঠিক তাই। ভিউপোর্টে সঠিকভাবে আকার দেওয়ার পরে এবং ImageOptim এর মাধ্যমে এটি চালানোর পরে, আমরা 100kb-এ নেমে এসেছি, যা গ্রহণযোগ্য।
আমাদের সাইটে একাধিক ছবির জন্য এটি পুনরাবৃত্তি করা আমাদের সামগ্রিক পৃষ্ঠার ওজন উল্লেখযোগ্যভাবে কমিয়ে আনতে দেয়।
অ্যানিমেটেড কন্টেন্টের জন্য সঠিক বিন্যাস ব্যবহার করুন
GIF সত্যিই ব্যয়বহুল হতে পারে। আশ্চর্যজনকভাবে, জিআইএফ ফর্ম্যাটটি প্রথম স্থানে অ্যানিমেশন প্ল্যাটফর্ম হিসাবে কখনই উদ্দেশ্য ছিল না। অতএব, একটি আরও উপযুক্ত ভিডিও বিন্যাসে স্যুইচ করা আপনাকে ফাইলের আকারের ক্ষেত্রে বড় সঞ্চয় প্রদান করে।
Oodle অ্যাপে, আমরা হোম পেজে একটি ইন্ট্রো সিকোয়েন্স হিসেবে একটি GIF ব্যবহার করছিলাম। লাইটহাউসের মতে, আমরা আরও দক্ষ ভিডিও ফর্ম্যাটে স্যুইচ করে 7mb-এর বেশি সংরক্ষণ করতে পারি। আমাদের ক্লিপের ওজন প্রায় 7.3mb, যেকোনো যুক্তিসঙ্গত ওয়েবসাইটের জন্য অনেক বেশি, তাই এর পরিবর্তে আমরা এটিকে দুটি উৎস ফাইল সহ একটি ভিডিও উপাদানে পরিণত করেছি - একটি mp4 এবং বৃহত্তর ব্রাউজার সমর্থনের জন্য WebM৷
আমরা আমাদের অ্যানিমেশন GIF কে mp4 ফাইলে রূপান্তর করতে FFmpeg টুল ব্যবহার করেছি। WebM ফর্ম্যাট আপনাকে আরও বড় সঞ্চয় অফার করে - ImageOptim API আপনার জন্য এই ধরনের রূপান্তর করতে পারে।
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
এই রূপান্তরের জন্য আমরা আমাদের সামগ্রিক ওজনের 80% এর বেশি সংরক্ষণ করতে পেরেছি। এটি আমাদের প্রায় 1mb-এ নেমে এসেছে।
তারপরও, 1mb তারের নিচে ধাক্কা দেওয়ার জন্য একটি বড় সম্পদ, বিশেষ করে একটি সীমাবদ্ধ ব্যান্ডউইথ ব্যবহারকারীর জন্য। সৌভাগ্যবশত আমরা কার্যকর টাইপ এপিআই ব্যবহার করতে পারি বুঝতে পারি যে তারা একটি ধীর ব্যান্ডউইথের উপর রয়েছে, এবং পরিবর্তে তাদের অনেক ছোট 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 আসলে এই বৈশিষ্ট্যগুলির কিছু কার্যকরভাবে ব্যবহার করার দিকে আমাদের গাইড করে।
লাইটহাউস আমাদেরকে প্রথম যে জিনিসটি করতে বলে তা হল যে কোনও উত্সের একাধিক ব্যয়বহুল রাউন্ড ট্রিপ এড়ানো৷
Oodle অ্যাপের ক্ষেত্রে, আমরা আসলে ব্যাপকভাবে গুগল ফন্ট ব্যবহার করছি। আপনি যখনই আপনার পৃষ্ঠায় একটি Google ফন্ট স্টাইলশীট ড্রপ করবেন তখন এটি দুটি সাবডোমেন পর্যন্ত সংযুক্ত হবে। এবং লাইটহাউস আমাদের যা বলছে তা হল যে আমরা যদি সেই সংযোগটিকে উষ্ণ করতে সক্ষম হই, আমরা আমাদের প্রাথমিক সংযোগের সময়ে 300 মিলিসেকেন্ড পর্যন্ত যে কোনও জায়গায় সংরক্ষণ করতে পারি।
লিঙ্ক রিল প্রি-কানেক্টের সুবিধা নিয়ে, আমরা কার্যকরভাবে সেই সংযোগের লেটেন্সিটি মাস্ক করতে পারি।
বিশেষ করে Google ফন্টের মতো কিছু যেখানে আমাদের ফন্ট ফেস সিএসএস googleapis.com- এ হোস্ট করা হয় এবং আমাদের ফন্ট রিসোর্স Gstatic- এ হোস্ট করা হয়, এটি সত্যিই একটি বড় প্রভাব ফেলতে পারে। তাই আমরা এই অপ্টিমাইজেশানটি প্রয়োগ করেছি এবং আমরা কয়েকশ মিলিসেকেন্ড শেভ করেছি।
Lighthouse পরামর্শ দেয় যে পরবর্তী জিনিস আমরা কী অনুরোধ প্রিলোড.
<link rel=preload> সত্যিই শক্তিশালী, এটি ব্রাউজারকে জানিয়ে দেয় যে বর্তমান নেভিগেশনের অংশ হিসাবে একটি সংস্থান প্রয়োজন, এবং এটি যত তাড়াতাড়ি সম্ভব ব্রাউজারটি আনার চেষ্টা করে।
এখন এখানে লাইটহাউস আমাদের বলছে যে আমাদের যাওয়া উচিত এবং আমাদের মূল ওয়েব ফন্ট সংস্থানগুলি প্রিলোড করা উচিত, কারণ আমরা দুটি ওয়েব ফন্টে লোড করছি।
একটি ওয়েব ফন্টে প্রিলোড করা এইরকম দেখায় - rel=preload নির্দিষ্ট করে, আপনি ফন্টের প্রকারের as পাস করেন, এবং তারপর আপনি যে ফন্টটি লোড করার চেষ্টা করছেন তা নির্দিষ্ট করুন, যেমন woff2।
এটি আপনার পৃষ্ঠায় যে প্রভাব ফেলতে পারে তা বেশ কঠোর।
সাধারণত, লিঙ্ক rel প্রিলোড ব্যবহার না করে, যদি ওয়েব ফন্টগুলি আপনার পৃষ্ঠার জন্য সমালোচনামূলক হয়, তাহলে ব্রাউজারকে যা করতে হবে তা হল প্রথমে আপনার HTML আনতে হবে, আপনার CSS পার্স করতে হবে এবং অনেক পরে লাইনের নিচে কোথাও, এটি অবশেষে যাবে এবং আপনার ওয়েব ফন্ট আনবে।
লিঙ্ক রিল প্রিলোড ব্যবহার করে, ব্রাউজারটি আপনার এইচটিএমএল পার্স করার সাথে সাথে এটি আসলে সেই ওয়েব ফন্টগুলিকে অনেক আগে আনা শুরু করতে পারে। আমাদের অ্যাপের ক্ষেত্রে, এটি আমাদের ওয়েব ফন্ট ব্যবহার করে টেক্সট রেন্ডার করতে যে সময় লেগেছে তা এক সেকেন্ড কমিয়ে দিতে সক্ষম হয়েছে।
এখন এটা খুব সহজ নয় যদি আপনি Google ফন্ট ব্যবহার করে ফন্ট প্রিলোড করার চেষ্টা করতে যাচ্ছেন, সেখানে একটি পাওয়া যাবে।
আমরা আমাদের স্টাইলশীটে আমাদের ফন্টের মুখগুলিতে যে Google ফন্ট ইউআরএলগুলি নির্দিষ্ট করি সেগুলি এমন কিছু হয়েছে যা ফন্ট টিম মোটামুটি নিয়মিত আপডেট করে। এই ইউআরএলগুলির মেয়াদ শেষ হতে পারে, বা নিয়মিত ফ্রিকোয়েন্সিতে আপডেট হতে পারে, এবং তাই আপনি যদি আপনার ফন্ট লোডিং অভিজ্ঞতার উপর সম্পূর্ণ নিয়ন্ত্রণ চান তবে আমরা যা করতে চাই তা হল আপনার ওয়েব ফন্টগুলি স্ব-হোস্ট করা। এটি দুর্দান্ত হতে পারে কারণ এটি আপনাকে লিঙ্ক রিল প্রিলোডের মতো জিনিসগুলিতে অ্যাক্সেস দেয়।
আমাদের ক্ষেত্রে আমরা Google Web Fonts Helper টুলটিকে সেই ওয়েব ফন্টগুলির কিছু অফলাইনে সাহায্য করতে এবং সেগুলিকে স্থানীয়ভাবে সেট আপ করতে সত্যিই দরকারী খুঁজে পেয়েছি, তাই সেই টুলটি পরীক্ষা করে দেখুন৷
আপনি আপনার গুরুত্বপূর্ণ সংস্থানগুলির অংশ হিসাবে ওয়েব ফন্টগুলি ব্যবহার করছেন বা এটি জাভাস্ক্রিপ্ট হিসাবে ঘটছে না কেন, ব্রাউজারটিকে যত তাড়াতাড়ি সম্ভব আপনার গুরুত্বপূর্ণ সংস্থানগুলি সরবরাহ করতে সহায়তা করার চেষ্টা করুন৷
পরীক্ষামূলক: অগ্রাধিকার ইঙ্গিত
আমরা আজ আপনার সাথে শেয়ার করার জন্য বিশেষ কিছু আছে. রিসোর্স ইঙ্গিত এবং প্রিলোডের মতো বৈশিষ্ট্যগুলি ছাড়াও, আমরা একটি একেবারে নতুন পরীক্ষামূলক ব্রাউজার বৈশিষ্ট্য নিয়ে কাজ করছি যাকে আমরা অগ্রাধিকার ইঙ্গিত বলছি৷
এটি একটি নতুন বৈশিষ্ট্য যা আপনাকে ব্রাউজারে ইঙ্গিত করতে দেয় যে একটি সংস্থান কতটা গুরুত্বপূর্ণ। এটি একটি নতুন বৈশিষ্ট্য প্রকাশ করে - গুরুত্ব - কম, উচ্চ বা স্বয়ংক্রিয় মান সহ।
এটি আমাদের কম গুরুত্বপূর্ণ সংস্থানগুলির অগ্রাধিকার হ্রাস করার অনুমতি দেয়, যেমন অ-সমালোচনামূলক শৈলী, চিত্র, বা বিতর্ক কমাতে API কল আনতে। আমরা আমাদের নায়কের ছবিগুলির মতো আরও গুরুত্বপূর্ণ জিনিসগুলির অগ্রাধিকারও বাড়িয়ে তুলতে পারি।
আমাদের Oodle অ্যাপের ক্ষেত্রে, এটি আসলে একটি ব্যবহারিক জায়গার দিকে নিয়ে গেছে যেখানে আমরা অপ্টিমাইজ করতে পারি।
আমরা আমাদের চিত্রগুলিতে অলস লোডিং যোগ করার আগে, ব্রাউজারটি যা করছিল তা হল, আমাদের সমস্ত ডুডলগুলির সাথে আমাদের এই চিত্র ক্যারোজেলটি ছিল এবং ব্রাউজারটি ক্যারোজেলের একেবারে শুরুতে একটি উচ্চ অগ্রাধিকার দিয়ে সমস্ত ছবি নিয়ে আসছিল৷ দুর্ভাগ্যবশত, এটি ছিল ক্যারোজেলের মাঝখানের ছবি যা ব্যবহারকারীর কাছে সবচেয়ে গুরুত্বপূর্ণ ছিল। তাই আমরা যা করেছি তা হল, আমরা সেই ব্যাকগ্রাউন্ড ইমেজগুলির গুরুত্বকে খুব কম, ফোরগ্রাউন্ডেরগুলিকে খুব উচ্চে সেট করেছি, এবং ধীরগতির 3G এর উপর এটির দুই সেকেন্ডের প্রভাব ছিল, এবং আমরা কত দ্রুত সেই ছবিগুলি আনতে এবং রেন্ডার করতে সক্ষম হয়েছি। . তাই একটি চমৎকার ইতিবাচক অভিজ্ঞতা.
আমরা কয়েক সপ্তাহের মধ্যে ক্যানারিতে এই বৈশিষ্ট্যটি আনতে আশা করছি, তাই এটির জন্য নজর রাখুন।
একটি ওয়েব ফন্ট লোডিং কৌশল আছে
টাইপোগ্রাফি ভাল ডিজাইনের জন্য মৌলিক, এবং আপনি যদি ওয়েব ফন্ট ব্যবহার করেন তবে আপনি আদর্শভাবে আপনার পাঠ্যের রেন্ডারিং ব্লক করতে চান না এবং আপনি অবশ্যই অদৃশ্য পাঠ্য দেখাতে চান না।
ওয়েব ফন্ট অডিট লোড করার সময় অদৃশ্য টেক্সট এড়িয়ে চলুন আমরা এখন লাইটহাউসে এটি হাইলাইট করি।
আপনি যদি একটি ফন্ট ফেস ব্লক ব্যবহার করে আপনার ওয়েব ফন্টগুলি লোড করেন, তাহলে আপনি ব্রাউজারকে সিদ্ধান্ত নিতে দিচ্ছেন যে ওয়েব ফন্টটি আনতে দীর্ঘ সময় লাগলে কি করতে হবে৷ কিছু ব্রাউজার সিস্টেম ফন্টে ফিরে আসার আগে এটির জন্য যে কোনও জায়গায় তিন সেকেন্ড পর্যন্ত অপেক্ষা করবে এবং এটি ডাউনলোড হয়ে গেলে তারা অবশেষে এটিকে ফন্টে অদলবদল করবে।
আমরা এই অদৃশ্য পাঠ্যটি এড়াতে চেষ্টা করছি, তাই এই ক্ষেত্রে আমরা এই সপ্তাহের ক্লাসিক ডুডলগুলি দেখতে পারতাম না যদি ওয়েব ফন্টটি খুব বেশি সময় নেয়। সৌভাগ্যক্রমে, 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-এর ওয়েব ফন্ট রেসিপি রেপোও দেখুন, কারণ এটি সত্যিই দুর্দান্ত৷
রেন্ডার-ব্লকিং স্ক্রিপ্টগুলি হ্রাস করুন
আমাদের অ্যাপ্লিকেশনের অন্যান্য অংশ রয়েছে যেগুলিকে আমরা ডাউনলোড চেইনে আগে চাপতে পারি যাতে কিছুটা আগে অন্তত কিছু মৌলিক ব্যবহারকারীর অভিজ্ঞতা প্রদান করা যায়।
লাইটহাউস টাইমলাইন স্ট্রিপে আপনি দেখতে পাচ্ছেন যে এই প্রথম কয়েক সেকেন্ডের মধ্যে যখন সমস্ত সংস্থান লোড হচ্ছে, ব্যবহারকারী সত্যিই কোনও সামগ্রী দেখতে পারে না৷
বাহ্যিক স্টাইলশীটগুলি ডাউনলোড এবং প্রক্রিয়াকরণ আমাদের রেন্ডারিং প্রক্রিয়াকে কোনো অগ্রগতি করতে বাধা দিচ্ছে৷
আমরা কিছু স্টাইল একটু আগে ডেলিভার করে আমাদের সমালোচনামূলক রেন্ডারিং পাথকে অপ্টিমাইজ করার চেষ্টা করতে পারি।
যদি আমরা এই প্রাথমিক রেন্ডারের জন্য দায়ী শৈলীগুলি বের করি এবং সেগুলিকে আমাদের HTML-এ ইনলাইন করি, তাহলে ব্রাউজার বহিরাগত স্টাইলশীট আসার জন্য অপেক্ষা না করে সরাসরি সেগুলি রেন্ডার করতে সক্ষম হবে৷
আমাদের ক্ষেত্রে, আমরা একটি বিল্ড স্টেপের সময় index.html এ আমাদের সমালোচনামূলক বিষয়বস্তু ইনলাইন করার জন্য Critical নামক একটি NPM মডিউল ব্যবহার করেছি।
যদিও এই মডিউলটি আমাদের জন্য বেশিরভাগ ভারী উত্তোলন করেছিল, তখনও বিভিন্ন রুট জুড়ে এই কাজটি সহজে করা কিছুটা কঠিন ছিল।
আপনি যদি সতর্ক না হন বা আপনার সাইটের গঠন সত্যিই জটিল হয়, আপনি যদি প্রথম থেকেই অ্যাপ শেল আর্কিটেকচারের পরিকল্পনা না করেন তাহলে এই ধরনের প্যাটার্ন চালু করা সত্যিই কঠিন হতে পারে।
এই কারণেই প্রথম দিকে কর্মক্ষমতা বিবেচনা করা এত গুরুত্বপূর্ণ। আপনি যদি শুরু থেকে কর্মক্ষমতার জন্য ডিজাইন না করেন, তাহলে পরবর্তীতে এটি করতে গিয়ে সমস্যার সম্মুখীন হওয়ার একটি উচ্চ সম্ভাবনা রয়েছে।
শেষ পর্যন্ত আমাদের ঝুঁকি মিটিয়েছে, আমরা এটিকে কার্যকর করতে সক্ষম হয়েছি এবং অ্যাপটি অনেক আগেই সামগ্রী সরবরাহ করা শুরু করেছে, আমাদের প্রথম অর্থপূর্ণ পেইন্ট সময়কে উল্লেখযোগ্যভাবে উন্নত করেছে।
ফলাফল
এটি আমাদের সাইটে প্রয়োগ করা কর্মক্ষমতা অপ্টিমাইজেশনের একটি দীর্ঘ তালিকা ছিল। চলুন এক নজরে দেখে নেওয়া যাক ফলাফল। অপ্টিমাইজেশনের আগে এবং পরে 3G নেটওয়ার্কে একটি মাঝারি মোবাইল ডিভাইসে আমাদের অ্যাপটি এভাবেই লোড হয়।
লাইটহাউস পারফরম্যান্সের স্কোর 23 থেকে 91 এ উঠে গেছে। গতির দিক থেকে এটি বেশ চমৎকার অগ্রগতি। আমাদের ক্রমাগত চেক করা এবং লাইটহাউস রিপোর্ট অনুসরণ করার মাধ্যমে সমস্ত পরিবর্তন হয়েছে৷ আপনি যদি দেখতে চান যে আমরা কীভাবে প্রযুক্তিগতভাবে সমস্ত উন্নতিগুলিকে বাস্তবায়িত করেছি, তাহলে নির্দ্বিধায় আমাদের রেপো , বিশেষ করে সেখানে অবতরণকারী PR-এ একবার চোখ বুলিয়ে নিন।
ভবিষ্যদ্বাণীমূলক কর্মক্ষমতা - ডেটা-চালিত ব্যবহারকারীর অভিজ্ঞতা
আমরা বিশ্বাস করি যে মেশিন লার্নিং অনেক ক্ষেত্রে ভবিষ্যতের জন্য একটি উত্তেজনাপূর্ণ সুযোগের প্রতিনিধিত্ব করে। একটি ধারণা যা আমরা আশা করি ভবিষ্যতে আরও পরীক্ষা-নিরীক্ষার জন্ম দেবে, তা হল বাস্তব ডেটা আমাদের তৈরি করা ব্যবহারকারীর অভিজ্ঞতাকে সত্যিই গাইড করতে পারে।
আজ, আমরা ব্যবহারকারীর কী চাই বা প্রয়োজন সে সম্পর্কে অনেক নির্বিচারে সিদ্ধান্ত নিই, এবং সেইজন্য প্রিফেচড, বা প্রিলোডেড, বা প্রি-ক্যাশেড হওয়া মূল্যবান। আমরা যদি সঠিক অনুমান করি তবে আমরা অল্প পরিমাণ সংস্থানকে অগ্রাধিকার দিতে সক্ষম, কিন্তু এটি সম্পূর্ণ ওয়েবসাইটে স্কেল করা সত্যিই কঠিন।
আজকে আমাদের অপ্টিমাইজেশানগুলিকে আরও ভালভাবে জানানোর জন্য আমাদের কাছে আসলে ডেটা উপলব্ধ রয়েছে৷ গুগল অ্যানালিটিক্স রিপোর্টিং API ব্যবহার করে আমরা পরবর্তী শীর্ষ পৃষ্ঠাটি দেখতে পারি এবং আমাদের সাইটের যেকোনো URL এর জন্য শতকরা প্রস্থান করতে পারি এবং সেইজন্য আমাদের কোন সংস্থানগুলিকে অগ্রাধিকার দেওয়া উচিত তার উপর সিদ্ধান্ত নিতে পারি।
যদি আমরা এটিকে একটি ভাল সম্ভাব্যতার মডেলের সাথে একত্রিত করি, তাহলে আমরা আক্রমনাত্মকভাবে অতিরিক্ত-প্রিফেচিং সামগ্রীর মাধ্যমে আমাদের ব্যবহারকারীর ডেটা নষ্ট করা এড়াতে পারি। আমরা সেই Google Analytics ডেটার সদ্ব্যবহার করতে পারি এবং এই ধরনের মডেলগুলি বাস্তবায়নের জন্য মেশিন লার্নিং এবং মার্কভ চেইন বা নিউরাল নেটওয়ার্কের মতো মডেলগুলি ব্যবহার করতে পারি।
এই পরীক্ষাগুলিকে সহজতর করার জন্য, আমরা Guess.js নামে একটি নতুন উদ্যোগ ঘোষণা করতে পেরে আনন্দিত।
Guess.js হল ওয়েবের জন্য ডেটা-চালিত ব্যবহারকারীর অভিজ্ঞতার উপর দৃষ্টি নিবদ্ধ করা একটি প্রকল্প। আমরা আশা করি এটি ওয়েব পারফরম্যান্স উন্নত করতে এবং এর বাইরে যেতে ডেটা ব্যবহার করার অন্বেষণকে অনুপ্রাণিত করবে। এটি সবই ওপেন সোর্স এবং আজ GitHub-এ উপলব্ধ৷ এটি মিঙ্কো গেচেভ, গ্যাটসবির কাইল ম্যাথিউস, কেটি হেমপেনিয়াস এবং আরও অনেকের দ্বারা ওপেন সোর্স সম্প্রদায়ের সহযোগিতায় নির্মিত হয়েছিল।
Guess.js দেখুন, আপনি কি মনে করেন তা আমাদের জানান।
সারাংশ
স্কোর এবং মেট্রিক্স ওয়েবের গতির উন্নতিতে সহায়ক, কিন্তু সেগুলি শুধুমাত্র মাধ্যম, লক্ষ্য নয়।
চলতে চলতে আমরা সকলেই ধীরগতির পৃষ্ঠা লোডের অভিজ্ঞতা পেয়েছি, কিন্তু এখন আমাদের ব্যবহারকারীদের আরও আনন্দদায়ক অভিজ্ঞতা দেওয়ার সুযোগ রয়েছে যা সত্যিই দ্রুত লোড হয়।
কর্মক্ষমতা উন্নতি একটি যাত্রা. অনেক ছোট পরিবর্তন বড় লাভ হতে পারে। সঠিক অপ্টিমাইজেশন টুল ব্যবহার করে এবং লাইটহাউস রিপোর্টের উপর নজর রেখে, আপনি আপনার ব্যবহারকারীদের আরও ভাল এবং আরও অন্তর্ভুক্ত অভিজ্ঞতা প্রদান করতে পারেন।
বিশেষ ধন্যবাদ সহ: ওয়ার্ড পিটার্স, মিঙ্কো গেচেভ, কাইল ম্যাথিউস, কেটি হেমপেনিয়াস, ডম ফারোলিনো, ইয়োভ ওয়েইস, সুসি লু, ইউসুকে উতসুনোমিয়া, টম অ্যাঙ্কার্স, লাইটহাউস এবং গুগল ডুডলস৷