محتوا
این مقاله برای اولین بار در شماره 231 مجله .net منتشر شد - پرفروش ترین مجله جهان برای طراحان و توسعه دهندگان وب.
سرعت باید برای هر وب سایتی مهم باشد. این یک واقعیت مشهور است که Google از سرعت سایت به عنوان معیار رتبه بندی برای نتایج جستجو استفاده می کند. این به ما می گوید که بازدید کنندگان وب سایت های سریع را ترجیح می دهند - جای تعجب نیست!
یاكوب نیلسن در سال 1993 در مورد سه محدودیت زمان پاسخ نوشت. اگرچه این تحقیق از نظر استانداردهای اینترنتی قدیمی است ، اما در طی 19 سال روانشناسی ما تغییر چندانی نکرده است. وی اظهار داشت که اگر سیستمی در کمتر از 0.1 ثانیه پاسخ دهد ، همان لحظه تلقی می شود ، در حالی که پاسخ های سریعتر از یک ثانیه باعث می شود جریان فکری کاربر بدون وقفه باقی بماند. بارگیری صفحه وب در مدت زمان 0.1 ثانیه احتمالاً غیرممکن است. حدود 0.34 ثانیه بهترین زمان بارگیری Google UK را نشان می دهد بنابراین این به عنوان یک معیار واقع گرایانه تر (البته بلند پروازانه) عمل می کند. بارگیری صفحه در جایی از منطقه 0.34 تا 1 ثانیه قابل دستیابی و مهم است.
قیمت کاهش سرعت
این نوع اهداف تأثیرات واقعی در وب سایت و تجارت شما دارند. Google's Marissa Mayer در سال 2006 در مورد آزمایشی صحبت کرد که در آن تعداد نتایج برگشتی توسط موتور جستجو به 30 مورد افزایش یافته بود. این باعث کاهش سرعت بارگذاری صفحه در حدود 500 میلی ثانیه شد و 20٪ افت بازدید به این امر نسبت داد. در همین حال ، آمازون بارگیری صفحه را با افزایش 100 میلی متری به تاخیر انداخت و دریافت که "حتی تاخیرهای بسیار کوچک نیز منجر به کاهش قابل توجه و پرهزینه درآمد" خواهد شد.
سایر انجمن های نامطلوب مرتبط با وب سایت های کند شامل کاهش اعتبار ، کیفیت پایین تر درک شده و سایت دارای جذابیت و جذابیت کمتری است. افزایش ناامیدی کاربر و افزایش فشار خون دو اثر دیگری است که احتمالاً همه ما در یک برهه از آن تجربه کرده ایم! اما چگونه می توان اطمینان حاصل کرد که وب سایت های ما به اندازه کافی سریع بارگیری می شوند تا از این مشکلات جلوگیری کنیم؟
یکی از اولین مواردی که باید بررسی شود ، اندازه کد HTML شماست. این احتمالاً یکی از نادیده گرفته شده ترین مناطق است ، شاید به این دلیل که مردم تصور می کنند دیگر با اتصالات باند پهن مدرن چندان مرتبط نیست. برخی از سیستم های مدیریت محتوا با مقداری که از بین می روند نسبتاً لیبرال هستند - یکی از دلایلی که می تواند ساخت سایت های شخصی شما بهتر باشد.
به عنوان یک راهنما باید بتوانید اکثر صفحات را در 50 کیلوبایت کد HTML جای دهید ، و اگر کمتر از 20 کیلوبایت هستید ، بسیار خوب عمل می کنید. بدیهی است که موارد استثنایی نیز وجود دارد ، اما این یک قانون کاملاً خوب است.
همچنین لازم به یادآوری است که اکنون افراد بیشتر در وب سایت های کامل در دستگاه های تلفن همراه مرور می کنند. اختلاف سرعت بین سایتهای مشاهده شده از طریق تلفن همراه اغلب بیشتر قابل توجه است ، زیرا سرعت انتقال آنها در مقایسه با اتصالات سیمی کمتر است. دو وب سایت رقابتی با اختلاف اندازه 100 کیلوبایت در هر صفحه می تواند به معنای بیش از یک ثانیه اختلاف زمان بارگذاری در برخی از شبکه های موبایل کند باشد - به خوبی در منطقه "جریان فکر متوقف شده" مشخص شده توسط Jakob Nielsen. وب سایت اصلاح کننده و سریعتر بسیار ناامیدکننده است که مرور کند ، و این یک اختلاف رقابتی متفاوت نسبت به وب سایت های چاق تر است و راهی طولانی تر برای تشویق بازدیدهای تکراری دارد.
یکی از ویژگی های مهم اکثر وب سرورها امکان سرویس دهی به HTML در قالب فشرده است. از آنجا که HTML به طور ذاتی حاوی داده های تکراری زیادی است ، از این رو یک کاندید مناسب برای فشرده سازی است. به عنوان مثال ، HTML 18.1KB یک صفحه اصلی در صورت ارائه در قالب فشرده به 6.3KB کاهش می یابد. این 65 درصد پس انداز است! الگوریتم های فشرده سازی هرچه متن بیشتری برای کار با آنها باشد ، بازده را افزایش می دهند ، بنابراین با صفحات HTML بزرگتر ، صرفه جویی بیشتری خواهید دید. یک صفحه 138.1K در یک انجمن محبوب وقتی که فشرده می شود به 25.7K کاهش می یابد ، صرفه جویی بیش از 80 درصد - که می تواند به طور قابل توجهی کل زمان انتقال منابع را بهبود بخشد.
در خدمت کردن HTML در این فرم هیچ منفی وجود ندارد. همه باید آن را برای تمام محتوای HTML خود فعال کنند.برخی از سرورهای وب تنظیمات متفاوتی برای فشرده سازی محتوای ثابت و تولید شده دارند ، بنابراین لازم است اطمینان حاصل کنید که در صورت امکان محتوای فشرده را برای هر دو ارائه می کنید.
شبکه های تحویل محتوا
شبکه های تحویل محتوا (معروف به CDN) همچنین می توانند بارگذاری وب سایت شما را به میزان قابل توجهی بهبود بخشند. CDN ها مجموعه ای از سرورهای توزیع شده در سرتاسر جهان هستند که همگی نسخه هایی از مطالب شما را در خود دارند. هنگامی که یک کاربر از وب سایت شما تصویری را درخواست می کند که در CDN میزبانی شده است ، از سرور موجود در CDN از نظر جغرافیایی نزدیک به کاربر برای ارائه تصویر استفاده می شود.
خدمات CDN زیادی در دسترس است. برخی از اینها بسیار پرهزینه هستند اما تبلیغ می کنند که عملکرد بهتری نسبت به CDN های ارزان قیمت ارائه می دهند. خدمات رایگان CDN نیز شروع به تولید کرده اند و شاید ارزش آزمایش داشته باشد تا ببینید آیا می توانند عملکرد وب سایت شما را بهبود ببخشند.
یک نکته مهم هنگام استفاده از CDN این است که اطمینان حاصل کنید که آن را به درستی تنظیم کرده اید تا هیچ ارزش SEO را از دست ندهید. بسته به ماهیت وب سایت خود ، ممکن است از تصاویر میزبانی شده در دامنه خود بازدید زیادی داشته باشید و با انتقال آنها به یک دامنه خارجی ، ممکن است بر میزان بازدید شما تأثیر منفی بگذارد. سرویس S3 آمازون شما را قادر می سازد یک زیر دامنه را به CDN خود نشان دهید ، که یک ویژگی بسیار مطلوب در CDN است.
ارائه محتوا در یک دامنه دیگر (مانند CDN) یا یک زیر دامنه در نام دامنه خود که کوکی ها را تنظیم نمی کند ، مزیت اصلی دیگری دارد. وقتی کوکی در دامنه ای تنظیم می شود ، مرورگر داده کوکی را با هر درخواست به هر منبع موجود در همان دامنه می فرستد. بیشتر اوقات ، داده های کوکی برای محتوای ثابت مانند تصاویر ، فایل های CSS یا JavaScript مورد نیاز نیست. نرخ بارگذاری کاربران وب اغلب بسیار پایین تر از نرخ های بارگیری موجود است ، که در برخی موارد باعث کاهش قابل توجه زمان بارگذاری صفحه می شود. با استفاده از یک نام دامنه دیگر برای ارائه محتوای ثابت شما ، مرورگرها این داده های کوکی غیر ضروری را نمی فرستند ، زیرا آنها سیاست های دامنه متقابل سختی دارند. این می تواند زمان درخواست را برای هر منبع به طور قابل توجهی تسریع کند.
کوکی ها در وب سایت ها نیز می توانند بیشتر درخواست HTTP را اشغال کنند. 1500 بایت تقریباً بیشترین محدودیت تک بسته برای شبکه های بزرگ است ، بنابراین اگر می توانید درخواست های HTTP خود را زیر این حد نگه دارید ، کل درخواست HTTP باید در یک بسته ارسال شود. این می تواند باعث بهبود زمان بارگیری صفحه شود. Google توصیه می کند که اندازه کوکی های شما کمتر از 400 بایت باشد - این امر تا حد زیادی به نگه داشتن درخواست های HTTP وب سایت های شما در حد یک بسته / 1500 بایت می انجامد.
تکنیک های بعدی
تکنیک های دیگری وجود دارد که به راحتی قابل اجرا هستند و می توانند مزایای زیادی برای سرعت سایت شما داشته باشند. یکی این است که فایلهای جاوا اسکریپت خود را در انتهای سند HTML خود قرار دهید ، درست قبل از بسته شدن برچسب متن ، زیرا مرورگرها محدودیت در تعداد منابع را دارند که می توانند به طور موازی از همان میزبان بارگیری کنند.
مشخصات اصلی HTTP 1.1 که در سال 1999 نوشته شده است ، توصیه می کند مرورگرها فقط باید از هر نام میزبان حداکثر دو منبع را به طور موازی بارگیری کنند. اما مرورگرهای مدرن به طور پیش فرض حدود شش محدودیت دارند. اگر صفحه وب شما بیش از شش منبع خارجی دارد (مانند تصاویر / پرونده های جاوا اسکریپت / CSS) ، ممکن است برای اطمینان از مرورگر ، عملکرد بهتری برای ارائه آنها از چندین دامنه (مانند زیر دامنه در نام دامنه اصلی یا CDN) به شما ارائه دهد. در بارگیری های موازی حداکثر حد خود را نمی گذارد.
به جای تقسیم چندین درخواست در دامنه های مختلف ، ممکن است ترکیب آنها را در نظر بگیرید. هر درخواست HTTP دارای یک سربار مربوط به آن است. ده ها تصویر مانند آیکون های وب سایت شما به عنوان منابع جداگانه ، هزینه های زیادی را ایجاد می کند و باعث کندی وب سایت شما می شود که اغلب یک مورد مهم است. با ترکیب تصاویر خود در یک تصویر معروف به "برگه sprite" می توانید تعداد درخواست های مورد نیاز را کاهش دهید. برای نمایش تصویر ، آن را در CSS با تنظیم عرض و ارتفاع یک عنصر بر روی تصویری که می خواهید نمایش داده شود تعریف کنید ، سپس پس زمینه را روی صفحه sprite تنظیم کنید. با استفاده از موقعیت پس زمینه ویژگی ما می توانیم صفحه sprite پس زمینه را به موقعیت خود منتقل کنیم بنابراین در وب سایت شما به عنوان تصویر مورد نظر ظاهر می شود.
ورق های Sprite مزایای دیگری نیز دارند. اگر از تصاویر جاذب ماوس استفاده می کنید ، ذخیره آنها در همان صفحه sprite به معنای این است که هنگام شروع ماوس ، تأخیری رخ نمی دهد زیرا تصویر ماوس از قبل در صفحه sprite بارگذاری شده است! این می تواند به طور قابل توجهی زمان بارگیری کاربر را بهبود بخشد و یک وب سایت احساس پاسخگو تر ایجاد کند.
تعیین ابعاد هر تصویر دیگر در img /> برچسب ها همچنین عامل مهمی در افزایش زمان بارگیری قابل درک در صفحه وب شما هستند. معمولاً برای توسعه دهندگان مشخص نیست که عرض و ارتفاع را برای تصاویر در صفحات مشخص کنند. این امر می تواند باعث بزرگ شدن اندازه صفحه در هنگام پرش هر تصویر (به طور جزئی) شود و باعث کند شدن اوضاع شود. اگر ابعاد مشخصی تنظیم شود ، مرورگر می تواند با بارگیری تصویر ، فضای صفحه را ذخیره کند ، تغییر اندازه صفحه را متوقف کرده و گاهی اوقات زمان بارگیری کاربر را به طور قابل توجهی بهبود می بخشد.
بنابراین چه کار دیگری می توانیم برای بهبود این کار انجام دهیم؟ واکشی از جمله ویژگی های موجود در HTML5 است. پیش بارگیری قبل از اینکه کاربر واقعاً از آنها بخواهد ، بارگیری صفحات و منابع را امکان پذیر می کند. پشتیبانی آن در حال حاضر به Firefox و Chrome (با یک نحو جایگزین) محدود شده است. با این حال ، سهولت اجرا و سودمندی آن در بهبود زمان بارگیری قابل درک در صفحه وب شما بسیار زیاد است ، و نکته قابل توجه برای پیاده سازی آن است.
! —Firefox Prefetching -> link rel = "prefetch" href = "http://www.example.com/page2.html">! - Chrome Prerender -> link rel = "prerender" href = "http: / /www.example.com/page2.html ">! - هر دو در یک خط -> پیوند rel = "پیش از پیش آماده سازی" href = "http://www.example.com/page2.html">
یک تفاوت رفتاری بین پیش تنظیم و قبل از ارائه وجود دارد. موزیلا پیش دستی منبع سطح بالای یک URL خاص ، معمولاً خود صفحه HTML را بارگیری می کند ، و در اینجا بارگیری متوقف می شود. گوگل تسلیم کردن منابع کودک را نیز بارگیری می کند و به عبارت Google "تمام کارهای لازم برای نمایش صفحه به کاربر ، بدون نمایش واقعی آن تا زمان کلیک کاربر" را انجام می دهد.
ملاحظات پیش فرض و قبل از ارائه
اما استفاده از این ویژگی با ملاحظات مهم نیز همراه است. اگر بیش از حد دارایی یا صفحات را پیش پرداخت / پیش فرض کنید ، ممکن است کل تجربه مرور کاربر آسیب ببیند. اگر آماری از سمت سرور داشته باشید ، می تواند به شدت کج شود. اگر کاربر روی منبع بارگیری نشده کلیک کند و از وب سایت شما خارج شود ، ردیاب آمار شما ممکن است بازدید را دو بازدید از صفحه حساب کند ، نه بازدید واقعی. این می تواند برای معیارهای مهم مانند نرخ گزاف گمراه کننده باشد.
Chrome's تسلیم کردن پیش فرض دیگری نیز دارد که توسعه دهندگان باید از آن آگاه باشند ، زیرا صفحه از پیش معرفی شده JavaScript را اجرا می کند. پیش نمایش ، صفحه را دقیقاً به همان روشی بارگذاری می کند که اگر کاربر روی پیوند کلیک کرده باشد. هیچ عنوان HTTP خاصی با پیش نمایش ارسال نمی شود. با این حال ، API قابلیت مشاهده صفحه به شما امکان می دهد تشخیص دهید که آیا صفحه از قبل از قبل ارائه شده است یا خیر. این مورد برای اسکریپت های شخص ثالثی که استفاده می کنید ، مانند اسکریپت های تبلیغاتی و ردیاب های آماری ، از اهمیت ویژه ای برخوردار است (Google Analytics قبلاً از Page Visual API استفاده می کند بنابراین دیگر نگران این موضوع نباشید). مدیریت نادرست این دارایی ها با استفاده از Page Visibility API دوباره خطر کج شدن معیارهای مهم را برای شما ایجاد می کند.
استفاده كردن پیش دستی و تسلیم کردن در محتوای صفحه ای احتمالاً یک پیاده سازی ایمن و مفید است - برای مثال در صفحه وب آموزشها که به چندین بخش تقسیم شده است. به خصوص در محتواهایی مانند آموزش ها ، احتمالاً مهم است که در مرزهای "جریان فکر بی وقفه" Nielsen باشد.
Google Analytics همچنین می تواند سرنخ های ارزشمندی راجع به اینکه کدام صفحات را می خواهید برای پیش نمایش / پیش فرض بخواهید ارائه دهد. با استفاده از Analytics در صفحه می توانید تعیین کنید که به احتمال زیاد روی کدام پیوند در صفحه اصلی شما کلیک شود. در برخی موارد با اقدامات عملیاتی بسیار تعریف شده ، این درصد ممکن است بسیار زیاد باشد - که آن را به یک گزینه عالی برای بارگیری مجدد تبدیل می کند.
هم پیش تنظیم و هم پیش پردازی کار با دامنه متقابل - موضوعی غیرمعمول لیبرال برای مرورگرها ، که معمولاً در دسترسی بین دامنه بسیار سختگیرانه عمل می کنند. با این حال ، این احتمالاً به نفع گوگل و موزیلا مفید است زیرا آنها از چندین طریق قادر به ایجاد تجربه مرور سریعتر برای کاربران خود هستند ، و از این نظر مزیت رقابتی قابل توجهی نسبت به سایر مرورگرهایی دارند که هنوز از چنین ویژگی هایی پشتیبانی نمی کنند.
واکشی مجدد و به ویژه پیش از راه اندازی ابزارهای قدرتمندی هستند که می توانند در بارگیری قابل درک صفحات وب پیشرفت های چشمگیری داشته باشند. اما مهم است که درک کنیم چگونه کار می کنند تا تجربه مرور کاربر شما مستقیم و منفی تحت تأثیر قرار نگیرد.
بارگیری محتوای آژاکس
روش دیگر برای بهبود زمان بارگذاری استفاده از Ajax برای بارگذاری محتوا است ، نه بارگیری مجدد کل صفحه - زیرا کارآمدتر این فقط بارگذاری تغییرات است ، نه دیگ بخار محتوا هر بار.
مشکلی که در بارگیری زیاد Ajax وجود دارد این است که می تواند مانند یک تجربه مرور غیر طبیعی احساس شود. اگر به درستی اجرا نشود ، دکمه های عقب و جلو مطابق انتظار کاربر کار نمی کنند ، و انجام کارهایی مانند نشانه گذاری صفحات یا تازه سازی صفحه نیز به طرز غیرمنتظره ای رفتار می کند. هنگام طراحی وب سایت ها توصیه می شود در رفتارهای سطح پایین مانند اینها تداخل نکنید - برای کاربران بسیار ناخوشایند و دوستانه نیست. نمونه بارز این تلاش ها برخی از وب سایت ها برای غیرفعال کردن کلیک راست بر روی صفحات وب خود به عنوان تلاش بیهوده برای جلوگیری از نقض حق چاپ است. اگرچه اجرای Ajax با همان هدف غیرفعال کردن کلیک راست ، بر عملکرد مرورگر تأثیر نمی گذارد ، اما تأثیرات آن مشابه است.
HTML5 راهی برای حل این مشکلات با History API دارد. در مرورگرها به خوبی پشتیبانی می شود (جدا از Internet Explorer ، اگرچه برنامه ریزی شده است که در IE10 پشتیبانی شود). با استفاده از API تاریخچه HTML5 ما می توانیم محتوا را با Ajax بارگذاری کنیم ، در حالی که همزمان تجربه مرور "عادی" را برای کاربران شبیه سازی می کنیم. در صورت استفاده صحیح از پشت ، دکمه های جلو و تازه سازی همه مطابق انتظار کار می کنند. URL نوار آدرس همچنین می تواند به روز شود ، به این معنی که نشانه گذاری اکنون دوباره به درستی کار می کند. اگر به درستی اجرا شود ، می توانید بارگیری مکرر منابع و همچنین داشتن پشتوانه های جذاب برای مرورگرهایی که JavaScript غیرفعال هستند را از بین ببرید.
یک نقطه ضعف بزرگ نیز وجود دارد: بسته به پیچیدگی و عملکرد سایتی که می خواهید ایجاد کنید ، اجرای بارگذاری محتوای Ajax با History API به روشی که برای کاربر نامرئی باشد دشوار است. اگر سایت از اسکریپت نویسی سمت سرور نیز استفاده می کند ، ممکن است دوبار هم بنویسید: یک بار در جاوا اسکریپت و دیگری روی سرور - که می تواند منجر به مشکلات تعمیر و نگهداری و ناسازگاری شود. کامل شدن آن ممکن است دشوار و زمانبر باشد ، اما اگر مطابق با هدف عمل کند ، می توانید بارهای واقعی و همچنین قابل درک برای کاربر را به میزان قابل توجهی کاهش دهید.
در تلاش برای بهبود سرعت سایت خود ممکن است با مشکلات غیر قابل حل روبرو شوید. همانطور که در ابتدای این مقاله ذکر شد ، مخفی نیست که Google از سرعت صفحه به عنوان معیار رتبه بندی استفاده می کند. این باید انگیزه قابل توجهی برای بهبود سرعت سایت شما باشد. با این حال ، ممکن است متوجه شوید که وقتی از منابعی مانند گزارش سرعت صفحه Google Webmaster Tools استفاده می کنید ، آنها زمان بارگیری کندتری را از آنچه انتظار دارید گزارش می کنند.
علت آن می تواند اسکریپت های شخص ثالث مانند دکمه های Facebook Like یا دکمه های Tweet باشد. این ها اغلب می توانند در منطقه صدها میلی ثانیه زمان انتظار داشته باشند که می تواند کل زمان بارگیری وب سایت شما را به میزان قابل توجهی پایین بیاورد. اما این بحثی برای حذف این اسکریپت ها نیست - داشتن دکمه های رسانه های اجتماعی در وب سایت خود احتمالاً مهمتر است. این دکمه ها معمولاً فضاهای نسبتاً کوچکی را در صفحه شما اشغال می کنند ، بنابراین به طور قابل توجهی بر زمان بارگیری بازدید کننده تأثیر نمی گذارد - این همان چیزی است که در هنگام انجام بهینه سازی سرعت باید در نظر داشته باشیم.
101 آموزش CSS و Javascript را در سایت خواهر ما ، Creative Bloq کشف کنید.
