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

در عین حال من شرکت بزرگی را می شناسم که به خاطر مسائلی که به آن اشاره شد خودش را از این ابزار محدود کرده است
حالا من از یک دید دیگه به این قضیه نگاه می کنم (مخصوصا که اینجا یک وبلاگ سئو است و نه وبلاگ طراحی سایت)
بعضی افکت ها و مخفی کاریهای جاوا اسکریپت مشکلاتی از نظر سئو ایجاد می کنه
یعنی باعث میشه گوگل فکر کنه که سایت می خواهد بعضی محتوا ها را از کاربران مخفی کنه
مثل منو های کشویی یا اسلاید شات های گالری و ...
 برای اینکه مشکلات از این دست پیش نیاید
کار جالبی که افراد خبره انجام می دهند(البته استفاده از این متد را من تو کشور خودمون ندیده ام) این است که برای وقتهایی که جاوا اسکریپت غیر فعال است صفحات را به یک صفحه از پیش تعریف شده ریدایرکت می کنند و در آن صفحه با ارسال هدر  101 به موتورهای جستجوگر اعلام می کنند که یک خطای کوچک (101 Switching Protocols) موجب عدم نمایش صفحه شده است

برای اینکار وقتی مرورگر کاربر فاقد جاوا اسکریپت باشد آن را به صفحه  ای که هدر 101 ارسال می کند می فرستیم
( اگر فکر می کنید که چون ربات گوگل یا googlebot  بدون جاوا اسکریپت است ممکن است با دیدن کد زیر از صفحه شما کوچ کند و آن را ایندکس نکند اشتباه می کنید)
برای فرستادن کاربر فاقد جاوا اسکریپت   به صفحه  ای که هدر 101 ارسال می کند از کد زیر در داخل صفحه مورد نظر استفاده کنید

کد خطای 101 ساده ترین کد خطای http  است که هیچ مشکلی برای شما ایجاد نمی کند
توضیحات کاملتر آن را می توانید در لینک 101 Switching Protocols بخوانید
 با این کار  گوگل  می فهمد که این سایت بدون جاوا اسکریپت خروجی ندارد ضمن این که کاربران هم متوجه می شوند که باید جاوا اسکریپت شان را روشن کنند
اما نکته ای در مورد ارسال هدر 101
ارسال هدر 101 در مود CGI سرور آپاچی بدون مشکل انجام می شود یعنی به صورت

 اما در تنظیمات سرور با مود آپاچی یا FastCGI  شما نمی توانید این هدر را بصورت زیر بفرستید

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

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

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

 روی قضیه نحوه افزایش سرعت یک سایت کلا دو راهکار داریم
1- کاهش درخواست از سرور
2- کاهش حجم انتقال
عمده حرف من از کاهش درخواست از سرور با مدیریت بهتر کش و css sprit  است

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

1- یک سری تغییرات کلی در نحوه چیدمان عکس ها و  نحوه استفاده از css که بحث پیرامون آن خارج از این مقوله است

2-غیرفعال کردن ETAG و  اولویت دادن به کش استاتیک

وقتی Etag فعال باشد مرورگر مدیریت کش را به سرور واگذار می کند یعنی مرورگر درخواست فایل را می دهد اگر سروردر  پاسخ هدر 304 را داد به این معنی است که کش را مورد استفاده قرار بده (محتوا فرستاه نمی شود) در غیر اینصورت محتوا ارسال می شود
ایراد etag در این است که در هر صورت ارسال درخواست را داریم (حتی اگر کش انجام شده باشد) اما در کش استاتیک مدیریت کش با مرورگر است

3- vary
vary که من آنرا واکنش معنی کرده ام  برای مدیریت واکنش ISP ها در کش محتوا می باشد
و یکی از مواردی که این هدر ایجاد می شود در مود ریرایت است
همه مشکل از آنجا شروع می شود که سرورPHP  در حالت gzip و غیر آن vary متفاوت ایجاد می کند. یعنی
در حالت فشرده vary در اکثر سرور ها بصورت     * "user-agent"

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

و این یکی از مهمترین مواردی است که چون مرورگر دچار سردرگمی می شود کش را ضایع می کند

راهکار پیشنهادی:
  استفاده ار force-no-vary  برای غیر فعال کردن کش آی اس پی ها و یا  استفاده از vary یکسان در هر دوحالت

4- HTTP/1.1 و  force-response-1.0
برای حفظ سازگاری در همه مرورگر ها پاسخ های هدر سرور همواره با HTTP/0 داده شود
که هیچ تاثیری در سرعت و قابلیت ها ندارد اما  موجب می شود که در مواردی که مرورگری پروتکل HTTP 1 را پشتیبانی نمیکند مانعی برای کش شدن پیش نیاید

5- برای کش همیشه نوع درخواست باید HTTP GET باشد (و بدون پارمترهای GET  تا کش انجام شود ) به عبارتی در متد POST هیچ کشی انجام نخواهد شد و این از مواردی است که در آجاکسی باید درنظر گرفته شود
6- یکی از شرطهای جالب Cache-Control کهIE بیشتر آن را مورد توجه قرار داده
 post-check و  pre-check است  مثلا
Control: post-check=10; pre-check=120
که به مروگر می گوید تا 10 ثانیه که اصلا نیازی به چک کردن ندارد و به کش اعتماد کن و بعد از 120 ثانیه هم قبل از استفاده از  کش از سرور استعلام بگیر(شباهت بسیاری به max-age دارد)

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

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

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

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

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

برای شما از 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"

استفاده شود

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

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

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

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

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

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

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

خوب وقتی آب و هوای امروز تهران 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

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

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

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

 Internet Explorer"s Cache-Control Extensions

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

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