Preload, prefetch এবং preconnect: কোনটি কখন সত্যিই সাহায্য করে
Resource hints তখনই কাজে লাগে, যখন সেগুলো ব্রাউজারের বাস্তব bottleneck-এর সঙ্গে মেলে। অন্ধভাবে ব্যবহার করলে এগুলো priority noise যোগ করে এবং কখনও কখনও পেজকে আরও ধীর করে।
সুচিপত্র
- Resource hints কোনো জাদু নয়
- ব্রাউজার ইতিমধ্যেই যা ভালোভাবে করে
- Preload: বর্তমান পেজের দেরিতে আবিষ্কৃত resource-এর জন্য
- Preload এবং LCP images
- Prefetch: next page-এর জন্য, এই পেজের জন্য নয়
- Preconnect: গুরুত্বপূর্ণ origin-এ expensive connection-এর জন্য
- DNS-prefetch: হালকা আত্মীয়
- কীভাবে সিদ্ধান্ত নেবেন: একটি ব্যবহারিক workflow
- 1. Bottleneck শনাক্ত করুন
- 2. একবারে একটি hint যোগ করুন
- 3. Priority side effect পরীক্ষা করুন
- 4. Headers এবং caching যাচাই করুন
- সাধারণ ভুল
- অতিরিক্ত preload করা
- Required resource-এর জন্য prefetch ব্যবহার করা
- প্রতিটি third party-তে preconnect করা
- Mobile condition ভুলে যাওয়া
- একটি সহজ decision table
- শান্ত rule
Resource hints কোনো জাদু নয়
preload, prefetch, এবং preconnect-কে প্রায়ই performance checklist হিসেবে দেখা হয়। <head>-এ কয়েকটি tag যোগ করুন, Lighthouse আবার চালান, আর একটু স্বস্তি নিন। এগুলো এভাবে কাজ করে না।
এই hints ব্রাউজারের loading pipeline-এর জন্য নির্দেশনা। আপনি যখন এমন কিছু জানেন যা ব্রাউজার যথেষ্ট তাড়াতাড়ি আবিষ্কার করতে পারে না, তখন এগুলো সাহায্য করতে পারে। আর আপনি যখন অনুমান করেন, non-critical কাজকে অতিরিক্ত priority দেন, বা এমন connection আগে থেকে প্রস্তুত করেন যা ব্যবহারকারীর কখনও লাগে না, তখন এগুলো ক্ষতি করতে পারে।
সংক্ষিপ্ত সংস্করণ:
- বর্তমান পেজের জন্য প্রয়োজনীয়, কিন্তু খুব দেরিতে আবিষ্কৃত resource-এর জন্য
preloadব্যবহার করুন। - সম্ভাব্য ভবিষ্যৎ navigation resource-এর জন্য
prefetchব্যবহার করুন, বর্তমান পেজের অপরিহার্য জিনিসের জন্য নয়। - গুরুত্বপূর্ণ third-party origin-এর জন্য
preconnectব্যবহার করুন, যেখানে connection setup সত্যিকারের delay তৈরি করে।
ব্যবহারিক প্রশ্নটি “কোন hint সবচেয়ে দ্রুত?” নয়। বরং প্রশ্নটি হলো “ব্রাউজার কীসের জন্য অপেক্ষা করছে, এবং এই hint কি সেই অপেক্ষা দূর করতে পারে?”
ব্রাউজার ইতিমধ্যেই যা ভালোভাবে করে
আধুনিক ব্রাউজার নিষ্ক্রিয় file downloader নয়। তারা HTML parse করে, resource-এর জন্য আগে থেকে scan করে, priority নির্ধারণ করে, connection reuse করে, দৃশ্যমান নয় এমন কাজ delay করে, এবং network condition-এর সঙ্গে মানিয়ে নেয়।
এর মানে resource hints বেছে বেছে ব্যবহার করা উচিত। কোনো stylesheet, script, image, বা font যদি ইতিমধ্যেই তাড়াতাড়ি আবিষ্কৃত হয় এবং সঠিক priority পায়, hint যোগ করলে কিছুই নাও হতে পারে। আরও খারাপ হলো, এটি বেশি গুরুত্বপূর্ণ resource-এর সঙ্গে প্রতিযোগিতা করতে পারে।
Hints যোগ করার আগে DevTools-এ waterfall trace বা lab report দেখুন। আপনি যদি Lighthouse ব্যবহার করেন, score-এর বদলে diagnostics দিয়ে শুরু করুন; panic না করে Lighthouse report পড়ার বিষয়ে আমাদের আলাদা guide আছে — তবে মনে রাখবেন সঠিক URL case-sensitive, তাই প্রয়োজনে আপনার site navigation থেকে linked article ব্যবহার করুন।
বাস্তব evidence সাধারণত তিন জায়গায় দেখা যায়:
- কোনো critical resource দেরিতে শুরু হয়, কারণ ব্রাউজার সেটি দেরিতে আবিষ্কার করে।
- কোনো গুরুত্বপূর্ণ origin-এ connection প্রথম request-এর আগে চোখে পড়ার মতো সময় নেয়।
- next-page resource অত্যন্ত predictable এবং idle time-এ fetch করা সস্তা।
এগুলোর কোনোটিই সত্য না হলে, hint সম্ভবত কেবল সাজসজ্জা।
Preload: বর্তমান পেজের দেরিতে আবিষ্কৃত resource-এর জন্য
preload ব্রাউজারকে বলে: “এই resource এখনই fetch করুন, কারণ বর্তমান পেজের এটি লাগবে।”
একটি সাধারণ উদাহরণ হলো CSS-এর ভেতরে referenced একটি web font। ব্রাউজারকে HTML download করতে হয়, CSS আবিষ্কার করতে হয়, CSS download করতে হয়, সেটি parse করতে হয়, font আবিষ্কার করতে হয়, তারপর font request করতে হয়। যদি সেই font above-the-fold text-এর জন্য গুরুত্বপূর্ণ হয়, discovery এতটাই দেরি হতে পারে যে layout shift বা delayed text rendering ঘটতে পারে।
একটি preload সেই request আগে এনে দিতে পারে:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>as attribute গুরুত্বপূর্ণ। এটি ব্রাউজারকে বলে resource-টি কী ধরনের, যা priority, caching, content security policy, এবং request header-কে প্রভাবিত করে। Fonts সাধারণত crossorigin-ও প্রয়োজন করে, একই site থেকে serve করা হলেও, কারণ font fetching CORS mode ব্যবহার করে।
ভালো preload candidate-এর মধ্যে আছে:
- দৃশ্যমান text-এর জন্য ব্যবহৃত primary web font।
- এমন hero image যা Largest Contentful Paint element এবং তাড়াতাড়ি discoverable নয়।
- পরোক্ষভাবে loaded critical CSS file।
- খুব তাড়াতাড়ি প্রয়োজনীয় module বা script, কিন্তু অন্য script-এর আড়ালে লুকানো।
খারাপ preload candidate-এর মধ্যে আছে:
- design system-এর প্রতিটি font weight।
- fold-এর নিচের image।
- initial rendering-এর জন্য প্রয়োজন নেই এমন script।
- ব্রাউজার first HTML chunk-এই ইতিমধ্যে আবিষ্কার করে এমন resource।
Preload শক্তিশালী, কারণ এটি current-page priority-কে প্রভাবিত করে। সেই কারণেই এর অপব্যবহারও সহজ। আপনি যদি পাঁচটি বড় asset preload করেন, আপনি আর ব্রাউজারকে সাহায্য করছেন না। আপনি তার সঙ্গে তর্ক করছেন।
Fonts হলো classic case। একটি primary font file preload করলে সাহায্য করতে পারে। ছয়টি weight এবং italic preload করলে সাধারণত অবস্থা খারাপ হয়। Fonts যদি আপনার bottleneck হয়, আগে font set ঠিক করুন; কেন web fonts are still the easiest performance win on most sites সে বিষয়ে আমাদের guide এই cleanup আরও বিস্তারিতভাবে আলোচনা করে।
Preload এবং LCP images
LCP image preload করা উপকারী হতে পারে, যখন image initial HTML-এ visible নয়। সাধারণ কারণের মধ্যে আছে CSS background images, client-rendered components, বা responsive image logic যা দেরিতে আসে।
কিন্তু আপনার hero image যদি ইতিমধ্যেই HTML-এ sensible srcset, sizes, dimensions, এবং lazy loading ছাড়া একটি <img> হিসেবে থাকে, ব্রাউজার সম্ভবত সেটি দ্রুত খুঁজে পাবে। সে ক্ষেত্রে page-এর ওপর নির্ভর করে preload-এর চেয়ে fetchpriority='high' যোগ করা বেশি উপযুক্ত হতে পারে।
একটি ভালো test: waterfall-এ image request যদি দেরিতে শুরু হয় এবং সেটিই LCP element হয়, preload বিবেচনা করুন। যদি এটি তাড়াতাড়ি শুরু হয় কিন্তু ধীরে download হয়, সমস্যা হলো size, format, CDN behavior, বা server latency — discovery নয়। Image format সিদ্ধান্তের জন্য দেখুন when AVIF beats WebP and when it does not।
Prefetch: next page-এর জন্য, এই পেজের জন্য নয়
prefetch ব্রাউজারকে বলে: “এই resource শিগগিরই লাগতে পারে, কিন্তু এখনই প্রয়োজন নয়।”
এই পার্থক্যটি গুরুত্বপূর্ণ। Prefetch ইচ্ছাকৃতভাবে low priority। ব্রাউজার idle time-এ এটি fetch করে পরে ব্যবহারের জন্য store করতে পারে। আবার poor connection, data-saving mode, বা memory pressure থাকলে এটি skip-ও করতে পারে।
User intent যথেষ্ট শক্তিশালী হলে, যাতে next resource সম্ভবত লাগবে, তখন prefetch ব্যবহার করুন।
ভালো prefetch candidate-এর মধ্যে আছে:
- multi-page checkout-এর next step।
- user query টাইপ করা শুরু করার পর search results, যদি next route predictable হয়।
- user nearby content সক্রিয়ভাবে পড়ছে এমন সময় table of contents থেকে linked documentation pages।
- user navigation item hover বা focus করার পর single-page app-এর route chunks।
খারাপ prefetch candidate-এর মধ্যে আছে:
- আপনার পুরো navigation tree।
- বড় video বা image gallery।
- “just in case” third-party scripts।
- ব্যবহারকারীরা খুব কমই পরবর্তীতে visit করে এমন pages।
Prefetch-এ সংযম লাভজনক। কোনো resource fetch হয়ে কখনও ব্যবহৃত না হলে সেটি free নয়। এটি bandwidth, server capacity, energy, এবং সম্ভবত user data consume করে। Mobile network-এ speculative fetching সক্রিয়ভাবে user-unfriendly হতে পারে।
অনেক site-এর জন্য সেরা prefetch strategy হলো intent-based। Home page load হওয়ার সঙ্গে সঙ্গে pricing page prefetch করবেন না। User pricing menu খুললে, pricing link hover করলে, বা এমন call-to-action-এর কাছে scroll করলে যা navigation শক্তভাবে predict করে, তখন সেটি prefetch করুন।
এটিও মনে রাখুন যে browser behavior ভিন্ন হয়। কিছু browser prefetch নিয়ে conservative; কিছু privacy setting speculative loading কমায় বা disable করে। Prefetch-কে opportunistic improvement হিসেবে ধরুন, correctness mechanism হিসেবে নয়।
Preconnect: গুরুত্বপূর্ণ origin-এ expensive connection-এর জন্য
preconnect ব্রাউজারকে বলে: “এই origin-এ connection setup এখনই শুরু করুন।”
এর মধ্যে DNS lookup, TCP connection, এবং TLS negotiation থাকতে পারে। Third-party origin-এর ক্ষেত্রে এই setup শত শত millisecond নিতে পারে, বিশেষ করে high-latency network-এ। Page-এর যদি শিগগিরই সেই origin থেকে critical request দরকার হয়, preconnect পরবর্তী request দ্রুত করতে পারে।
Example:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>ভালো preconnect candidate-এর মধ্যে আছে:
- render-blocking text-এর জন্য ব্যবহৃত font origin।
- initial interaction-এর সময় প্রয়োজনীয় critical API origin।
- above-the-fold asset serve করা CDN origin।
- user action-এর ঠিক পরেই দরকার এমন payments বা identity provider।
খারাপ preconnect candidate-এর মধ্যে আছে:
- user-critical নয় এমন analytics এবং advertising endpoint।
- কেবল কিছু session-এ ব্যবহৃত origin।
- third party-এর দীর্ঘ list।
- same-origin resources, যেখানে ব্রাউজারের ইতিমধ্যেই connection আছে বা শিগগিরই খুলবে।
Preconnect-এর holding cost আছে। Open socket memory এবং network resource consume করে। Browsers unused connection বন্ধ করে দেবে, কিন্তু তাতে unnecessary preconnect harmless হয়ে যায় না।
একটি কার্যকর rule: একটি page-এ সর্বোচ্চ এক বা দুটি high-confidence third-party origin-এ preconnect করুন। যদি আরও যোগ করার প্রলোভন হয়, আপনার third-party architecture-ই সম্ভবত review দরকার, hints বাড়ানো নয়।
DNS-prefetch: হালকা আত্মীয়
আপনি dns-prefetch-ও দেখতে পারেন:
<link rel='dns-prefetch' href='https://example-cdn.com'>এটি শুধু domain name resolve করে। এটি TCP বা TLS connection খোলে না। এটি preconnect-এর চেয়ে সস্তা, কিন্তু কম সহায়কও।
Lower-confidence third-party origin-এর জন্য DNS-prefetch যুক্তিযুক্ত হতে পারে, যেখানে full preconnect খুব aggressive মনে হয়। বাস্তবে, কোনো origin critical এবং নিশ্চিতভাবে শিগগিরই ব্যবহৃত হলে preconnect পছন্দ করুন। যদি কেবল সম্ভাবনা থাকে, DNS-prefetch ব্যবহার করুন অথবা কিছুই করবেন না।
কীভাবে সিদ্ধান্ত নেবেন: একটি ব্যবহারিক workflow
Tags দিয়ে নয়, measurement দিয়ে শুরু করুন।
1. Bottleneck শনাক্ত করুন
একটি performance trace খুলুন এবং late discovery খুঁজুন। Font, hero image, বা script request কি অন্য file download ও parse হওয়ার পরেই শুরু হয়েছে? সেটি preload candidate।
Third-party origin-এ দীর্ঘ DNS/TCP/TLS setup-এর পরেই যদি request শুরু হয়, সেটি preconnect candidate।
বর্তমান page ঠিক থাকলেও next navigation যদি predictably slow হয়, prefetch সাহায্য করতে পারে।
2. একবারে একটি hint যোগ করুন
Resource hints একে অন্যের সঙ্গে interact করে। একটি যোগ করুন, test করুন, এবং waterfall উন্নত হলে ও user-facing metrics regress না করলে তবেই রাখুন।
Preload-এর ক্ষেত্রে hinted resource সত্যিই শিগগির ব্যবহৃত হচ্ছে কি না দেখুন। Load-এর কিছুক্ষণ পর preloaded resource ব্যবহৃত না হলে Chrome warning দিতে পারে। সেই warning গুরুত্বসহকারে নিন।
3. Priority side effect পরীক্ষা করুন
Preload CSS, JavaScript, বা আরও গুরুত্বপূর্ণ image থেকে bandwidth টেনে নিতে পারে। Preconnect একটি connection slot দখল করতে পারে। Prefetch background traffic যোগ করতে পারে।
সঠিক ফলাফল “hinted file আগে শুরু হয়েছে” নয়। সঠিক ফলাফল হলো “page ব্যবহারকারীর জন্য অর্থপূর্ণভাবে ভালো হয়েছে।” সম্ভব হলে LCP, INP, CLS, এবং real-user monitoring দেখুন।
4. Headers এবং caching যাচাই করুন
Hints HTML বা HTTP Link headers-এ পাঠানো যেতে পারে। Server যদি আগেভাগে জানে page-এর কী লাগবে, headers উপকারী, কিন্তু casually inspect করা কঠিন। Production-এ কোনো hint সত্যিই present কি না debug করতে গেলে raw headers গুরুত্বপূর্ণ; ঠিক এই ধরনের পরিস্থিতিই covered হয়েছে our guide to debugging redirects and HTTP headers-এ।
Caching-ও গুরুত্বপূর্ণ। Mismatched credentials, ভুল as, বা ভিন্ন URL parameters দিয়ে resource preload করলে duplicate download হতে পারে। ভালো উদ্দেশ্যের preload performance bug হয়ে যাওয়ার সবচেয়ে সাধারণ উপায়গুলোর একটি এটি।
সাধারণ ভুল
অতিরিক্ত preload করা
সবকিছু critical হলে, কিছুই critical নয়। Initial rendering বা immediate interactivity-এর জন্য প্রয়োজনীয় resource-এ preload সীমিত রাখুন। একটি typical page-এ zero থেকে three preloads থাকা উচিত, twenty নয়।
Required resource-এর জন্য prefetch ব্যবহার করা
Prefetch low priority এবং optional। বর্তমান page-এর প্রয়োজনীয় asset-এর জন্য এটি ব্যবহার করবেন না। Page-এর এখনই লাগলে preload বা normal HTML discovery বিবেচনা করুন।
প্রতিটি third party-তে preconnect করা
Third-party-heavy page-এ প্রায়ই দশ বা তার বেশি external origin থাকে। সবগুলোতে preconnect করা noise তৈরি করে। যে এক বা দুটি একই সঙ্গে critical এবং predictably used, সেগুলো বেছে নিন।
Mobile condition ভুলে যাওয়া
Resource hints slower connection-এ সবচেয়ে মূল্যবান, কিন্তু সেখানেই সবচেয়ে বিপজ্জনকও। Fast desktop connection-এ wasted prefetch সামান্য rounding error। Constrained mobile plan-এ এটি খারাপ trade।
একটি সহজ decision table
| Situation | Best hint | Why | |---|---:|---| | CSS-এর মাধ্যমে আবিষ্কৃত critical font | preload | বর্তমান page-এর এটি লাগে, discovery দেরিতে হয় | | CSS বা client rendering-এর আড়ালে থাকা hero image | preload | Image দেরিতে শুরু হলে LCP উন্নত করতে পারে | | User intent-এর পর সম্ভাব্য next route | prefetch | বর্তমান page block না করে future navigation-এ সাহায্য করে | | Critical third-party font/API origin | preconnect | Critical path থেকে connection setup সরায় | | সম্ভাব্য কিন্তু অনিশ্চিত third-party origin | dns-prefetch বা কিছু নয় | কম cost, কম confidence | | Below-the-fold image | কিছু নয় | Lazy loading এবং browser priority-কে কাজ করতে দিন |
শান্ত rule
Resource hints সবচেয়ে ভালো কাজ করে যখন সেগুলো boring এবং specific। একটি font। একটি LCP image। একটি গুরুত্বপূর্ণ third-party origin। Intent-এর পর একটি সম্ভাব্য next route।
Optimism হিসেবে ব্যবহার করলে এগুলো খারাপ কাজ করে: হয়তো user-এর এটি লাগবে, হয়তো browser-এর ওটা fetch করা উচিত, হয়তো বেশি hints মানে বেশি speed।
Browsers ইতিমধ্যেই aggressiveভাবে optimize করে। আপনার কাজ প্রতিটি request micromanage করা নয়। আপনার কাজ হলো সেই কয়েকটি case ঠিক করা যেখানে সঠিক মুহূর্তে ব্রাউজারের কাছে তথ্যের অভাব থাকে।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
আমার কি সব font preload করা উচিত?
প্রতিটি internal link-এর জন্য prefetch ব্যবহার করা কি নিরাপদ?
preconnect এবং dns-prefetch-এর পার্থক্য কী?
Resource hints কি Core Web Vitals উন্নত করতে পারে?
Resource hints HTML-এ যোগ করা উচিত, নাকি HTTP headers-এ?
স्रोत ও আরও পড়া
