راهنمایی‌های عملی

تنظیم کش مرورگر (Browser Caching) و مدت زمان آن در هاستینگ

  • 15 دقیقه برای خواندن
تنظیم کش مرورگر (Browser Caching) و مدت زمان آن در هاستینگ

مدت زمان کش مرورگر (browser caching) با استفاده از هدرهای HTTP مانند Cache-Control و Expires تعیین می‌شود و مشخص می‌کند فایل‌های استاتیک سایت چقدر در مرورگر بازدیدکننده باقی بمانند. در عمل برای فایل‌های CSS، جاوااسکریپت، تصاویر، فونت و آیکون‌ها هدر Cache-Control (و در برخی موارد Expires) تنظیم می‌شود؛ مثلاً فایل‌های نسخه‌دار CSS و JS تا یک سال، تصاویر ۳۰ روز تا یک سال و صفحات HTML با مدت کوتاه یا نیاز به اعتبارسنجی مجدد. تنظیم درست از دانلود تکراری فایل‌ها جلوگیری می‌کند، سرعت بارگذاری را افزایش می‌دهد و امتیاز Core Web Vitals را بهبود می‌بخشد.

در این راهنما نحوه کار کش مرورگر، مدت مناسب برای هر نوع فایل، و نحوه پیاده‌سازی آن در Apache، Nginx، LiteSpeed، وردپرس و CDN را قدم‌به‌قدم توضیح می‌دهیم. هدف فقط گرفتن امتیاز سبز در ابزارهای تست سرعت نیست؛ بلکه ارائه فایل به‌روز به کاربر در کنار استفاده بهینه از منابع سرور، کاهش TTFB و مصرف پهنای باند و ایجاد حس سرعت در بازدیدهای مجدد است. به‌ویژه در هاستینگ اشتراکی، هاست وردپرس و پروژه‌های سازمانی، استراتژی درست کش مرورگر یکی از مؤثرترین بهبودهای عملکردی با کمترین هزینه است. بسته های هاستینگ وب Hostragons

کش مرورگر چیست؟

کش مرورگر به معنای ذخیره موقت منابع استاتیک دانلودشده هنگام باز شدن صفحه در دستگاه کاربر است. وقتی بازدیدکننده وارد صفحه اصلی می‌شود، لوگو، فایل CSS، جاوااسکریپت، فونت‌ها و تصاویر دانلود می‌شوند. اگر هدرهای کش درست تنظیم شده باشند، در بازدید دوم یا بازگشت بعدی مرورگر نیازی به درخواست مجدد از سرور ندارد و صفحه سریع‌تر بارگذاری می‌شود.

فرض کنید صفحه اصلی شما ۲ مگابایت است: ۱.۴ مگابایت تصویر، ۳۰۰ کیلوبایت CSS و JS و ۱۰۰ کیلوبایت فونت. در اولین بازدید همه دانلود می‌شوند، اما در بازدید دوم مرورگر از نسخه محلی استفاده می‌کند و حجم داده منتقل‌شده از شبکه به شدت کاهش می‌یابد. این تفاوت در اتصال موبایل و سایت‌های پرترافیک بیشتر محسوس است.

کش مرورگر را نباید با کش سمت سرور اشتباه گرفت. کش سرور خروجی PHP یا نتایج دیتابیس را روی سرور نگه می‌دارد، در حالی که کش مرورگر منابع دستگاه کاربر را دوباره استفاده می‌کند. برای بهترین عملکرد هر دو لایه باید با هم برنامه‌ریزی شوند. در سایت‌های وردپرسی، کش صفحه، کش آبجکت، کش CDN و کش مرورگر معمولاً اجزای یک استراتژی بهینه‌سازی واحد هستند. هاستینگ وردپرس و بهینه‌سازی عملکرد

چرا کش مرورگر برای سئو مهم است؟

گوگل سایت‌هایی را که تجربه سریع و پایدار ارائه می‌دهند از نظر رضایت کاربر ارزشمندتر می‌داند. کش مرورگر به‌تنهایی رتبه را تضمین نمی‌کند، اما چون مستقیماً بر سرعت صفحه، تأخیر تعامل و کارایی بارگذاری منابع تأثیر می‌گذارد، عملکرد سئو را تقویت می‌کند. به‌ویژه در سناریوهایی مثل بازدید مجدد، گشت‌وگذار دسته‌بندی‌ها، انتقال بین صفحات محصول و پیمایش داخل بلاگ تفاوت چشمگیری ایجاد می‌کند.

در استانداردهای سئوی ۲۰۲۶، عملکرد فنی فقط امتیاز Lighthouse نیست. تجربه کاربری که گوگل ارزیابی می‌کند با معیارهای LCP، INP، CLS، TTFB و داده‌های واقعی کاربر مرتبط است. دانلود دوباره CSS و JS مدت LCP را طولانی می‌کند، درخواست مجدد فونت‌ها ثبات بصری را مختل می‌کند و عدم کش تصاویر حس کندی در موبایل ایجاد می‌کند.

  • بازدید مجدد سریع‌تر: کاربر فایل‌های یکسان را دوباره دانلود نمی‌کند.
  • کاهش مصرف پهنای باند: ترافیک سرور کم می‌شود و منابع هاستینگ بهتر استفاده می‌شوند.
  • بهبود کارایی خزش: منابع استاتیک برای ربات‌ها و کاربران منظم‌تر ارائه می‌شوند.
  • کاهش نرخ پرش: صفحات سریع‌تر بازشونده تعامل کاربر را افزایش می‌دهند.
  • عملکرد پایدارتر: نوسانات بار در CDN و هاستینگ بهتر مدیریت می‌شوند.

هدرهای اصلی HTTP Cache

مدت زمان کش مرورگر با هدرهای پاسخ HTTP مدیریت می‌شود. رایج‌ترین هدرها Cache-Control، Expires، ETag و Last-Modified هستند. در پروژه‌های مدرن نقطه کنترل اصلی هدر Cache-Control است؛ Expires بیشتر برای سازگاری با نسخه‌های قدیمی استفاده می‌شود.

کنترل حافظه پنهان

Cache-Control به مرورگر و سیستم‌های کش میانی می‌گوید فایل چگونه ذخیره شود. دستورالعمل‌های پراستفاده عبارت‌اند از:

  • max-age: تعداد ثانیه‌هایی که منبع تازه در نظر گرفته می‌شود. مثلاً max-age=31536000 حدود یک سال است.
  • public: منبع می‌تواند در کش‌های اشتراکی مثل مرورگر و CDN ذخیره شود.
  • private: منبع فقط در مرورگر کاربر ذخیره شود.
  • no-cache: منبع قبل از استفاده باید با سرور اعتبارسنجی شود؛ به معنای خاموش کردن کامل کش نیست.
  • no-store: منبع در هیچ‌جا ذخیره نشود؛ مناسب صفحات پرداخت، پنل و داده‌های شخصی.
  • immutable: منبع تا پایان مدت اعتبار تغییر نخواهد کرد؛ ایده‌آل برای فایل‌های نسخه‌دار.

نمونه هدر یک فایل استاتیک: Cache-Control: public, max-age=31536000, immutable. این هدر به مرورگر می‌گوید فایل را یک سال نگه دارد و تا وقتی نام فایل تغییر نکرده، نیازی به بررسی مجدد نیست.

Expires

هدر Expires تاریخ و ساعت دقیق انقضا را مشخص می‌کند. مثلاً برای یک تصویر می‌توان ۳۰ روز آینده را تنظیم کرد. اما چون از تاریخ مطلق استفاده می‌کند، انعطاف Cache-Control را ندارد. در تنظیمات مدرن Cache-Control اولویت دارد و Expires فقط برای مرورگرهای قدیمی اضافه می‌شود.

ETag و Last-Modified

ETag و Last-Modified مکانیسم‌های اعتبارسنجی هستند. مرورگر می‌تواند از سرور بپرسد نسخه فایل موجود در دستش به‌روز است یا نه. اگر فایل تغییر نکرده باشد، سرور پاسخ 304 Not Modified برمی‌گرداند و بدنه فایل دوباره دانلود نمی‌شود. این روش برای محتوای HTML که اغلب تغییر می‌کند یا وقتی نمی‌خواهید مدت کش طولانی بدهید، مفید است.

برای هر نوع فایل چه مدت کش مناسب است؟

اشتباه رایج، دادن مدت یکسان به همه فایل‌هاست. HTML، CSS، JS، تصویر، فونت و پاسخ API رفتار به‌روزرسانی متفاوتی دارند. قانون اصلی ساده است: اگر نام فایل قابل تغییر باشد، مدت کش طولانی مجاز است؛ اگر محتوا بدون تغییر نام فایل مرتب عوض می‌شود، مدت کوتاه یا اعتبارسنجی استفاده کنید.

برای هر نوع فایل چه مدت کش مناسب است؟
نوع منبعمدت پیشنهادیهدر پیشنهادیتوضیح
صفحات HTML۰–۱۰ دقیقه یا اعتبارسنجیno-cache, max-age=0اگر محتوا مرتب تغییر می‌کند، تازگی اولویت دارد.
CSS و JS۳۰ روز تا ۱ سالpublic, max-age=31536000, immutableنام فایل باید نسخه‌دار باشد: style.v3.css
تصاویر۳۰ روز تا ۱ سالpublic, max-age=2592000 یا 31536000لوگو و آیکون طولانی؛ بنرهای کمپین کوتاه‌تر
فونت‌ها۶ ماه تا ۱ سالpublic, max-age=31536000, immutableفایل‌های WOFF2 معمولاً کمتر تغییر می‌کنند.
PDF و مدیا۷ روز تا ۶ ماهpublic, max-age=604800 یا 15552000در کاتالوگ‌های به‌روز شونده مدت را با دقت انتخاب کنید.
صفحات ادمین و پرداختبدون کشno-store, privateامنیت و داده‌های شخصی اولویت دارند.

این جدول نقطه شروع کلی است. در فروشگاه اینترنتی صفحات HTML حاوی قیمت و موجودی نباید به‌طور تهاجمی کش شوند، اما تصاویر محصول تا وقتی نام فایل تغییر کند می‌توانند یک سال کش شوند. در سایت سازمانی لوگو، فونت و فایل‌های قالب مدت طولانی نگه داشته می‌شوند، ولی بنرهای کمپین که مرتب تغییر می‌کنند بهتر است ۷–۳۰ روزه باشند.

چگونه مدت زمان کش مرورگر را برنامه‌ریزی کنیم؟

برای استراتژی موفق کش ابتدا فایل‌های سایت را دسته‌بندی کنید. از نظر فنی باید بر اساس پسوند فایل قانون نوشت؛ از نظر استراتژیک باید بر اساس دفعات به‌روزرسانی مدت تعیین کرد.

۱. منابع استاتیک و دینامیک را جدا کنید

فایل‌های CSS، JS، JPG، PNG، WebP، SVG، WOFF2 استاتیک هستند. HTML، سبد خرید، پنل کاربری، نتایج جستجو و پاسخ API دینامیک محسوب می‌شوند. منابع استاتیک مدت طولانی کش می‌شوند، اما محتوای دینامیک باید با احتیاط مدیریت شود. به‌ویژه محتوای اختصاصی کاربر نباید public کش شود.

۲. نسخه‌بندی فایل را به کار ببرید

راه امن دادن مدت کش طولانی، نسخه‌بندی فایل است. اگر style.css را یک سال کش کنید و بعداً محتوایش را تغییر دهید، برخی کاربران همچنان طراحی قدیمی را می‌بینند. به‌جای آن از نام‌هایی مثل style.2026.01.css، app.v12.js یا app.8f3a2.js (حاوی هش فایل) استفاده کنید تا هنگام به‌روزرسانی نام جدید منتشر شود و مرورگر فایل جدید را دانلود کند.

قالب‌های وردپرس و ابزارهای مدرن build این کار را خودکار انجام می‌دهند. اگر قالب توسعه می‌دهید، در توابع wp_enqueue_style و wp_enqueue_script از پارامتر version استفاده کنید. با این حال در برخی تنظیمات CDN رفتار query string متفاوت است، بنابراین اضافه کردن هش به نام فایل روش مقاوم‌تری است.

۳. با HTML تهاجمی عمل نکنید

صفحات HTML محتوای اصلی قابل مشاهده کاربر را حمل می‌کنند، بنابراین معمولاً با مدت کوتاه یا revalidation مدیریت می‌شوند. در بلاگ ۵–۱۰ دقیقه کش کافی است؛ در صفحات خبری، کمپین یا قیمت مدت کوتاه‌تری لازم است. در وردپرس اگر از کش صفحه استفاده می‌کنید، هدر کش مرورگر را همراه با مکانیسم purge سرور و CDN در نظر بگیرید.

۴. صفحات حساس امنیتی را از کش خارج کنید

صفحه ورود، پنل مشتری، مراحل پرداخت، خلاصه سفارش، فاکتور و صفحات حاوی داده شخصی باید هدر Cache-Control: no-store, private داشته باشند. کش مرورگر برای عملکرد است، اما نباید امنیت داده‌های شخصی را به خطر بیندازد. استفاده از SSL در این مرحله الزامی است. گواهی SSL Hostragons

تنظیم کش مرورگر در Apache با .htaccess

در سرورهای Apache معمولاً از فایل .htaccess برای تنظیم کش مرورگر استفاده می‌شود. برای اکثر کاربران هاستینگ اشتراکی این روش عملی‌ترین راه است. ابتدا باید ماژول‌های mod_expires و mod_headers فعال باشند که در اکثر هاستینگ‌های باکیفیت به‌صورت پیش‌فرض فعال هستند.

منطق کلی: تصاویر و فونت‌ها مدت طولانی، CSS و JS مدت طولانی، HTML مدت کوتاه یا اعتبارسنجی. در .htaccess با دستورات ExpiresByType و Header set Cache-Control بر اساس نوع فایل قانون می‌نویسید. مثلاً image/webp، image/jpeg، image/png، image/svg+xml یک سال؛ text/css و application/javascript یک سال؛ text/html با no-cache.

قبل از اعمال، از .htaccess پشتیبان بگیرید. قانون اشتباه می‌تواند خطای ۵۰۰ ایجاد کند. بعد از تغییر، سایت را در تب ناشناس باز کنید و در DevTools بخش Network هدر پاسخ فایل را بررسی کنید. اگر Cache-Control دیده نشد، ممکن است ماژول سرور غیرفعال باشد، CDN هدر را تغییر دهد یا افزونه‌ای هدرها را override کند.

نمونه مدت‌های Apache: CSS و JS با max-age=31536000، تصاویر با max-age=31536000، PDF با max-age=2592000، HTML با max-age=0 و no-cache. این مقادیر شروع خوبی هستند و باید بر اساس جریان انتشار سایت بازبینی شوند. در زیرساخت هاستینگ Hostragons هنگام استفاده از تنظیمات عملکردی .htaccess، تداخل با تنظیمات کش قالب و افزونه را بررسی کنید. تنظیمات عملکرد Apache .htaccess

تنظیم Browser Caching در Nginx

در Nginx هدرهای کش داخل بلوک‌های server یا location تعریف می‌شوند. Nginx به‌خاطر ارائه سریع فایل‌های استاتیک در پروژه‌های پرترافیک محبوب است. منطق اصلی، نوشتن قانون location بر اساس پسوند و تعیین expires و add_header Cache-Control است.

رویکرد نمونه: به CSS، JS، WebP، JPG، PNG، SVG، WOFF2 هدر expires 1y و Cache-Control: public, immutable بدهید. برای خروجی HTML از expires off یا no-cache استفاده کنید. اگر CDN دارید، نحوه تفسیر هدر Cache-Control ارسالی از origin توسط CDN را هم تست کنید.

نکته مهم در Nginx این است که دستور add_header در برخی شرایط فقط روی کدهای پاسخ خاص اعمال می‌شود. در نسخه‌های مدرن از پارامتر always استفاده کنید. همچنین اگر هم اپلیکیشن، هم Nginx و هم CDN همان هدر را اضافه کنند، مقادیر Cache-Control تکراری یا متضاد ایجاد می‌شود که باید زنجیره اولویت را مشخص کنید.

LiteSpeed و کش مرورگر در وردپرس

سرورهای LiteSpeed به‌ویژه در پروژه‌های وردپرسی با افزونه LiteSpeed Cache مزیت عملکردی قوی ایجاد می‌کنند. اما کش مرورگر را باید از کش صفحه جدا کرد. وقتی گزینه Browser Cache در افزونه فعال شود، هدرهای کش برای فایل‌های استاتیک به‌صورت خودکار اعمال می‌شوند، ولی همچنان کنترل مدت‌ها مهم است.

در وردپرس توصیه می‌شود فایل‌های استاتیک مدت طولانی کش شوند و نسخه‌بندی فایل فعال بماند. هنگام به‌روزرسانی قالب، تغییر CSS یا JS، افزونه باید کش را پاک کند و اگر CDN استفاده می‌شود، عملیات purge انجام شود. در غیر این صورت برخی کاربران طراحی قدیمی یا رفتار نادرست جاوااسکریپت را می‌بینند.

در افزونه‌های محبوب کش گزینه‌های Browser Cache، Minify، Combine، Critical CSS، ادغام CDN و Object Cache وجود دارد. فعال کردن همزمان و تهاجمی همه گزینه‌ها همیشه درست نیست. ابتدا هدرهای کش مرورگر را تنظیم کنید، سپس minify و combine را تست کنید. در سال ۲۰۲۶ که HTTP/2 و HTTP/3 رایج هستند، ترکیب همه فایل‌ها به اندازه گذشته حیاتی نیست و حتی ممکن است کارایی کش را کاهش دهد.

اگر سایت وردپرسی شما کند است، مشکل فقط browser cache نیست. bloated دیتابیس، قالب سنگین، افزونه زیاد، تصاویر بهینه‌نشده و هاستینگ ضعیف هم تأثیرگذارند. بنابراین تنظیمات کش را همراه با هاستینگ باکیفیت، نسخه به‌روز PHP و پیکربندی درست SSL ارزیابی کنید. هاستینگ وردپرس Hostragons

تنظیم مدت کش هنگام استفاده از CDN

CDN فایل‌های استاتیک را از سرورهای لبه نزدیک کاربر تحویل می‌دهد. کش مرورگر فایل را در مرورگر کاربر نگه می‌دارد. وقتی این دو لایه با هم کار کنند، افزایش عملکرد محسوس‌تر است. اما مدت edge cache در پنل CDN باید با هدر Cache-Control مبدأ سازگار باشد.

رویکرد کلی: در سرور مبدأ به فایل‌های استاتیک Cache-Control یک‌ساله بدهید و در CDN هم TTL مشابه یا کنترل‌شده تعریف کنید. هنگام تغییر فایل، نام آن را نسخه‌دار کنید یا purge CDN انجام دهید. برای صفحات HTML اگر از کش CDN استفاده می‌کنید، قوانین ویژه بسازید و بخش سبد خرید، حساب کاربری، پرداخت و پنل مدیریت را کاملاً خارج از کش نگه دارید.

مشکل رایج در سایت‌های CDNدار، نمایش فایل‌های قدیمی بعد از به‌روزرسانی است. دلیل معمولاً تغییر محتوا بدون تغییر نام فایل یا انجام ندادن purge CDN است. محکم‌ترین روش، تولید فایل هش‌دار در فرآیند build و فراخوانی نام جدید در HTML است تا حتی اگر مرورگر یا CDN فایل قدیمی را نگه داشته باشد، صفحه جدید فایل جدید را درخواست کند.

چک‌لیست گام‌به‌گام پیاده‌سازی

چک‌لیست زیر برنامه عملی برای تنظیم مدت زمان کش مرورگر ارائه می‌دهد. در سایت سازمانی کوچک ظرف ۳۰–۶۰ دقیقه قابل اجراست؛ در فروشگاه یا پروژه نرم‌افزاری سفارشی زمان تست طولانی‌تر است.

  • ۱. فهرست فایل‌ها را تهیه کنید: CSS، JS، تصویر، فونت، PDF، HTML و پاسخ API را جدا کنید.
  • ۲. دفعات به‌روزرسانی را مشخص کنید: کدام فایل‌ها روزانه و کدام‌ها ماهانه تغییر می‌کنند.
  • ۳. استراتژی نسخه‌بندی انتخاب کنید: هش نام فایل، پارامتر نسخه یا شماره build استفاده کنید.
  • ۴. قوانین سرور را اضافه کنید: در Apache، Nginx، LiteSpeed یا پنل CDN هدرهای Cache-Control را تعریف کنید.
  • ۵. صفحات حساس را مستثنا کنید: در بخش ادمین، پرداخت، سبد خرید، پنل کاربر و داده شخصی از no-store استفاده کنید.
  • ۶. تست کنید: با Chrome DevTools، curl -I، WebPageTest، Lighthouse و تست دستگاه واقعی اعتبارسنجی کنید.
  • ۷. بعد از انتشار نظارت کنید: فایل قدیمی اشتباه، طراحی خراب یا خطای JS وجود دارد؟

چگونه کش مرورگر را تست کنیم؟

سریع‌ترین راه بررسی کارکرد تنظیمات، استفاده از ابزار توسعه مرورگر است. در کروم صفحه را باز کنید، به تب Network DevTools بروید، روی یک فایل CSS یا تصویر کلیک کنید و بخش Response Headers را برای مقدار Cache-Control بررسی کنید. در بارگذاری دوم در ستون Status عبارت memory cache یا disk cache را می‌بینید.

اگر از خط فرمان استفاده می‌کنید، دستور curl -I yourdomain.com/file.css هدرهای پاسخ را نشان می‌دهد. مقادیر Cache-Control، Expires، ETag و Last-Modified را کنترل کنید. اگر هدر مورد انتظار وجود نداشت، احتمالاً یکی از لایه‌های اپلیکیشن، وب‌سرور یا CDN تنظیم را تغییر داده است.

برای تست عملکرد از Lighthouse، PageSpeed Insights و WebPageTest استفاده کنید. اما پیشنهادهای این ابزارها را کورکورانه اعمال نکنید؛ سناریوی واقعی کاربر را در نظر بگیرید. مثلاً Lighthouse برای فایل‌های استاتیک مدت کش طولانی پیشنهاد می‌کند، ولی برای صفحات HTML همان شدت را انتظار ندارد. همچنین ابزارهای تست گاهی اسکریپت‌های شخص ثالث را هشدار می‌دهند؛ Google Fonts، شبکه‌های تبلیغاتی یا اسکریپت‌های شبکه‌های اجتماعی ممکن است خارج از کنترل شما باشند.

اشتباهات رایج

هرچند کش مرورگر ساده به نظر می‌رسد، پیکربندی اشتباه می‌تواند مشکلات به‌روزرسانی، ریسک امنیتی و تجربه کاربری ضعیف ایجاد کند. اشتباهات زیر به‌ویژه در میان تازه‌کاران شایع است.

  • دادن یک سال کش به همه منابع: HTML، پاسخ API و محتوای اختصاصی کاربر نباید شامل این قانون شوند.
  • استفاده از کش طولانی بدون نسخه‌بندی: کاربران ممکن است CSS یا JS قدیمی را همچنان ببینند.
  • فراموش کردن فرآیند purge CDN: حتی اگر مبدأ به‌روز شود، CDN ممکن است فایل قدیمی را ارائه دهد.
  • استفاده هم‌زمان چند افزونه کش: افزونه‌های متعدد هدرهای یکسان را می‌نویسند و تداخل ایجاد می‌کنند.
  • تفسیر اشتباه هشدارهای شخص ثالث: هدرهای کش اسکریپت‌های خارجی ممکن است در کنترل شما نباشد.
  • کش کردن صفحات حساس: در صفحات پرداخت و حساب کاربری باید از no-store استفاده شود.

مقادیر شروع پیشنهادی

برای سایت جدید مقادیر شروع ایمن به این شکل خلاصه می‌شوند: فایل‌های CSS و JS نسخه‌دار یک سال؛ تصاویر یک سال (تصاویر کمپین ۳۰ روز)؛ فونت‌ها یک سال؛ فایل‌های PDF بسته به دفعات به‌روزرسانی ۷–۱۸۰ روز؛ صفحات HTML no-cache یا چند دقیقه کوتاه. این رویکرد تعادل عملکرد و تازگی محتوا را حفظ می‌کند.

اگر سایت شما معرفی سازمانی است، مدت‌های طولانی معمولاً بدون مشکل کار می‌کنند. اگر فروشگاه اینترنتی هستید، فایل‌های استاتیک صفحات محصول را مدت طولانی کش کنید، اما قیمت، موجودی، سبد خرید و داده کاربر را خارج از کش نگه دارید. اگر سایت خبری یا بلاگ هستید، تصاویر و فایل‌های قالب را مدت طولانی نگه دارید و خروجی HTML را بر اساس دفعات انتشار کوتاه‌مدت کش کنید. دامنه، SSL و زیرساخت هاستینگ هم بخشی از زنجیره عملکرد هستند. استعلام دامنه Hostragons راهکارهای هاستینگ شرکتی Hostragons

نتیجه‌گیری

وقتی مدت زمان کش مرورگر درست برنامه‌ریزی شود، عملکرد بازدید مجدد سایت را به‌طور جدی افزایش می‌دهد. قانون اصلی: فایل‌های استاتیک نسخه‌دار مدت طولانی، صفحات HTML و صفحات حاوی داده شخصی مدت کوتاه یا no-store. همین منطق در Apache، Nginx، LiteSpeed، وردپرس و محیط CDN صدق می‌کند: نوع منبع را بشناسید، دفعات به‌روزرسانی را تعیین کنید، هدرهای Cache-Control را تست کنید و بعد از انتشار نظارت را ادامه دهید.

به طور خلاصه، browser caching بهینه‌سازی سرعت کم‌هزینه اما پربازده است. اگر سایت خود را روی زیرساخت Hostragons میزبانی می‌کنید، با انتخاب تنظیمات کش مناسب نوع هاستینگ خود هم تجربه کاربر و هم عملکرد فنی سئو را تقویت کنید. برای بررسی مناسب‌ترین راه‌حل میزبانی، گزینه‌های هاستینگ Hostragons را مشاهده کنید یا پیکربندی کش سایت فعلی خود را قدم‌به‌قدم بررسی کنید. بسته های هاستینگ Hostragons

سؤالات متداول

مدت زمان کش مرورگر چقدر باید باشد؟

برای فایل‌های استاتیک نسخه‌دار مثل CSS، JS، تصویر و فونت، ۳۰ روز تا یک سال ایده‌آل است. در صفحات HTML به‌خاطر اهمیت تازگی محتوا، no-cache، max-age=0 یا مدت کوتاه چند دقیقه‌ای ترجیح داده می‌شود.

تفاوت Cache-Control و Expires چیست؟

Cache-Control هدر مدرن و انعطاف‌پذیرتر است و از قواعد ثانیه‌محور مثل max-age استفاده می‌کند. Expires مقدار تاریخ-ساعت مشخصی می‌دهد. در پروژه‌های به‌روز Cache-Control اولویت دارد و Expires فقط برای سازگاری با مرورگرهای قدیمی اضافه می‌شود.

در وردپرس چگونه browser caching را فعال کنیم؟

در افزونه‌هایی مثل LiteSpeed Cache، WP Rocket و W3 Total Cache گزینه Browser Cache یا کش مرورگر را فعال کنید. همچنین می‌توانید با .htaccess یا پیکربندی سرور بر اساس نوع فایل هدرهای Cache-Control اضافه کنید.

با دادن کش طولانی، به‌روزرسانی‌های سایت دیده نمی‌شوند؟

اگر بدون تغییر نام فایل، CSS یا JS را به‌روزرسانی کنید، برخی کاربران فایل قدیمی را می‌بینند. برای جلوگیری از این مشکل از نسخه‌بندی فایل، نام فایل حاوی هش و عملیات purge CDN استفاده کنید.

آیا صفحات پرداخت و پنل کاربری باید کش شوند؟

خیر. در صفحات پرداخت، سبد خرید، حساب کاربری، فاکتور و پنل مدیریت که حاوی داده شخصی هستند، باید از هدرهای امن Cache-Control: no-store, private استفاده شود. برای عملکرد نباید از امنیت چشم‌پوشی کرد.

این مقاله را به اشتراک بگذارید:
Sophia Mendes

متخصص راه‌حل‌های ابری

دارای بیش از ۸ سال تجربه در معماری ابری و مدیریت داده‌ها. به‌ویژه در طراحی برنامه‌های مبتنی بر ابر فعالیت می‌کند.

همه نوشته‌ها →