سفارش تبلیغ
صبا ویژن

سئو- استفاده از همه شگردها برای بالابردن ترافیک سایت

تعین میزان فشرده سازی محتوای صفحه

    نظر

دست آورد دیگری از  گروه گوگل 724 

برای اولین بار در وب   گروه G724  اقدام به ارایه سرویس «تعین میزان فشرده سازی محتوای صفحه» نمود
از این پس شما می توانید میزان فشرده سازی صفحات سایت خود را بدون نیاز به هیچ نرم افزار دیگری  بررسی کنید
کاری که در هیچ کجا سابقه ندارد
محاسبه میزان فضای فشرده شده از صفحه از این نظر مهم است که می توانید پی ببرید که آیا هاست شما این قابلیت را فعال کرده است یا خیر (قابلیت GZIP یا فشرده سازی محتوای صفحات)
وقتی محتوای صفحه فشرده شده باشد گاها  تا 85 درصد از حجم آن کم می شود خوب فرض کنید اگر محتوای شما 100 کیلو حجم داشته باشد به 15 کیلو کاهش پیدا  می کند
یعنی کاربران شما صفحات را سریعتر از همیشه  خواهند دید همینطور است برای گوگل
من شخصا جای دیگری که این امکان را در اختیار کاربران داده باشند ندیده ام  
علی الخصوص  که وضعیت فشرده سازی را در سطوح مختلف نشان می دهد 
متاسفانه به دلیل محدودیتهای موجود و جلوگیری از اضافه بار روی سرور این امکان  فقط برای مشتریان گروه گوگل 724  بدون محدودیت در صفحات است و
برای سایر افراد تنها صفحه اصلی سنجیده می شود و البته چون مقادیر کسانی که مشتری نیستند کش می شود عملا یکبار بیشتر محاسبه فشرده سازی انجام نمی شود
اما همان یکبارش هم کافیست تا متوجه شوید  که آیا هاست و در کنار آن نرم افزار مورد استفاده تان  محتوا را فشرده می کند یا خیر
در صورتیکه تمایل به استفاده از سرویس  تعین میزان فشرده سازی محتوای صفحه دارید  بر روی عکس زیر کلیک نمایید

 

سرویس نمایش فشرده سازی محتوای سایتها


فشرده سازی خودکار مطالب در php

    نظر

بررسی روشهای متنوع فشرده سازی  خودکار مطالب در php 

منظور از فشرده سازی خودکار  فشرده سازی توسط سیستم عامل سرور می باشد یعنی بدون اینکه شما نیازی به فشرده کردن  محتوا در  کدهای خودتان با توابع PHP داشته باشید مدیریت آن را به آپاچی بسپارید

آپاچی را طبق متد دیفلت یا RFC 1951 - DEFLATE Compressed Data Format Specification version  پیکربندی کنید

حال به دو روش می توانید فشرده سازی با آپاچی را از طریق HTACCESS مدیریت نمایید
در سرور  فشرده سازی بر روی بافر انجام می  شود  اما می توان آن را طوری پیکر بندی کرد که ابتدا بافر ایجاد شود و بعد هدر ها ارسال شود (در این صورت می توان هدر یا ست کردن کوکی را در بین متن یا BODY هم انجام داد بدون اینکه خطایی دیده شود) و یا اینکه به ترتیب کد بافر ایجاد شود (در صورت استفاده از هدر بعد از  BODY  خطا دیده می شود )
که هر کدام مزایا و معایب خود را دارد که در اینجا مجال پرداختن به آن نیست
روش اول ـ  ابتدا بافر ایجاد شود و بعد هدر ها ارسال شود
برای این کار باید کد زیر را در htaccess نوشت 
php_flag output_handler ob_gzhandler
توجه شود که این کد تنها در مود آپاچی اجرا می شود و نه مود CGi ضمنا این کد خودبخود کد php_flag output_buffering Off را هم به همراه دارد
روش دوم -  به ترتیب کد بافر ایجاد شود 
برای این کار باید کد زیر را در htaccess نوشت 
AddOutputFilterByType DEFLATE
دقت نمایید که من خیلی کلی نوشتم و در عمل باید ظرافتها را اعمال کنید مثلا بهتر است کد آخر بصورت زیر نوشته شود
<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-java application/java
</ifmodule>

واکنش های پایدار یا Vary consistently

    نظر

تعجب نکنید مبحثی که می خواهم باز کنم چیز پیچیده و غامض نیست بلکه  بیشتر می خواهم یکی از نکاتی را باز کنم که به درست کار نکردن کش تنظیم شده شما مربوط میشود

برای شما از VARY در شرایط کش شدن یک صفحه سایت گفتم و توضیح مختصری از آن دادم

در اینجا vary را  بیشتر می خواهم  بازکنم تا مطلب بیشتر برایتان جا بیفتد

vary به طور خلاصه به واکنش ها در برابر محتوا اشاره دارد

وقتی تمام آن را خواندید متوجه می شوید که Vary  از مواردی است که به سرور شما مربوط می شود تا فایلهای سایت تان پس اگر سرور اختصاصی ندارید یا دسترسی به تنظیمات سرور ندارید نیازی به خواندن آن پیدا نمی کنید

یکی از ارزنده ترین کاربردهای vary در پروکسی هایی است که همه چیز را کش می کنند(یک مثال از پروکسی گفته شده ISP ها هستند)

فرض کنید شما مطلبی را می خوانید که سرور آن را به دو صورت  gzip شده و فشرده نشده بسته به پشتیبانی مرورگر می فرستد

حال فرض کنید مرورگر شما gzip را پشتیبانی می کند (در 90 درصد مواقع چنین است) پس سرور مطلب را بصورت gzip یا فشرده می فرستد

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

حال کاربر دیگری با ارایه آدرس اینترنتی یکسان  همان  مطلب را از سرور در خواست می کند با این تفاوت که مرورگرش gzip را پشتیبانی نمی کند

حال ISP بین راه وقتی درخواست را می بیند و می بیند که آن را بر اساس آإرس اعلام شده در کش خودش  دارد کش را برای این کاربر بی خبر از همه جا می فرستد

و چون مرورگر او gzip را پشتیبانی نمی کند تنها یک سری حروف عجق وجق می بیند

در نتیجه فکر می کند از منبع ایراد وجود دارد

برای اجتناب از خطاهای از این دست VARY تعریف شد

در حالت فشرده vary در اکثر سرور ها بصورت     * "user-agent"

و در حالت غیر فشرده بصورت   * "accept-encoding, user-agent"

در می اید

تا اینجای کار همه چیز درست است و دیگر ISP ها دچار آن اشتباه مهلک نمی شوند

ولی مشکل اینجاست که اینبار مرورگر دچار مشکل شده و نمی تواند تفاوتی بین حالت فشرده شده و غیر آن قائل شود در نتیجه کش را مورد استفاده قرار نمی دهد

چرا که در حالت فشرده و غیر آن دو نوع VARY دریافت کرده

برای رفع این مشکل توصیه می شود که در هر دوحالت از vary  حالت فشرده یعنی

* "user-agent"

استفاده شود

 


چرا کسانی که مطالب ما را کپی می کنند بالاتر قرار می گیرند

    نظر

پاسخ به چند سوال مطرح شده از سوی کاربران

حتما برای شما هم این سوال  پیش آمده که چرا کسانی که مطالب ما را کپی می کنند بالاتر قرار می گیرند

من در پست الگوریتم پاندا گوگل پاسخ ان را داده ام

مثلا کاربر در سایت شما با دیدن مطلب رغبتی به خواندنش نشان ندهد (مثلا انتخاب فونت بد یا قالب افتضاح سایت و یا ...) اما در سایت رقیب همه چیز مهیا شده که کاربر در کنار خواندن مطلبی که با جستجویش وارد سایت شده، مطالب دیگری را هم بخواند و همین یعنی امتیاز در الگوریتم پاندا گوگل  پس چاره کار در این است که به گوگل بفهمانیم که مطلب متعلق به شماست اینطور کاربران همه سایت شما را می بینند و زرق وبرق سایت متخلف در کپی از سایت شما جایگاهی پیدا نمی کند با این مقدمه سوال دوست عزیز را مطرح می کنم

سوال سلام و عرض ادب خدمت شما آقای شیبانی چندی پیش سایت منو از بلاک در آورده بودید که لازمه تو هر ایمیلم ازتون سپاسگذاری کنم .
میخواستم یک موضوع رو باهاتون در میون بذارم.
الان سایت من بخوبی مطالبش ایندکس میشه و دامین تولز سئوی سایتمو 100% نشون میده همچنین بخوبی سایتو آپدیت میکنم اما میخوام دلیل اینو بدونم که چرا مطالبم توی گوگل خیلی پایینتر از مطالب سایت رقبا میاد چطور میتونم این مشکلو حل کنم آیا تغییر قالب تاثیر آنچنانی دارد ؟
ضمنا من موقع بلاک شدن لینکستان سایت رو برداشتم و دیگر هیچ لینکی به سایت دوستانم ندادم خب  دوستان هم لینک منو از سایت هاشون برداشتن آیا ممکنه مشکل فوق بخاطر همین عمل من باشه ؟ 
با تشکر
جواب:سلام
از لطف حضرت عالی کمال تشکر را دارم
من نمی دونم که شما تولید محتوا می کنید و یا کپی
و این خیلی مهم است
اگر کپی از سایت دیگری دارید حتما یک لینک به آن سایت بدهید
لینکی که هیچ شرط و شروطی نداشته باشد مثل (rel=nofollow) و این به گوگل می فهماند که شما حقوق ناشرین را رعایت کرده اید ضمن اینکه اگر کسی از شما به گوگل شاکی شد کاری پیش نمی برد و دردسری برایتان ندارد
اما اگر مطالبتان از خودتان است به هرکس که از شما کپی کرده بدون اینکه به شما لینک سالم داده باشد دوستانه هشدار بدهید که لینک به شما را فراموش کرده
و همینکه او به شما لینک بدهد کافیست (هرچند در این مورد احتمالا گوگل جایگاه شما را برنگرداند چرا که  همینکه چند روز بالاتر از شما بوده باعث شده محبوبیت کسب کند  اما در موارد بعدی باعث می شود که جایگاه خودتان را داشته باشید)
ولی اگر راضی به اینکار نشد با اینکه گفتنش برایم جالب نیست اما چاره ای جز شکایت از او به گوگل ندارید
البته بهتر است سعی کنید او را قانع کنید چرا که با اقدامات گوگل ممکن است  لطمات مادی زیادی از قطع ورودی های گوگل  به متخلف برسد تا ان حد که تصورش را نکند برای اینکار من توضیحاتی در لینک شکایت کپی مطالب گوگل دادم
شاید به ظاهر وقت گیر باشد ولی با چند روز استمرار بر این کار متخلف خودش می فهمد که ادامه این کار او را همیشه از صحنه جستجوی گوگل خارج می کند

چطور مقادیر فرم با POST را کش کنیم

    نظر

کمتر پیش میاید که بخواهیم مقادیر ایجاد شده از یک فرم را کش کنیم چرا که معمولا مقادیر فرم دل بخواه تغییر می کند و اکثرا اطلاعات شخصی و محرمانه است

اما گاه پیش میاید که می خواهیم مقادیر کش شود چرا که نه محرمانه است و نه شخصی

در نظر بگیرید پیش بینی آب و هوا را

خوب وقتی آب و هوای امروز تهران 10 درجه بالای صفر اعلام شده اگر  کاربر یکساعت دیگر  هم  در فرم پیش بینی آب و هوا  تهران را انتخاب کرد باز نتیجه همان 10 درجه بالای صفر خواهد بود

همانطور که قبلا گفته شد پروتکل HTTP  طوری نوشته شده که تنها مرورگرها اجازه کش کردن متد GET را دارند

در مواردی که فرم ما با متد post نوشته شده  به روش جاوا اسکریپتی می توان بصورت GET با آن برخورد کرد تا مقادیر را به درستی کش کند

کافیست با استفاده از  پلاگین جیکوئری jquery و ترفند های جاوا اسکریپتی (قرار دادن onsubmit و فرارخوانی کد زیر) فرم را بصورت Post ارسال کنیم

$.get(
    "form.php",
    {param1 : 1, paramX : "abc"},
    function(data) {
       alert("page content: " + data);
    }
);

کدخط بالا  از لینک مقابل برداشته شده است در صورتیکه نیاز به استفاده از این ترفند برای کش کردن فرم با متد POST در صفحات دارید حتما لینک مقابل را ببینید

HTTP GET request in Java


بررسی دقیق Cache-Control در کش شرطی

    نظر
کلا ما دو روش منطقی برای افزایش سرعت یک صفحه اینترنتی داریم
1- کم کردن تعداد درخواستها از سرور (مثلا با کم کردن عکس ها و کدهای الحاقی جاوا اسکریپت و css ها و...)
2- کم کردن حجم داده هایی که باید از سرور به مرورگر منتقل شود (مثل فشردهسازی محتوا با gzip یا کامپرس کردن عکس ها)
با کش استاتیک یا cache static  ما به هر دو خواسته می رسیم و با کش شرطی  با ETAGS  خواسته دوم  حاصل میشود

اهدافی که ما از  کش کردن محتوا داریم عبارتند از

1- پایین  نگهداشتن لود سرور
2-لود شبکه
3- زمان تاخیر کاربر
به عنوان مثال مرورگر اینترنت اکسپلور برای تاعمل کش با سرور به صورت زیر ارسال هدر دارد
Pragma: no-cache
با این هدر مرورگر به سرور می فهماند که تمایلی به استفاده از کش موجود ندارد و ترجیح می دهد از نسخه سرور استفاده کند (این هدر با ctrl+F5 ایجاد می شود)
If-Modified-Since: datetime
مرورگر منتظر پاسخ سرور است که آیا از این تاریخ فایل تغییر داشته است یا خیر
If-None-Match: etagvalue
مرورگر به سرور اعلام می کند مشخصه فایل(ETAG) که من در اختیار دارم به صورت زیر است اگر نسخه جدیدتری داری اطلاع بده 
هر دو هدر If-Modified-Since یا  If-None-Match حالت کش شرطی را به وجود می آورند 

در حالت کش استاتیک ارسال هدر از هیچ نوع را نداریم 

در حالت شرطی سرور یا مجددا فایل را با کد 200 ارسال می کند و یا تنها هدر 304 را بصورت زیر می فرستد
HTTP/304 Not Modified
حال با این مقدمه برویم سر اصل مبحث یعنی
بررسی دقیق   Cache-Control در کش شرطی
در حالت شرطی ما هدری داریم به نام  Cache-Control
که انتخاب های (یکی یا برخی ) ‌زیر را برای آن داریم
no-store, no-cache, must-revalidate, pre-check, post-check
حالت no-store به معنی این است که مرورگر کش نمی کند
 no-cache به معنی این است که مرورگر کش می کند ولی تغییرات را با  هربار  رفرش جویاست 
must-revalidate به معنی لازم اجرا دانستن سوال از  سرور برای کش است
و اما دو حالت دیگر یعنی  pre-check, post-check ویژه اینترنت اکسپلور هست
post-check یعنی تا این زمان نیازی به استعلام برای تغییر کش نیست
pre-check یعنی تا قبل از این زمان حتما از تغییر نکردن کش مطمئن شو
مثلا اینطور می شود گفت که با کد زیر 
Control: post-check=10; pre-check=120
مکالمه مرورگر با سرور اینگونه است که 
تا ثانیه 10 ام که هیچ مکالمه ای انجام نمی شود و مانند کش استاتیک برخورد می شود
از ثانیه 10 تا 120 برای کش سوال میشود
بعد از ثانیه 120 کش منقضی است و مرورگر وجود آن را نادید می گیرد
با این توضیحات معلوم میشود که pre-check شباهت بسیاری به max-age دارد
با این تفاوت که ie تا زمانیکه به زمان post-check نرسیده باشد از هدر استفاده نمی کند (کش استاتیک)
این دو حتما باید با هم مقدار دهی شوند و در صورتیکه یکی از آنها مقدار دهی نشود خطا می باشد
مقدار داده شده عدد و به معنای ثانیه است مثلا عدد 60 یعنی یک دقیقه
اگر هر دو صفر باشند هیچکدام در نظر گرفته نمی شوند
post-check همیشه باید کوچکتر یا مساوی با  pre-check باشد در غیر اینصورت خطا است
اگر post-check صفر باشد و pre-check  عددی بزرگتر از صفر باشد تنها اتفاقی که می افتد محتوای صفحه دوبار دانلود می شود 
پس اگر می خواهید بدون دلیل صفحه اتان دو بار در مرورگر بار گذاری شود از کد زیر استفاده نمایید
Control: post-check=0; pre-check=1
اما حالت منطقی این است که همیشه به post-check عددی بدهید که موجب دانلود بی دلیل صفحه در هربار نشود مثلا می توانید 10 بدهید

مطلب برداشت آزادی بود از مطلب:

 Internet Explorer"s Cache-Control Extensions


چه وقتهایی نباید محتوای یک صفحه را کش کرد

    نظر

گفتیم که کش کردن محتوا نقش زیادی در بالا بردن سرعت بارگذاری صفحه دارد اما مواردی هم هست که نباید محتوا را کش کرد

به عبارتی به برخی دلایل و صلاحدیدهای امنیتی نباید خیلی اصرا به کش محتوا داد و در مواردی با تمهیدات لازم را دید(علی الخصوص در مواردی که از CDN استفاده شده است)

به طور خلاصه هر محتوایی ک وابسته به تغییرات زمان است یا وابسته به شرایطی است که در هدرهای HTTP پیش بینی نشده است مانند آی پی درخواست کننده در این موارد نباید محتوا را کش کرد
که شامل
1-اگر محتوای مطالب شما هر 5 دقیقه به روز می شود کلا قید کش را بزنید
 2-  اگر طراحی سایت بگونه ای است که محتوا متناسب با آی پی  شخص درخواست کننده  تغییر می کند محتوا را نباید کش کرد
3- در صورتیکه شرایط خاص در هدر سایت پیش بینی شده است می توان صفحات وابسته به زبان یا agent یا کدینگ فونت را نیز کش کرد  که در اینصورت باید 
Vary: negotiate,accept-language,accept-charset
را داشته باشیم تا بتوان بر اساس زبان یا انکدینگ انتخابی زبان  یا سایر انتخاب های محلی درخواست  کش را به مرورگر داد
چرا که مرورگر ها قادرند بر حسب vary کش را مدیریت کنند
 نکته: Vary: negotiate به معنای وضعیت مذاکره است مثلا ارسال فرم  و امثالهم که مرورگر باید از کش صفحه بپرهیزد

شرایط کش شدن یک صفحه سایت

    نظر

شاید برایتان پیش آمده باشد که همه تنظیمات را در کش سرور و مرورگر اعمال کرده اید اما آخر هم به یک کش پایدار و مطمئن نرسیده اید

این از اون مواردی است که بقولی به آن فوت کوزه گری می گویند من  ده مورد از آنها را در زیر می اورم و پیدا کردن الباقی را به خودتان وا می گذارم

1- هدر های expire (تاریخ انقضا) و  max-age (طول عمر) modify (زمان آخرین تغییر) توسط سرور ارسال شود

2- پاسخ کد وضعیت HTTP یکی از کدهای  200 ، 203 ، 300 ، 301 و یا 410 را داشته باشد.
3- نوع درخواست باید HTTP GET باشد (و نه PUT یا POST)
4- اگر در درخواست هدرهای مربوط به مجوز یا Authorization وجود داشته باشد پاسخ  کش نخواهد شد
5- اگر در پاسخ سرور هدرهای مربوط به مجوز یا Authorization وجود داشته باشد پاسخ   به شرطی کش خواهد شد که هدر 
Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا  "public"  آورده شود
6- اگر یو-آر-ال  یا URL دارای query string یا پرامترهای متد GET از صفحه HTML باشد  معمولا کش انجام نخواهد شد مگر اینکه علاوه بر هدر Expires  مانند بند  5 هدر Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا  "public"  آورده شود (طبق رفرنس RFC2616  و بخش 13.9 و 13.2.1)
7- اگر پاسخ سرور با کد 200 باشد حداقل یکی از هدرهای  "Etag" یا  "Last-Modified"  یا "Expires" و یا مانند بند  5 هدر Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا  "public"  آورده شود تا عمل کش کردن پاسخ سرور در مروگر انجام شود
8- اگر هدر Cache-Control ارسال شود و یکی از انتخاب ها در آن  "private" باشد کش انجام نخواهد شد مگر بصورت کش استاتیک (که ارزش امنیتی خیلی پایینی دارد و برای داده های مهم اصلا توصیه نمی شود)
9- به همین نرتیب اگر یکی از انتخاب های ما  no-store در     Cache-Control باش کش صورت نخواهد گرفت
10- بالاخره اینکه اگر در هدر Vary پاسخ ارسالی match-all "*" باشد کش صورت نمی گیرد (معمولا User-Agent است که بهتر است Accept-Encoding,User-Agent باشد تا همیشه کش موفقی داشته باشیم)

 


 


چگونه امنیت سایت را بالا ببریم

    نظر

تصورش را بکنید یک روز وقتی وارد ftp سایتتون می شوید متوجه تغییراتی در ساختار فایلها می شوید 
مثلا فایلی ناخواسته به لیست فایلهایتان اضافه شده و یا تاریخ modify یکی از پوشه ها تون تغییر کرده و خیلی موارد دیگر
خلاصه متوجه حضور ناخوانده در سایتتان می شوید
البته به شکلهای دیگر هم می توان حضور ناخوانده را فهمید مثلا تغییر محتوای صفحات یا ریدایرکت های ناخواسته صفحات، هدرهای ارسالی مشکوک و خیلی موارد دیگر(از جمله جارو جنجالی که بعد پیش خواهد آمد)
شما فقط مشکوک شده اید و اینکه بتوانید تغییر را بیابید شاید روزها طول بکشد 
چرا که ما هم هکر داریم  هم جوجه هکر 
جوجه هکر به کسی می گویند که تا سایتی را هک کرد تو بوق و کرنا می کند که آی من چنین کردم و چنان
اما هکر واقعی مدتها در داخل یک سایت پرسه می زند بدون اینکه کسی از وجودش خبردار شود
فقط ممکن است مرتکب یکی از اشتباهات شمرده شده در بالا شود که بتوان به وجودش پی برد
پس قبول دارید اگر با یک هکر واقعی طرف شوید روزها طول خواهد کشید تا مچش را بگیرید
و در این مدت اگر هکر با شما خصومت داشته باشد از نظر سئو  هر ضربه ای که هکر بخواهد به شما می تواند وارد کند  و اگر در پی منافع مادی باشد می تواند تا مدتها مثل زالو به بدنه سایت شما بچسبد
برای مورد اول
مثلا تغییر هویت صفحات(= کپی رایت )‌و یا انتقال ارزش صفحات با ارزش  به صفحه خودش و... 
و برای مورد دوم:
تغییر فاکتورها، شارژ حساب، دسترسی به اطلاعات مالی کاربران و  بالاخره تغییر موجودی حسابها بصورت جابجا کردن به حساب خودش 
و اینجاست که یک  بک آپ سالم به دردتان می خورد تا ظرف چند ثانیه همه چیز را به حالت اول برگردانید
اما قبل از هر چیز برای گرفتن چنین بک آپی باید مطمئن شوید که فایلهایتان سالم است 
و اینجاست که متدی برای چک مرتب سلامت سیستم  فایلها و دیتابیس نیاز است
بهترین روش از نظر من ثبت etag فایلها  است و  همیشه با بررسی etag فایلها  مثل روغن موتور  از اصل کار مطمئن شوید چرا که  اگر هکر در کار خودش هر چقدر هم مهارت داشته باشد یعنی تا آن حد که حتی اگر قادر باشد با روش هایی (که غیر ممکن نیست) تاریخ تغییر فایلها را به قبل برگرداند تا تغییراتش مشخص نشود اما حریف مقدار etag که توسط اپاچی ساخته می شود و یک کد 128 بیتی هش شده است که براساس سایز،تاریخ،نام فایل و بالاخره شماره اینود فایل ساخته می شود نمی شود 
کافیست شما هرازگاهی مثل مروگر به چک ایتگ ازقبل ذخیره شده با مقدار فعلی بنمایید همین و بس
البته برای این کار یک پکیج براساس  php  باید نوشته شود که etag ها را در دیتابیس ذخیره کند و هر چند وقت مثل چک روغن ماشین ایتگ ها هم چک شود

چگونگی هدرهای شرطی در سیستم کش و پاسخ دهی به آن

    نظر

اگر فایلهای کش شده مبتنی بر شناسایی بر اساس ETAG باشند هدر شرط برای بررسی کش "If-None-Match" می باشد

اما اگر ما ETAG را غیر فعال کرده باشیم شرط بررسی کش از هدر ارسال شده توسط مرورگر "If-Modified-Since" می باشد

بسته به اینکه کدام هدر از مرورگر ارسال شده باشد پاسخ دریافتی از سرور نیز باید متفاوت باشد

اگر با شرط "If-Modified-Since" کش مرورگر شناخته شد به عبارتی در حالت فعال بودن ETAG در پاسخ آن سرور  اگر کش معتبر باشد هدر 304 یا "304 Not Modified" را می فرستد بدون محتوا (یعنی هیچ خروجی متنی در کار نخواهد بود.) اما اگر مشخص شد که کش ملغی شده در پاسخ هدر 200 با محتوای کامل درخواستی ارسال میشود

ولی با خاموش کردن etag اگر ما بتوانیم ماهیت کش استاتیک را ایجاد کنیم (ارسال هدر expire  مثلا با مود expire در آپاچی ) دیگر مرورگر تا زمان اکسپایر شدن درخواست به مرورگر نمی فرستد

هدرهای شرطی یا مبتنی بر ETAG دو مزیت دارد

1- با تغییر مشخصه فایل خودبخود فایل جدید به مرورگر ارسال می شود

2- پهنای باندی مصرف نمی شود

اما هدرهای استاتیک تنها مزیت دوم را دارند و اگر به هردلیلی فایل تغییر کند نمی توان به مرورگر این را فهماند

ضمنا این موارد را از طریق  تست با ابزار فایرباگ یا کروم  نمی توان بررسی کرد و تنها http://www.webpagetest.org آزمون مطمئنی برای کش و بررسی تفاوتهای گفته شده بین کش شرطی و استاتیک خواهد بود

در مبحث بعدی به این موضوع خواهیم پرداخت که چه چیزهایی را نمی توان کش کرد