Wix কীভাবে তাদের পরিকাঠামোর উন্নয়ন করে ওয়েবসাইটের কর্মক্ষমতা উন্নত করেছে

লক্ষ লক্ষ সাইটের জন্য ওয়েবসাইট লোডিং কর্মক্ষমতা উন্নত করতে Wix-এ প্রবর্তিত কিছু বড় পরিবর্তনের একটি কেস স্টাডি, তাদের জন্য ভাল পেজস্পিড ইনসাইট এবং কোর ওয়েব ভাইটাল স্কোর পাওয়ার পথ পরিষ্কার করে।

Alon Kochba

আমাদের ওয়েবসাইট রানটাইমের একটি বড় পুনর্লিখনের সাথে মিলিত শিল্পের মান, ক্লাউড প্রদানকারী এবং CDN ক্ষমতার সুবিধার জন্য ধন্যবাদ, Wix সাইটের শতাংশের শতাংশ সমস্ত কোর ওয়েব ভাইটাল মেট্রিক্সে ভাল 75 তম পার্সেন্টাইল স্কোর ছুঁয়েছে বছরের পর বছর তিনগুণেরও বেশি , CrUX এবং HTTP আর্কাইভ ।

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

ওভারভিউ

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

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

Wix একটি পরিচালিত পরিবেশ এবং সবকিছু ব্যবহারকারীর হাতে থাকে না। সাধারণ অবকাঠামো ভাগ করে নেওয়া এই সমস্ত সাইটের জন্য অনেক চ্যালেঞ্জ উপস্থাপন করে, তবে বোর্ড জুড়ে বড় বড় উন্নতির সুযোগও উন্মুক্ত করে, যেমন স্কেল অর্থনীতির সুবিধা।

সাধারণ ভাষায় কথা বলা

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

আমরা আমাদের সমস্ত মনিটরিং এবং অভ্যন্তরীণ আলোচনাগুলিকে সামঞ্জস্য করেছি যাতে ওয়েব ভাইটালসের মতো ইন্ডাস্ট্রি স্ট্যান্ডার্ড মেট্রিক্স অন্তর্ভুক্ত থাকে, যার মধ্যে রয়েছে:

সাইট জটিলতা এবং কর্মক্ষমতা স্কোর

একটি সাইট তৈরি করা খুব সহজ যেটি তাত্ক্ষণিকভাবে লোড হয় যতক্ষণ না আপনি এটিকে শুধুমাত্র HTML ব্যবহার করে খুব সহজ করে CDN এর মাধ্যমে পরিবেশন করেন৷

যাইহোক, বাস্তবতা হল যে সাইটগুলি আরও জটিল এবং পরিশীলিত হয়ে উঠছে, নথির পরিবর্তে অ্যাপ্লিকেশনগুলির মতো কাজ করছে এবং ব্লগ, ই-কমার্স সমাধান, কাস্টম কোড ইত্যাদির মতো কার্যকারিতাগুলিকে সমর্থন করছে৷

Wix একটি খুব বড় বৈচিত্র্যের টেমপ্লেট অফার করে, যা এর ব্যবহারকারীদের সহজেই অনেক ব্যবসায়িক ক্ষমতা সহ একটি সাইট তৈরি করতে সক্ষম করে। এই অতিরিক্ত বৈশিষ্ট্যগুলি প্রায়শই কিছু কর্মক্ষমতা খরচের সাথে আসে।

ভ্রমণ

শুরুতে, এইচটিএমএল ছিল

প্রতিবার একটি ওয়েবপৃষ্ঠা লোড করা হয়, এটি সর্বদা একটি URL-এ একটি প্রাথমিক অনুরোধের সাথে শুরু হয় যাতে HTML নথি পুনরুদ্ধার করা যায়। এই HTML প্রতিক্রিয়া আপনার সাইট চালানো এবং রেন্ডার করার জন্য সমস্ত অতিরিক্ত ক্লায়েন্ট অনুরোধ এবং ব্রাউজার লজিক ট্রিগার করে। এটি পৃষ্ঠা লোড করার সবচেয়ে গুরুত্বপূর্ণ অংশ, কারণ প্রতিক্রিয়া শুরু না হওয়া পর্যন্ত কিছুই ঘটে না (টিটিএফবি নামে পরিচিত - প্রথম বাইট থেকে সময়)।

অতীত: ক্লায়েন্ট-সাইড রেন্ডারিং (CSR)

বড় আকারের সিস্টেম পরিচালনা করার সময়, আপনার সর্বদা ট্রেড-অফ থাকে যা আপনাকে বিবেচনা করতে হবে, যেমন কর্মক্ষমতা, নির্ভরযোগ্যতা এবং খরচ। কয়েক বছর আগে পর্যন্ত, Wix ক্লায়েন্ট-সাইড রেন্ডারিং (CSR) ব্যবহার করত, যেখানে প্রকৃত HTML কন্টেন্ট জাভাস্ক্রিপ্টের মাধ্যমে ক্লায়েন্ট সাইডে (অর্থাৎ ব্রাউজারে) তৈরি করা হয়েছিল যা আমাদের বিশাল ব্যাকএন্ড ছাড়াই উচ্চ স্কেল সাইটকে সমর্থন করতে দেয়। অপারেশনাল খরচ।

CSR আমাদের একটি সাধারণ HTML নথি ব্যবহার করতে সক্ষম করেছে, যা মূলত খালি ছিল। এটি যা করেছে তা হল প্রয়োজনীয় কোড এবং ডেটা ডাউনলোডকে ট্রিগার করা যা তখন ক্লায়েন্ট ডিভাইসে সম্পূর্ণ HTML তৈরি করতে ব্যবহৃত হয়েছিল।

আজ: সার্ভার-সাইড রেন্ডারিং (SSR)

কয়েক বছর আগে আমরা সার্ভার-সাইড রেন্ডারিং (SSR) তে স্থানান্তরিত হয়েছিলাম, কারণ এটি SEO এবং কর্মক্ষমতা উভয়ের জন্যই উপকারী ছিল, প্রাথমিক পৃষ্ঠা দৃশ্যমানতার সময় উন্নত করা এবং জাভাস্ক্রিপ্ট চালানোর জন্য সম্পূর্ণ সমর্থন নেই এমন সার্চ ইঞ্জিনগুলির জন্য আরও ভাল সূচীকরণ নিশ্চিত করা।

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

একাধিক স্থানে ক্যাশিং প্রবর্তন করা হচ্ছে

প্রতিটি সাইটের জন্য এইচটিএমএল বেশিরভাগই স্থির ছিল, তবে এতে কয়েকটি সতর্কতা ছিল:

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

প্রাথমিকভাবে, আমরা ভিজিটর ডাটা ছাড়াই এইচটিএমএল ক্যাশে করার তুলনামূলকভাবে নিরাপদ পন্থা নিয়েছিলাম, এবং তারপর প্রতিটি ক্যাশে হিটের জন্য, প্রতিটি দর্শকের জন্য ফ্লাইতে এইচটিএমএল প্রতিক্রিয়ার নির্দিষ্ট অংশগুলিকে পরিবর্তন করেছি।

ইন-হাউস CDN সমাধান

আমরা একটি ইন-হাউস সমাধান স্থাপন করে এটি করেছি: প্রক্সি এবং ক্যাশিংয়ের জন্য বার্নিশ HTTP ক্যাশে ব্যবহার করে, অবৈধ বার্তাগুলির জন্য কাফকা, এবং একটি স্কালা/নেটি-ভিত্তিক পরিষেবা যা এই HTML প্রতিক্রিয়াগুলিকে প্রক্সি করে, কিন্তু এইচটিএমএলকে পরিবর্তন করে এবং দর্শক-নির্দিষ্ট ডেটা যোগ করে এবং ক্যাশে করা প্রতিক্রিয়ার কুকিজ।

এই সমাধানটি আমাদের এই স্লিম উপাদানগুলিকে আরও অনেক ভৌগলিক অবস্থানে এবং একাধিক ক্লাউড প্রদানকারী অঞ্চলে স্থাপন করতে সক্ষম করেছে, যা সারা বিশ্বে ছড়িয়ে আছে। 2019 সালে, আমরা 15টিরও বেশি নতুন অঞ্চল প্রবর্তন করেছি এবং ধীরে ধীরে আমাদের পৃষ্ঠার ভিউগুলির 90% এর জন্য ক্যাশিং সক্ষম করেছি যা ক্যাশে করার জন্য যোগ্য। অতিরিক্ত অবস্থান থেকে সাইট পরিবেশন করা ক্লায়েন্ট এবং সার্ভারের মধ্যে নেটওয়ার্ক লেটেন্সি কমিয়ে দেয়, যা ওয়েবসাইটের দর্শকদের কাছে বিষয়বস্তু নিয়ে আসে।

আমরা একই সমাধান ব্যবহার করে এবং সাইটের বিষয়বস্তুর যেকোনো পরিবর্তনের ক্ষেত্রে ক্যাশে অবৈধ করে নির্দিষ্ট কিছু পঠনযোগ্য API প্রতিক্রিয়াগুলিকে ক্যাশ করা শুরু করেছি। উদাহরণস্বরূপ, একটি পোস্ট প্রকাশিত/পরিবর্তিত হলে সাইটে ব্লগ পোস্টের তালিকা ক্যাশে করা হয় এবং বাতিল করা হয়।

জটিলতা কমানো

ক্যাশিং প্রয়োগ করার ফলে কর্মক্ষমতা উল্লেখযোগ্যভাবে উন্নত হয়েছে, বেশিরভাগই TTFB এবং FCP ধাপে, এবং শেষ ব্যবহারকারীর কাছাকাছি অবস্থান থেকে সামগ্রী পরিবেশন করে আমাদের নির্ভরযোগ্যতা উন্নত করেছে।

যাইহোক, প্রতিটি প্রতিক্রিয়ার জন্য এইচটিএমএল পরিবর্তন করার প্রয়োজনীয়তা একটি অপ্রয়োজনীয় জটিলতা প্রবর্তন করেছে যা, যদি সরানো হয়, আরও কর্মক্ষমতা উন্নতির জন্য একটি সুযোগ উপস্থাপন করে।

ব্রাউজার ক্যাশিং (এবং CDN-এর জন্য প্রস্তুতি)

পরবর্তী পদক্ষেপটি আসলে HTML থেকে সম্পূর্ণরূপে এই ভিজিটর-নির্দিষ্ট ডেটা সরিয়ে ফেলা এবং এইচটিএমএল আসার পরে, এই উদ্দেশ্যে ক্লায়েন্ট দ্বারা ডাকা একটি পৃথক এন্ডপয়েন্ট থেকে এটি পুনরুদ্ধার করা।

আমরা সাবধানে এই ডেটা এবং কুকিগুলিকে একটি নতুন এন্ডপয়েন্টে স্থানান্তরিত করেছি, যা প্রতিটি পৃষ্ঠা লোডে বলা হয়, কিন্তু একটি পাতলা JSON প্রদান করে, যা শুধুমাত্র হাইড্রেশন প্রক্রিয়ার জন্য প্রয়োজন, সম্পূর্ণ পৃষ্ঠার ইন্টারঅ্যাক্টিভিটিতে পৌঁছানোর জন্য৷

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

উপরন্তু, এই পরিবর্তনের অর্থ হল আমাদের HTML আর দর্শক-নির্দিষ্ট নয় এবং এতে কোনো কুকিজ নেই। অন্য কথায়, এটি মূলত যে কোনও জায়গায় ক্যাশে করা যেতে পারে, যা সারা বিশ্বের শত শত জায়গায় অনেক ভাল জিও উপস্থিতি রয়েছে এমন CDN প্রদানকারী ব্যবহার করার দরজা খুলে দেয়।

DNS, SSL এবং HTTP/2

ক্যাশিং সক্ষম হওয়ার সাথে সাথে, অপেক্ষার সময় হ্রাস করা হয়েছিল এবং প্রাথমিক সংযোগের অন্যান্য গুরুত্বপূর্ণ অংশগুলি আরও উল্লেখযোগ্য হয়ে উঠেছে। আমাদের নেটওয়ার্কিং পরিকাঠামো উন্নত করা এবং মনিটরিং আমাদের DNS, সংযোগ এবং SSL সময় উন্নত করতে সক্ষম করেছে।

HTTP/2 সমস্ত ব্যবহারকারী ডোমেনের জন্য সক্ষম করা হয়েছিল, প্রতিটি নতুন সংযোগের সাথে প্রয়োজনীয় সংযোগের পরিমাণ এবং ওভারহেড উভয়ই হ্রাস করে। HTTP/2 এর সাথে আসা কর্মক্ষমতা এবং স্থিতিস্থাপকতার সুবিধার সুবিধা নেওয়ার সময় এটি স্থাপন করা একটি অপেক্ষাকৃত সহজ পরিবর্তন ছিল।

ব্রটলি কম্প্রেশন (বনাম জিজিপ)

ঐতিহ্যগতভাবে, আমাদের সমস্ত ফাইল gzip কম্প্রেশন ব্যবহার করে সংকুচিত করা হয়েছিল, যা ওয়েবে সবচেয়ে প্রচলিত HTML কম্প্রেশন বিকল্প। এই কম্প্রেশন প্রোটোকল প্রাথমিকভাবে প্রায় 30 বছর আগে বাস্তবায়িত হয়েছিল!

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

আমরা প্রান্তে আমাদের nginx প্রক্সিগুলিতে Brotli সমর্থন সক্ষম করেছি, যে সমস্ত ক্লায়েন্ট এটি সমর্থন করে তাদের জন্য।

ব্রোটলি কম্প্রেশন ব্যবহার করার জন্য সরানো আমাদের মিডিয়ান ফাইল স্থানান্তরের আকার 21% থেকে 25% কমিয়েছে যার ফলে ব্যান্ডউইথের ব্যবহার কমে গেছে এবং লোডিং সময় উন্নত হয়েছে।

বিষয়বস্তু বিতরণ নেটওয়ার্ক (CDN)

ডায়নামিক CDN নির্বাচন

Wix-এ, আমরা সবসময় ব্যবহারকারীর ওয়েবসাইটগুলিতে সমস্ত জাভাস্ক্রিপ্ট কোড এবং ছবি পরিবেশন করার জন্য CDN ব্যবহার করেছি।

সম্প্রতি, আমরা ক্লায়েন্টের নেটওয়ার্ক এবং উৎপত্তি অনুসারে সেরা পারফরম্যান্সকারী CDN স্বয়ংক্রিয়ভাবে নির্বাচন করতে আমাদের DNS প্রদানকারীর একটি সমাধানের সাথে একত্রিত করেছি। এটি আমাদের প্রতিটি দর্শকের জন্য সর্বোত্তম অবস্থান থেকে স্ট্যাটিক ফাইল পরিবেশন করতে এবং একটি নির্দিষ্ট CDN-এ প্রাপ্যতার সমস্যাগুলি এড়াতে সক্ষম করে।

শীঘ্রই আসছে... ব্যবহারকারী ডোমেনগুলি CDN দ্বারা পরিবেশিত৷

ধাঁধার চূড়ান্ত অংশটি একটি CDN এর মাধ্যমে শেষ, এবং সবচেয়ে গুরুত্বপূর্ণ অংশটি পরিবেশন করছে: ব্যবহারকারীর ডোমেন থেকে HTML।

উপরে বর্ণিত হিসাবে, আমরা সাইট-নির্দিষ্ট HTML এবং API ফলাফলগুলি ক্যাশে এবং পরিবেশন করার জন্য আমাদের নিজস্ব ইন-হাউস সমাধান তৈরি করেছি। অনেক নতুন অঞ্চলে এই সমাধানটি রক্ষণাবেক্ষণ করার জন্য এর অপারেশনাল খরচও রয়েছে এবং নতুন অবস্থান যোগ করা একটি প্রক্রিয়া হয়ে ওঠে যা আমাদের পরিচালনা এবং ক্রমাগত অপ্টিমাইজ করতে হবে।

আমরা বর্তমানে বিভিন্ন CDN প্রদানকারীর সাথে একীভূত করছি যাতে সারা বিশ্বে আমাদের সার্ভারের বিতরণকে উন্নত করতে এবং এইভাবে প্রতিক্রিয়ার সময় আরও উন্নত করতে সরাসরি CDN অবস্থান থেকে সম্পূর্ণ Wix সাইট পরিবেশন করতে সহায়তা করে। আমরা যে বিপুল পরিমাণ ডোমেন পরিবেশন করি তার কারণে এটি একটি চ্যালেঞ্জ, যার প্রান্তে SSL সমাপ্তির প্রয়োজন।

CDN-এর সাথে একীভূত করা Wix ওয়েবসাইটগুলিকে গ্রাহকের আগের চেয়ে আরও কাছাকাছি নিয়ে আসে এবং আমাদের পক্ষ থেকে অতিরিক্ত প্রচেষ্টা ছাড়াই HTTP/3-এর মতো নতুন প্রযুক্তি সহ লোডিং অভিজ্ঞতার আরও উন্নতির সাথে আসে।

কর্মক্ষমতা নিরীক্ষণ উপর কিছু শব্দ

আপনি যদি একটি Wix সাইট চালান, তাহলে আপনি সম্ভবত ভাবছেন যে এটি কীভাবে আপনার Wix সাইটের পারফরম্যান্স ফলাফলে অনুবাদ করে এবং আমরা কীভাবে অন্যান্য ওয়েবসাইট প্ল্যাটফর্মের সাথে তুলনা করি।

উপরে করা বেশিরভাগ কাজ গত বছরে স্থাপন করা হয়েছে, এবং কিছু এখনও রোল আউট করা হচ্ছে।

HTTPArchive-এর Web Almanac সম্প্রতি 2020 সংস্করণ প্রকাশ করেছে যাতে CMS ব্যবহারকারীর অভিজ্ঞতার উপর একটি চমৎকার অধ্যায় রয়েছে। মনে রাখবেন যে এই নিবন্ধে বর্ণিত অনেক সংখ্যা 2020 এর মাঝামাঝি।

আমরা 2021 সালে আপডেট করা রিপোর্ট দেখার জন্য উন্মুখ, এবং সক্রিয়ভাবে আমাদের সাইটের পাশাপাশি আমাদের অভ্যন্তরীণ পারফরম্যান্স মেট্রিকগুলির জন্য CrUX রিপোর্টগুলি পর্যবেক্ষণ করছি৷

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

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

উপসংহার

আমরা আশা করি আমাদের অভিজ্ঞতা আপনাকে আপনার প্রতিষ্ঠানে পারফরম্যান্স-ভিত্তিক সংস্কৃতি গ্রহণ করতে অনুপ্রাণিত করবে এবং উপরের বিবরণগুলি আপনার প্ল্যাটফর্ম বা সাইটের জন্য সহায়ক এবং প্রযোজ্য।

সংক্ষেপে:

• মেট্রিক্সের একটি সেট বেছে নিন যা আপনি ইন্ডাস্ট্রি দ্বারা অনুমোদিত টুল ব্যবহার করে ধারাবাহিকভাবে ট্র্যাক করতে পারেন। আমরা Core Web Vitals সুপারিশ করি।
• লিভারেজ ব্রাউজার ক্যাশিং এবং CDNs.
• HTTP/2 (বা সম্ভব হলে HTTP/3) এ স্থানান্তর করুন।
• ব্রটলি কম্প্রেশন ব্যবহার করুন।

আমাদের গল্প শেখার জন্য ধন্যবাদ এবং আমরা আপনাকে প্রশ্ন জিজ্ঞাসা করতে, Twitter এবং GitHub- এ ধারনা শেয়ার করতে এবং আপনার প্রিয় চ্যানেলগুলিতে ওয়েব পারফরম্যান্স কথোপকথনে যোগ দিতে আমন্ত্রণ জানাই।

তাহলে, আপনার সাম্প্রতিক Wix সাইটের কর্মক্ষমতা কেমন দেখাচ্ছে?