অত্যধিক অলস লোডিং কর্মক্ষমতা প্রভাব

কোর ওয়েব ভাইটালগুলিকে মাথায় রেখে অলস লোডিং চিত্রগুলির জন্য ডেটা-চালিত পরামর্শ৷

ফেলিক্স আর্ন্টজ
রিক ভিসকোমি

অলস লোডিং এমন একটি কৌশল যা ডেটা সংরক্ষণ করতে এবং গুরুত্বপূর্ণ সম্পদের জন্য নেটওয়ার্ক বিরোধ কমাতে প্রয়োজন না হওয়া পর্যন্ত কোনও সংস্থান ডাউনলোড করা পিছিয়ে দেয়। এটি 2019 সালে একটি ওয়েব স্ট্যান্ডার্ড হয়ে ওঠে এবং আজকে ছবির জন্য loading="lazy" বেশিরভাগ প্রধান ব্রাউজার দ্বারা সমর্থিত ।

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

দত্তক

এইচটিটিপি আর্কাইভের সাম্প্রতিকতম তথ্য অনুসারে, বিল্ট-ইন ইমেজ অলস লোডিং 29% ওয়েবসাইট দ্বারা ব্যবহৃত হয় এবং গ্রহণ দ্রুত বৃদ্ধি পাচ্ছে।

পাই চার্ট দেখায় যে ওয়ার্ডপ্রেস অলস লোডিং গ্রহণের 84.1%, অন্যান্য CMS 2.3% এবং নন-CMS 13.5%।
বিল্ট-ইন ইমেজ অলস লোডিং ব্যবহার করে এমন ওয়েবসাইটগুলির ধরনের ব্রেকডাউন। ( উৎস )

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

পূর্ববর্তী চার্টের অনুরূপ অনুপাত সহ অন্যান্য CMS এবং নন-CMS-এর তুলনায় ওয়ার্ডপ্রেস প্রধান প্লেয়ার হিসাবে অলস লোডিং গ্রহণের টাইমসিরিজ চার্ট। জুলাই 2020 থেকে জুন 2021 পর্যন্ত মোট দত্তক গ্রহণ দ্রুত 1% থেকে 17% বেড়েছে বলে দেখানো হয়েছে।
বিল্ট-ইন ইমেজ অলস লোডিং ব্যবহার করে এমন ওয়েবসাইটগুলির ধরনের ব্রেকডাউন। ( উৎস )

দত্তক নেওয়ার হারও লক্ষণীয়। জুলাই 2020 সালে, ওয়ার্ডপ্রেস সাইটগুলি যেগুলি অলস লোডিং ব্যবহার করে প্রায় 6 মিলিয়ন (মোট 1%) এর মধ্যে কয়েক হাজার ওয়েবসাইট তৈরি করেছে। 2021 সালের শুরুতে, শুধুমাত্র ওয়ার্ডপ্রেসেই অলস লোডিং গ্রহণ 1 মিলিয়নেরও বেশি ওয়েবসাইটে (মোট 14%) হয়ে গেছে।

পারস্পরিক পারফরম্যান্স

এইচটিটিপি আর্কাইভের আরও গভীরে খনন করে , আমরা বিল্ট-ইন ইমেজ অলস লোডিং সহ এবং ব্যতীত পৃষ্ঠাগুলি কীভাবে সবচেয়ে বড় কন্টেন্টফুল পেইন্ট (LCP) মেট্রিকের সাথে কাজ করে তা তুলনা করতে পারি। LCP ডেটা ল্যাবে কৃত্রিম পরীক্ষার বিপরীতে Chrome ব্যবহারকারীর অভিজ্ঞতা রিপোর্ট (CrUX) থেকে বাস্তব-ব্যবহারকারীর অভিজ্ঞতা থেকে আসে। নিম্নলিখিত চার্টটি প্রতিটি পৃষ্ঠার 75 তম পার্সেন্টাইল এলসিপির ডিস্ট্রিবিউশনগুলি কল্পনা করার জন্য একটি বাক্স-এবং-হুইকার প্লট ব্যবহার করে: লাইনগুলি 10 তম এবং 90 তম পার্সেন্টাইল এবং বাক্সগুলি 25 তম এবং 75 তম পার্সেন্টাইল প্রতিনিধিত্ব করে৷

বাক্স এবং হুইস্কার চার্ট 10, 25, 75 এবং 90 তম পার্সেন্টাইল দেখায় এমন পৃষ্ঠাগুলির জন্য যা বিল্ট-ইন ইমেজ অলস লোডিং করে এবং ব্যবহার করে না। যে পৃষ্ঠাগুলি এটি ব্যবহার করে না তাদের LCP বিতরণ যেগুলি করে তাদের তুলনায় দ্রুত।
সমস্ত পৃষ্ঠার 75 তম পার্সেন্টাইল LCP অভিজ্ঞতার বিতরণ, তারা বিল্ট-ইন ইমেজ অলস লোডিং ব্যবহার করে কিনা তা দ্বারা বিভক্ত। ( উৎস )

অলস লোডিংবিহীন মধ্যমা পৃষ্ঠাটির 75তম পার্সেন্টাইল LCP 2,922 ms আছে, যেখানে অলস লোডিং সহ মধ্যম পৃষ্ঠাটির জন্য 3,546 ms এর তুলনায়। সামগ্রিকভাবে, যে ওয়েবসাইটগুলি অলস লোডিং ব্যবহার করে সেগুলির LCP কার্যক্ষমতা আরও খারাপ হয়৷

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

বক্স এবং হুইকার চার্ট ওয়ার্ডপ্রেস পৃষ্ঠাগুলির জন্য 10, 25, 75 এবং 90 তম পার্সেন্টাইল দেখাচ্ছে যা বিল্ট-ইন ইমেজ অলস লোডিং করে এবং ব্যবহার করে না। আগের চার্টের মতো, যে পৃষ্ঠাগুলি এটি ব্যবহার করে না তাদের LCP বিতরণ যেগুলি করে তাদের তুলনায় দ্রুত।
ওয়ার্ডপ্রেস পৃষ্ঠাগুলির 75 তম পার্সেন্টাইল LCP অভিজ্ঞতার বিতরণ, তারা বিল্ট-ইন ইমেজ অলস লোডিং ব্যবহার করে কিনা তা দ্বারা বিভক্ত। ( উৎস )

দুর্ভাগ্যবশত, একই প্যাটার্ন শুধুমাত্র ওয়ার্ডপ্রেস পেজ থেকে উদ্ভূত হয়; যারা অলস লোডিং ব্যবহার করে তাদের LCP কর্মক্ষমতা কম থাকে। অলস লোডিং ছাড়া মিডিয়ান ওয়ার্ডপ্রেস পৃষ্ঠাটির 75তম পার্সেন্টাইল LCP 3,495 ms, যেখানে অলস লোডিং সহ মিডিয়ান পৃষ্ঠার জন্য 3,768 ms এর তুলনায়।

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

কার্যকারণ কর্মক্ষমতা

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

সিরিজ ডিফল্ট অক্ষম ডিফল্ট থেকে পার্থক্য
twentyone-archive-desktop 2,029 1,759 -13%
বাইশ-আর্কাইভ-মোবাইল 1,657 1,403 -15%
কুড়ি-একক-ডেস্কটপ 1,655 1,726 4%
কুড়ি-একক-মোবাইল 1,352 1,384 2%
 নমুনা ওয়ার্ডপ্রেস পৃষ্ঠাগুলিতে অন্তর্নির্মিত চিত্র অলস লোডিং অক্ষম করে LCP (ms) এ পরিবর্তন করুন৷

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

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

সিরিজ ডিফল্ট অক্ষম ডিফল্ট থেকে পার্থক্য
twentyone-archive-desktop 577 1173 103%
বাইশ-আর্কাইভ-মোবাইল 172 378 120%
কুড়ি-একক-ডেস্কটপ 301 850 183%
কুড়ি-একক-মোবাইল 114 378 233%
 নমুনা ওয়ার্ডপ্রেস পৃষ্ঠাগুলিতে অন্তর্নির্মিত চিত্র অলস লোডিং অক্ষম করে ইমেজ বাইটের সংখ্যা (কেবি) পরিবর্তন করুন।

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

A/B পরীক্ষার ফলাফল সংক্ষিপ্ত করার জন্য, WordPress দ্বারা ব্যবহৃত অলস লোডিং কৌশলটি খুব স্পষ্টভাবে বিলম্বিত LCP-এর খরচে ইমেজ বাইট কমাতে সাহায্য করে।

একটি সম্ভাব্য সংশোধন

এই পরীক্ষার জন্য ওয়ার্ডপ্রেসের বর্তমান অলস-লোডিং বাস্তবায়নের সবচেয়ে গুরুত্বপূর্ণ দিক হল এটি ভিউপোর্টের মধ্যে (_ভাঁজের উপরে) ছবিগুলিকে অলস-লোড করে। CMS ব্লগ পোস্ট এটিকে এড়ানোর জন্য একটি প্যাটার্ন হিসাবে স্বীকার করে , কিন্তু সেই সময়ে পরীক্ষামূলক ডেটা ইঙ্গিত দেয় যে LCP এর প্রভাব ন্যূনতম এবং ওয়ার্ডপ্রেস কোরে বাস্তবায়নকে সহজ করার জন্য মূল্যবান।

এই নতুন ডেটা দেওয়া, আমরা একটি পরীক্ষামূলক সমাধান তৈরি করেছি যা ভাঁজের উপরে অলস লোডিং চিত্রগুলি এড়ায় এবং প্রথম A/B পরীক্ষার মতো একই পরিস্থিতিতে এটি পরীক্ষা করেছিলাম৷

সিরিজ ডিফল্ট অক্ষম ঠিক করা ডিফল্ট থেকে পার্থক্য প্রতিবন্ধীদের থেকে পার্থক্য
twentyone-archive-desktop 2,029 1,759 1,749 -14% -1%
বাইশ-আর্কাইভ-মোবাইল 1,657 1,403 1,352 -18% -4%
কুড়ি-একক-ডেস্কটপ 1,655 1,726 1,676 1% -3%
কুড়ি-একক-মোবাইল 1,352 1,384 1,342 -1% -3%
 নমুনা ওয়ার্ডপ্রেস পৃষ্ঠাগুলিতে অন্তর্নির্মিত চিত্র অলস লোড করার প্রস্তাবিত সংশোধন দ্বারা LCP (ms) এ পরিবর্তন।

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

সিরিজ ডিফল্ট অক্ষম ঠিক করা ডিফল্ট থেকে পার্থক্য প্রতিবন্ধীদের থেকে পার্থক্য
twentyone-archive-desktop 577 1173 577 0% -51%
বাইশ-আর্কাইভ-মোবাইল 172 378 172 0% -54%
কুড়ি-একক-ডেস্কটপ 301 850 301 0% -65%
কুড়ি-একক-মোবাইল 114 378 114 0% -70%
 নমুনা ওয়ার্ডপ্রেস পৃষ্ঠাগুলিতে অন্তর্নির্মিত ইমেজ অলস লোডের জন্য প্রস্তাবিত ফিক্স দ্বারা ইমেজ বাইটের সংখ্যা (কেবি) পরিবর্তন করুন।

ইমেজ বাইটের পরিপ্রেক্ষিতে, ফিক্সটি ডিফল্ট আচরণকে প্রভাবিত করে না। এটি দুর্দান্ত, কারণ এটি ছিল ডিফল্ট পদ্ধতির অন্যতম শক্তি।

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

বাস্তবায়ন (:#বাস্তবায়ন)

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

যেহেতু এই সর্বোত্তম অনুশীলনগুলি সমস্ত ওয়েব বিকাশকারীদের জন্য প্রযোজ্য, এটি লাইটহাউসের মতো সরঞ্জামগুলিতে অলস লোডিং অত্যধিক ব্যবহারকে ফ্ল্যাগ করাও মূল্যবান হতে পারে৷ সেই অডিটের অগ্রগতি অনুসরণ করতে, GitHub-এ বৈশিষ্ট্যের অনুরোধটি পড়ুন। ততক্ষণ পর্যন্ত, LCP উপাদানগুলি অলসভাবে লোড হওয়ার উদাহরণ খুঁজে পেতে বিকাশকারীরা একটি জিনিস করতে পারেন তা হল তাদের ফিল্ড ডেটাতে আরও বিস্তারিত লগিং যুক্ত করা।

নিম্নলিখিত কোডটি সাম্প্রতিকতম এলসিপি উপাদানটির মূল্যায়ন করে এবং এটি অলসভাবে লোড হলে একটি সতর্কতা লগ করে৷

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

এটি অলস লোডিং কৌশলের একটি তীক্ষ্ণ প্রান্ত এবং প্ল্যাটফর্ম স্তরে API উন্নতির সম্ভাবনাকেও হাইলাইট করে। উদাহরণস্বরূপ, loading অ্যাট্রিবিউট থাকা সত্ত্বেও, প্রথম কয়েকটি ছবি সাগ্রহে লোড করার সাথে পরীক্ষা করার জন্য Chromium-এ একটি উন্মুক্ত সমস্যা রয়েছে, ঠিক করার মতো।

উপসংহার

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

আনস্প্ল্যাশে ফ্রাঙ্কি লোপেজের ছবি