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

ابزارهای زیادی برای بالابردن سرعت صفحات سایت تان وجود دارد. اما آیا می دانید این ابزارهای چگونه کار می‌کنند و اصلا آیا این ابزارها سرعت سایتتان را بالا می برند یا خیر؟!

پیج اسپید یک موضوع پیچیده است. بسیاری از مقالات لیستی از کارها یا افزونه ها را برای بالابردن سرعت سایت به شما معرفی می کنند.

این مقالات خوب هستند. با این حال همه سایت های مثل هم نیستند و نمی شود این توصیه ها را برای همه سایت ها اعمال کرد.

بنابراین، در این مقاله ما به شما توضیح می دهیم که سرعت سایت چگونه کار می کند و برای بالا بردن سرعت صفحات سایت چه اقداماتی باید انجام دهید.

در مقاله قبلی مستر وب درباره آموزش افزایش سرعت سایت صحبت کرده بودم.

اگر شما متخصص نیستید و فقط به دنبال نصب افزونه ای برای افزایش سرعت سایت تان هستید، ما در این مقاله چند افزونه را به شما معرفی کرده ایم:

wordpress

WP Rocket پولی + یک پلاگین بهینه سازی تصویر

یا

Autoptimize + یک پلاگین کش

Drupal

AdvAgg + یک ماژول بهینه سازی تصویر

اکنون بهتر است به موضوع اصلی مقاله بپردازیم. در این مقاله موضوعات زیر مورد بررسی قرار می گیرند:

1-سرعت صفحه (page speed) چیست ؟

2-چرا سرعت صفحه مهم است؟

3-سرعت لود شدن یک صفحه باید چقدر باشد؟

4-یک صفحه چطور ساخته می شود؟

5- ابزارهای تست سرعت سایت و آموزش استفاده از آن

6- تخمین اثر تغییرات

سرعت صفحه (page speed) چیست ؟

سرعت صفحه مقدار زمان بارگیری صفحه سایت است.

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

چرا سرعت صفحه مهم است؟

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

همچنین با اضافه کردن گزارش سرعت در سرچ کنسول گوگل و اعلام گوگل کروم مبنی بر علام سایت های کند به کاربران، سرعت صفحه بیش از پیش اهمیت پیدا می کند.

اما آیا می دانستید از سال 2010 سرعت صفحه، یکی از فاکتورهای سئو بوده است.

دلایلی وجود دارد که نشان می دهد شما باید به افزایش سرعت سایت اهمیت بدهید:

سرعت صفحه تجربه کاربری را تحت تاثیر قرار می دهد.

شما باید برای مخاطبانتان صفحه را سریع و نرم لود کنید. چرا که هر گونه تاخیر یا لگ روی اعمال بعدی آن ها در سایتتان تاثیرگذار است.

سرعت صفحه روی تحلیل های آماری سایتتان تاثیرگذار است.

به طور کلی، یک سایت سریع تر مخاطبین بیشتری را ترک می کند زیرا تگ های آنالتیکس یا دیگر ابزارها، زودتر لود می شوند.

اگر کاربری قبل از بارگذاری تگ سایت را ترک کند، بازدید او در سیستم انالتیکس ثبت نخواهد شد.

سئو؟ طبق اعلامیه رسمی، آپدیت مربوط به سرعت، تنها کندترین سایت‌ها را تحت تاثیر قرار می دهد .

مطالعات زیادی وجود دارد که نشان می دهد با افزایش سرعت سایت، ترافیک ارگانیک، نرخ کلیک بر روی تبلیغات داخل سایت، و به طور کلی بازدیدکنندگان سایت نیز افزایش می یابد.

WPO State مثال های تحقیقاتی زیادی درباره بهبود سرعت صفحه دارد.

با این وجود بسیاری از این مطالعات ممکن است اندکی گمراه کننده باشند.

بر اساس گفته گوگل، بهبود سرعت صفحه تاثیری روی رتبه بندی شما نخواهد داشت. مگر اینکه سایت واقعا کندی داشته باشید.

احتمالا می پرسید، اگر افزایش سرعت روی رنکینگ تاثیری ندارد، پس چرا بازدیدکنندگان سایت بیشتر می شوند؟

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

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

هیچ معیار رسمی خاصی برای سرعت صفحه وجود ندارد.

اما معمولا پیشنهاد می شود که  صفحه باید کمتر از 3 ثانیه بارگذاری شود.

این پیشنهاد شاید از اینجا استنباط شده که طبق یک تحقیق گوگل، 53% از بازدیدکنندگان موبایلی، صفحه ای که بارگذاری آن بیش از 3 ثانیه طول بکشد، ترک می کنند.

علاوه بر این این توصیه شاید مبتنی بر شاخص Speed Index است که بعدا درباره آن صحبت خواهیم کرد.

به عقیده ما گوگل هیچ معیار خاصی برای سرعت صفحه معین نکرده است.

چیزی که گوگل معمولا می گوید توصیه کلی است. مثل: سرعت سایت را برای کاربران بیشتر کنید یا تا جایی که می شود سرعت را بیشتر کنید.

یک صفحه چطور ساخته می شود؟

برای درک چگونگی بهبود سرعت صفحه می بایست بدانید چطور یک مرورگر صفحه را می سازد؟

برای این منظور، بیایید به چارت های Waterfall نگاهی بندازیم و ببینیم در زمان لود صفحه چه منابعی بارگذاری می شوند.

شما می توانید این روند را در زمان بارگذاری صفحه، با استفاده از راست کلیک و انتخاب گزینه inspect و رفتن در تب network مشاهده کنید.

تذکر: بیشتر تصاویر با استفاده از ابزار https://www.webpagetest.org به دست آمده است.

ایجاد کانکشن

رنگ سبز، نارنجی و بنفش، نشانگر زمان لازم برای برقراری ارتباط یا کانکشن با وب سایت است.

در ادامه هر رنگ به طور جداگانه بررسی خواهیم کرد.

چارت Waterfall برای قالب وردپرس 2020 از WebPageTest.org. موقعیت: Dulles, VA. دستگاه Moto G4. مرورگر: کروم. سرعت 3GSlow

DNS (سبز)

DNS دفتر تلفن وب است.

شما به مرورگر نام وب سایت می دهید و مرورگر برای گرفتن IP آدرس با یک سرور DNS ارتباط برقرار می کند.

DNS به مرورگر می گوید که سایت مورد نظر کجا میزبانی می شود. درست مثل دفتر تلفن که شما نام فرد را می دانید اما شماره تماس را نه.

بیشتر مواقع، DNS در جایی قرار دارد که دامنه را آنجا ثبت کرده‌اید و یا در جایی قرار دارد که CDN شما است.

دقت داشته باشید که همه ارائه‌ دهندگان DNS ها یکسان نیستند.

اگر یک میلی ثانیه هم برای شما مهم است، بهتر است از ارائه‌دهنده دیگری استفاده کنید.

طبق تحقیقات DNSPerf، سرعت پاسخ کلود فلر به طور متوسط 12.6 میلی ثانیه است.

این رقم برای GoDaddy عدد 46.04 میلی ثانیه است و برای Rackspace این رقم به 90.38 میلی ثانیه میرسد.

با این وجود این اعداد خیلی دقیق نیستند زیرا DNS را می توان هنگام مرور وب سایت از قبل بصورت موقت در مرورگر ذخیره کرد.

مقدار زمانی که DNS در مرورگر ذخیره می شود TTL نامیده می شود.

در زمانیکه کش فعال است، مرورگر برای اینکه بداند وب سایت کجا قرار گرفته، دیگر نیازی به اتصال به DNS ندارد.

اتصال(نارنجی)

این جایی است که مرورگر در حال برقراری ارتباط با سرور میزبان است.

پروتکل کنترل انتقال / پروتکل اینترنت (TCP / IP) پیچیده است اما شما فقط به نحوه کار فکر کنید.

احتمالاً یک خط مستقیم نیست. شما باید بچرخید، و مناطقی با ترافیک بالاتر وجود دارد.

حتی ممکن است مسیر را دوباره دنبال کنید یا چند چرخش اشتباهی انجام دهید.

این نوعی از چگونگی عملکرد آن است؛ این از مرورگر شما به سمت سرور حرکت می کند و برمی گردد .

دلایل زیادی برای طولانی شدن زمان اتصال وجود دارد.

در ارتباطات ناپایدار، از دست رفتن بسته ممکن است اتفاق بیفتد و بایستی مجددا ارسال شود.

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

چقدر باید از آن استفاده کرد؟ چقدر باید مسیر را طی کرد؟ ترافیک های دیگر روی سایت چقدر شبیه هستند و شما چندبار بایستی بچرخید؟

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

علاوه بر این، ظرفیت محدودکننده و اتصال بر روی سرور شبیه به یک تونل است که فقط به تعداد بسیار زیادی اتومبیل اجازه عبور در یک بازه زمانی را می دهد.

بسیاری از این موارد با کوتاه تر کردن فاصله با سرور و استفاده از مسیریابی هوشمندانه تر (که اکثر DNSها آن را انجام می دهند) قابل حل شدن است.

با داشتن یک شبکه از سرورها درسرتاسر دنیا، بازدیدکنندگان معمولا به سرورهای نزدیک متصل می شوند.

برخی ارائه دهندگان DNS معمولا مقادیر زیادی از درخواست های اینترنتی را مدیریت می کنند و می توانند ببینند در زمان واقعی کجا ترافیک وجود دارد.

اگر یک گزینه سریع تر ببینند، ترافیک را مجددا مسیردهی می کنند. دقیقا مانند کاری که GPS در ترافیک ها برای شما انجام می دهد.

لایه Secure Sockets (SSL) (بنفش)

برای سایت هایی که اتصال ایمن برقرار می کنند (HTTPS)، این جایی است که مرورگر و سرور بر روی نسخه پروتکل TLS (امنیت لایه انتقال)، ciphersuite (سطح امنیت) و تغییر تاییدیه (برای اطمینان از اینکه سایت همانی باشد که می گوید هست) توافق دارند.

شاید تصور کنید تنها با کمک HTTPS نتوانید سرعت سایت را بیشتر کنید.

این تقریبا صحیح است (حداقل برای بخش اتصال).

اما بودن بر روی HTTPS مزیت هایی دارد مثلا کرورگرها به شما اجازه استفاده از HTTP/2 (H2) بدون HTTPS را نمی دهند.

H2 دارای مزیت هایی از جمله اتصال مداوم است.

بنابراین لازم نیست اتصال جدیدی را برای فایل ها در همان سرور باز کنید.

هدرهای درون این درخواست ها نیز کوچک تر از HTTP/1.1 هستند و فایل های چندگانه می توانند همزمان منتقل شوند.

دربیشتر موارد، سایت هایی که از HTTPS استفاده می کنند سریع تر از سایت های بر روی HTTP هستند.

به طور کلی، مهم ترین دستاورد شما از بروزرسانی پروتکل (TLS 1.3 سریع تر از TLS 1.2 است) و اجرای امنیت انتقال محض HTTP (HSTS) ناشی می شود که همیشه به مرورگر می گوید از یک اتصال امن استفاده کند.

مرورگر درخواست هایی را از HTTP به HTTPS بدون نیاز به تماس با سرور و تغییر مسیر انجام می دهد.

در تصویر زیر، تغییر مسیر از HTTP به HTTPS و زمان لازم با استفاده از HSTS حذف می شود.

حتی شاید بخواهید برای اتصالات سریع تر از HTTP / 3 استفاده کنید. با این حال، پشتیبانی از این پروتکل هنوز در مراحل اولیه است، و حداقل در زمان نوشتن این مقاله احتمالاً هنوز گزینه مناسبی موجود نیست.

مهم: دستگاه، موقعیت و شبکه

فرض کنید اتصال به یک وب سایت در تلفن هوشمند میان رده با اتصال 3G 2 ثانیه طول می کشد. در همان تلفن با اتصال LTE، تقریبا 0.41 ثانیه کاهش می یابد.

در دسکتاپ با سرعت عادی، برقراری این ارتباط کمتر از 0.1 ثانیه است.

اگر زمان اتصال طولانی تر را مشاهده می کنید، به خاطر داشته باشید ممکن است زمان اتصال طولانی تری را تجربه کنید که ممکن است به دلیل پهنای باند محدود یا قدرت پردازش دستگاه تست باشد.

این عوامل همراه با حافظه پنهان مهم هستند.

آن ها می توانند به شما کمک کنند تا برای کسی که آخرین تلفن هوشمند خود را به WiFi متصل کرده است، با تمام پرونده های مورد نیاز برای بارگیری صفحه ای که قبلاً روی دستگاه خود ذخیره کرده اند (ما در این مورد در بخش دیگری صحبت خواهیم کرد) توضیح دهید روشی که آن ها تجربه می کنند.

تحت شرایط ایده آل است و اکثر افراد این شرایط را تجربه نمی کنند.

بارگیری و پردازش HTML

کد HTML یک صفحه همان چیزی است که در ابتدا توسط یک مرورگر بارگیری می شود.

این اطلاعاتی است که می توانید با کلیک راست بر روی یک وب سایت و رفتن به قسمت “View Page Source” مشاهده کنید.

پس از برقراری اتصال، مرورگر بیت اول اطلاعات را از سرور برگشت می دهد، ما به Time To First Byte (TTFB) می رسیم، که اندازه گیری معمولی برای زمان پاسخ اولیه است.

همانطور که در زیر خطوط نارنجی نشان داده شده است، این زمان از شروع درخواست HTML (آبی روشن) تا زمانی که HTML شروع به بارگیری می کند (آبی تیره) می باشد.

اگر تأخیری برای TTFB وجود داشته باشد، می تواند مربوط به کوئری دیتابیس، منابع سرور، انتظار برای تکمیل یک سرور جانبی (SSR) یا سایر مواردی که معمولاً در ایجاد محتوای پویا دخیل هستند، باشد.

زمان بارگیری به مواردی مانند اتصال و اندازه فایل بستگی دارد.

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

هنگامی که HTML بارگیری می شود، مرورگر آن را در Document Object Model DOM تجزیه می کند، یک کامپیوتر به این روش ساختار محتوا را درک می کند.

این فرآیند تجزیه از main thread مرورگر برای پردازش اقدامات کاربر و رنگ آمیزی صفحه، اجرای JavaScript و انجام چیدمان، بازگرداندن و جمع آوری زباله استفاده می کند.

در حال حاضر، فقط بدانید که این main thread وجود دارد و کارهای مختلفی را به عهده دارد. ما بعداً به این موضوع خواهیم پرداخت.

اگر بین HTML و درخواست بعدی فاصله ای بینید، محتمل ترین علت آن این است که CPU مشغول پردازش HTML برای ساخت DOM است.

از آنجا که دلیل آن CPU است، این موضوع مجددا به دستگاهی که استفاده می شود بستگی دارد، بنابراین می توانید با یک دستگاه قدرتمندتر تست کنید تا ببینید هنوز این شکاف وجود دارد یا خیر.

اگر از HTML و سایر فایل ها مانند CSS و JavaScript استفاده کنید، می توانید زمان را با استفاده از less code و کوچک سازی کاهش دهید تا کاراکترهای غیرضروری مانند نظرات و فضای سفید از کد حذف شوند، و فشرده سازی برای کاهش سایز فایل ها صورت گیرد.

نکته این است که بارگیری فایل را کوچک تر کنید تا این بخش از بارگذاری سریع تر شود.

با این حال، راه های زیادی برای کوچک و فشرده سازی وجود دارد.

در بسیاری موارد، این کار توسط CDN یا سرور (Apache یا Nginx سرورهای متداول هستند) یا توسط یک افزونه / ماژول /پکیج انجام می شود.

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

سابقا میزبانی منابع بر روی دامنه های cookelless که همان دامنه اصلی نبودند، بهترین راه حل بود، و گاهی اوقات استفاده از چندین دامنه (فرآیندی به نام domain sharding) به دلیل محدودیت های درخواست اتصال تعیین شده توسط مرورگرها، مزیتی داشت.

بدلیل آنکه HTTP / 2، بهترین روش نیست. در صورت امکان باید از همان سرور برای درخواست ها استفاده کنید.

به عنوان مثال، cdn.ahrefs.com را در نمودار Waterfall زیر قرار دهید.

اگر میزبان آن فایل، ahrefs.com باشد، نیازی به برقراری اتصال نیست… زمان برقراری اتصال DNS، اتصال، و مذاکره در مورد دستیابی امنیتی، با تأخیر انجام می شود. بدون حلقه های اضافی برای پرش، فایل زودتر در اختیار قرار خواهد گرفت، این بدان معنا است که این صفحه حتی سریع تر بارگیری می شود.

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

به عنوان مثال، اگر من از یک وب سایت بازدید کردم که یک فونت را از گوگل فونت نامیده است و سپس با همان فونت به وب سایت دیگری مراجعه کنم، ممکن است آن فایل را قبلاً در محلی ذخیره کرده باشم و مجبور نباشم دوباره آن را بارگیری کنم.

از Preconnect یا DNS-Preetch استفاده کنید (اگر از سرور دیگری استفاده می کنید)

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

این امر باعث می شود اتصال به سرور دیگر زودتر از حدمعمول انجام شود.

در زیرنشان دادیم چگونه یکی از اتصالات سایت آمازون حتی قبل از  پردازش HTML شروع می شود.

مثال کد:

<link rel=”preconnect” href=”https://site.com”>

اگر می خواهید آن بخش از اتصال را زودتر کنترل کنید، DNS-prefetch نیز وجود دارد.

قسمت سبز (DNS) زود متصل می شود، اما بقیه اتصال بعداً اتفاق می افتد.

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

بطورکلی، اگر می دانید چیزی از آن سرور باید برای کار کردن صفحه بارگذاری شود، پیش اتصال بهتر است.

با این وجود، از آنجا که اتصال مجدد به مسیریابی و امنیت بیشتری نیاز دارد (نارنجی و بنفش)، قرار است به زودی تمرکز منابع اندکی بیشتر باشد.

مثال کد:

<link rel=”dns-prefetch” href=”//asset1.com”>

مرورگرها چگونه یک صفحه را ارائه می دهند؟

قبل از ادامه و بحث در مورد گزینه های بهینه سازی، بهتر است کمی در مورد نحوه ارائه یک صفحه توسط مرورگر صحبت کنیم.

ما فایل های دیگری مانند CSS ،JavaScript ،Images و Fonts داریم که مرورگر آن ها را به همراه HTML به چیز مفیدی تبدیل کرده است.

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

این فرایند معمولاً مسیر حیاتی ارائه (Critical Rendering Path) نامیده می شود و این چنین به نظر می رسد:

1- HTML به درخت DOM (که قبلاً به آن اشاره کردیم) پردازش می شود.

2- CSS درون CSS Object Model (CSSOM) تجزیه می شود و به مرورگر می گوید چگونه همه چیز استایل شده، رنگی، اندازه گیری شده و … می باشد.

3- CSSOM + DOM با هم آنچه را Render Tree می نامند، ایجاد می کند.

4- چیدمان اتفاق می افتد، یعنی جاییکه هر عنصر بر اساس آنچه در Render Tree است، درون ویوپرت مرورگر قرار می گیرد.

5- پیکسل ها روی صفحه نمایش رنگ می شوند بنابراین به جای یک صفحه سفید، شما رنگ ها، اشکال، متن و تصاویر را می بینید.

نکته : یک واقعیت جالب که توسط مارتین اسپلیت از Google آشکار شد این است که Googlebot با نقاشی کردن پیکسل های یک صفحه باعث صرفه جویی در وقت و منابع می شود.

آن ها اطلاعات لازم را بعد از چیدمان در اختیار دارند.

هدف باید بدست آوردن عناصر مورد نیازدر اسرع وقت باشد تا بتوانیم نمای اولیه را با بیشترین سرعت ممکن بسازیم.

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

بیشترین تأثیر آن در بارگذاری منابع است.

این کار معمولاً بر عهده CMS یا JavaScript Framework است تا به مرورگر کمک کند زمان / چطوری / چگونگی بارگذاری منابع را الویت بندی کند تا سایت سریع تر نمایش داده شود.

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

گوگل برای این قسمت یک راهنمای متمرکز بر توسعه دهنده و یک راهنمای دیگر برای ساده کردن فرآیند نقاشی دارد.

معیارهای بارگذاری تصویری

First Paint (FP): مرورگر هرچیزی را برای اولین بار بارگذاری می کند.

First Contentful Paint (FCP): مرورگر چیزی را از DOM (Document Object Model) ارائه می دهد، که می تواند متن، تصویر و غیره باشد.

First Meaningful Paint (FMP): مهم ترین عناصر بصورت بصری بارگذاری می شوند.

Largest Contentful Paint (LCP): بزرگترین عنصر بالای دسته بارگذاری می شود.

Visually Complete: صفحه بصورت بصری بارگذاری می شود.

Speed Index: یک امتیاز محاسبه شده برای بارگذاری تصویری که چندین امتیاز دریک زمان  نظر می گیرد.

Cumulative Layout Shift (CLS): اندازه گیری مقدار عناصری که در هنگام بارگذاری در viewpoint حرکت می کند، یا چگونگی ثبات طرح.

دیدن بارگذاری بصری به همراه جدول waterfall

در بخش Summary در WebPageTest، اگرامکان ضبط را فعال کرده اید، باید یک ستون Video در جدول اصلی با “نمای فیلم(Filmstrip View)” داشته باشید.

در این نما، خط قرمز در بالا با اسنپ شات های بصری در همان نقطه ای است که خط قرمز در انتهای waterfall قرار دارد.

با حرکت خط قرمز به نقاط مختلف در بارگذاری تصویری، باید بتوانید آنچه که اخیراً در waterfall بارگیری شده است را جستجو کنید، که ممکن است به عناصر مختلف اجازه نمایش بصری دهد.

این می تواند به شما در تعیین اینکه چه فایل هایی برای اولویت بندی نیاز دارید، کمک کند.

به عنوان مثال، اگر می بینید که بیشتر صفحه شما به غیر از متن بارگیری شده است، اما بلافاصله پس از آن یک فونت بارگذاری شده و متن ظاهر می شود، این نشانه خوبی است که فونت برای نمایش متن لازم بود.

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

در پایین این نمودار اطلاعات اضافی مانند استفاده از CPU، پهنای باند، فعالیت در Browser Main Thread و تعامل وجود دارد.

همه این نمودارها دوباره به نوع دستگاه و نوع اتصال بستگی دارد.

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

به عنوان مثال، شاید بارگیری بیش از حد باشد، که پهنای باند را در بالاترین نقطه نگه می دارد.

یا شاید یک اسکریپت وجود دارد که از تمام CPU برای یک دستگاه خاص استفاده می کند، که می تواند باعث تاخیر شود.

Filetype CSS

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

بیشتر روش ها دارای تریدآف هایی هستند و بعضی از آن ها برای اجرای و نگهداری پیچیده تر هستند.

شما باید تصمیم بگیرید که در شرایطتان ساده ترین، سریع ترین و بهترین حالت را انتخاب کنید.

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

این بدان معناست که مجدداً بارگیری نمی شود، و بازدیدهای بعدی باید سریع تر باشند.

اکثر ابزارهای سرعت در اولین نگاه تست می شوند، بنابراین بیشتر چیزی که در ابزاری مانند PageSpeed Insights می بینید، نشان دهنده کاربر باراولی است که فقط یک صفحه را مشاهده می کند و نه کسی که به چندین صفحه مراجعه می کند یا اغلب به وب سایت شما مراجعه می کند.

هدف شما باید بهینه سازی این نمای اول و نمایش های بعدی برای کاربران باشد.

بارگیری CSS به صورت همزمان

شما می خواهید کد مهم را در اسرع وقت بارگذاری کنید، و ما چندنکته درباره آن به شما خواهیم گفت، اما بخش دیگر این است که شما می خواهید CSS مانع ارائه شود.

برای این منظور، می خواهیم استایل شیت هایی که بعدا در فرایند بارگذاری مورد نیاز است را بارگذاری کنیم و سپس آن را به همه اعمال کنیم.

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

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

بطور مثال این:

<link rel=”stylesheet” href=”/my.css”>

تبدیل می شود به:

<link rel=”stylesheet” href=”/my.css” media=”print” onload=”this.media=’all’”>

شما می توانید این را با همه منابع CSS  استفاده کنید.

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

بنابراین وقتی CSS اعمال می شود، صفحه ممکن است مکان و چگونگی نمایش موضوعات را تغییر دهد ..

Inline

Inline کد مورد نیاز برای رندر کردن محتوای بالاتر از دسته را دربر می گیرد و به جای یک فایل جداگانه، آن را با پاسخ HTML تحویل می دهد.

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

ساده ترین راه برای فکر کردن دراین مورد این است که شما در حال بدست آوردن قسمت های مهم فایل های CSS و JS هستید و مستقیما آن ها را درون HTML قرار می دهید.

بارگذاری HTML اولیه کمی طول می کشد، اما ارائه صفحه می تواند قبل از همه فایل های دانلود شده اتفاق بیفتد.

احتمالاً Inlining سریع ترین رندر را در بارگیری صفحه اولیه به شما میدهد، اما ترید آف ها به با ذخیره سازی همراه هستند.

کد بارگذاری شده در HTML نمی تواند از حافظه پنهان مجددا مورد استفاده قرار گیرد، بنابراین معمولاً مقداری از کد را دو بار بارگیری می کنید: یک بار با HTML و دوباره در فایل نرمال که به طور معمول ذخیره شده است.

اما اگر برای هر صفحه کد وارد کردید، این بدان معنی است که صفحات بعدی نیز کد اضافی دارند.

این یک روش پیشرفته است و مستلزم استفاده از پرسنل بخش خدمات است، اما شما می توانید هم inlining و هم حافظه پنهانی داشته باشید.

همراه با ساخت بقیه CSS، این یک حالت ایده آل است.

به یاد داشته باشید که می توانید کد CSS درون خطی را کوچک کنید.

همانطور که در بخش HTML در بالا ذکر شد، این کار باعث می شود برخی از فاصله های غیرضروری و کاراکترهای اضافی حذف شوند تا کد کوچک تر و سریع تر بارگیری شود.

احتمالاً نمی خواهید همه محتوا رادر تمام فایل ها بگنجانید.

فقط به محتوای مهم inline توجه داشته باشید.

می توانید تمام CSS و JS و حتی فونت ها و تصاویر را بصورت فنی بچسبانید، اما می خواهید با یک بارگیری عظیم HTML (که در آن بسیاری از کد استفاده نمی شود)، به پایان برسید.

این در واقع وب سایت شما را کندتر می کند. اگر چند فایل های کوچک چند کیلوبایتی دارید و می خواهید همه موارد را برای آن ها بگنجانید، این روش بسیار خوب است.

CSS های مهم inline در مقیاس

شما به جای اینکه این کار برای هر صفحه انجام دهید، یک سیستم خودکار می خواهید.

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

معمولا برای این کار برخی از افزونه ها / ماژول ها / پکیج ها یا نسخه هایی از Critical یا Critical CSS وجود دارد.

این پکیج ها برای هر کار taskrunner یا هر پکیجی که از آن ها استفاده می کنید مانند Grunt ،Gulp ،Webpack یا قالب هایی مانند React ،Angular،Vue وجود دارد و حتی می توانید آموزش های اختصاصی برای WordPress یا Drupal یا حتی صفحات دارای کد دستی نیز پیدا کنید.

آن ها قصد دارند یک مرورگر بدون سرصفحه را به صفحه ارسال کنند تا مشخص شود کدام CSS واقعا برای بارگذاری صفحه در اندازه های مختلف مهم است، یا کد را به شما می دهند یا کد را درون عناصر مهم و غیر مهم تقسیم می کند تا بتوانید آن ها را به طور مناسب بارگیری کنید.

چند مثال:

Grunt:

https://github.com/filamentgroup/grunt-criticalcss

https://www.npmjs.com/package/grunt-critical-css

https://github.com/bezoerb/grunt-critical

Gulp:

https://github.com/addyosmani/critical

https://www.npmjs.com/package/gulp-critical-css

Webpack:

https://github.com/anthonygore/html-critical-webpack-plugin

https://github.com/GoogleChromeLabs/critters

https://github.com/anthonygore/html-critical-webpack-plugin

https://www.npmjs.com/package/critical-css-webpack-plugin

React:

https://www.npmjs.com/package/react-critical-css

https://github.com/addyosmani/critical-path-css-tools

https://github.com/sergei-zelinsky/react-critical-css

Angular:

https://github.com/addyosmani/critical-path-angular-demo

Vue:

https://github.com/anthonygore/vue-cli-plugin-critical

https://vuejsdevelopers.com/2017/07/24/critical-css-webpack/

Drupal:

Use Gulp to automate your critical path CSS

WordPress:

https://joe-watkins.io/javascript/inline-critical-css-with-wordpress/

https://wordpress.org/plugins/wp-criticalcss/

Hand-coded:

https://www.sitelocity.com/critical-path-css-generator

https://jonassebastianohlsson.com/criticalpathcssgenerator/

Preload

اگر نمی خواهید CSS مهمی را بگنجانید، گزینه دیگر استفاده از Preload است.

Preload با گرفتن منابع لازم برای نمایش سریع تر صفحه، رکوئست را زودتر در بارگذاری می آورد.

Preload اولویت مرورگر را برای دارایی های از پیش بارگذاری شده به عنوان بالا تعیین می کند و آن ها را به صورت غیر همزمان بارگذاری می کند، بنابراین آن ها مانع رندرینگ نمی شوند.

این موضوع در دامنه ها هم صدق می کند.

مرورگر به هررکوئست برای یک فایل اولویت می دهد.

فایل های ضروری برای نمایش بالاتر از محتوای دسته، زودتر (در اولویت بالاتر) بدست اورید و مواردی غیرضروری در مراحل بعدی ارائه دهید.

اولویت داده شده به فایل ها را در تب شبکه در Chrome Dev Tools قابل مشاهده است. روی نوار راست کلیک کرده، گزینه Priority را انتخاب کرده و آن را به عنوان ستون اضافه کنید.

آنچه انجام خواهد داد اینست که فایلی را که بعداً بارگیری آن شروع شده است، بگیرید و در اسرع وقت بارگیری کنید.

مزیت دیگر این است اگر در جایی که فایل از قبل بارگذاری شده قبلا مسدود شده باشد، دیگر این مورد نخواهد بود.

علاوه بر آنچه در بالا برای ایجاد CSS async بیان شد، preload فقط خط دیگری را اضافه می کند که به معنی گرفتن سریع فایل توسط تنظیم کردن الویت مرورگر بالاتر از حد نرمال است.

این کار همچنین برای مرورگرهایی که از preload پشتیبانی نمی کنند نیز جواب می دهد.

مثال های کد:

<link rel=”preload” href=”/my.css” as=”style”>
<link rel=”stylesheet” href=”/my.css” media=”print” onload=”this.media=’all’”>

انتخاب فایل برای Preload

معمولا، شما می خواهید فایل موضوع اصلی را که حاوی مقدار زیادی CSS برای وب سایت است، داشته باشید.

Devs اغلب این را پس از تم نامگذاری می کند، یا آن را “style” می نامد، یا گاهی اوقات آن را بعد از خود وب سایت قرار می دهد.

اگر در شناسایی این فایل  مشکل دارید یا فکر می کنید که ممکن است سایر فایل ها نیز نیاز به بارگذاری مجدد داشته باشند، ساده ترین راه برای بررسی استفاده از ویژگی مسدود کردن درخواست در Chrome Dev Tools است.

برگه شبکه را باز کرده و یک صفحه را بارگیری کنید تا فایل های درخواست شده را ببینید.

برای افزودن آن ها به لیست بلاک می توانید بر روی این موارد راست کلیک کنید.

وقتی صفحه را بارگیری مجدد می کنید، اگر این صفحه هنوز نرمال به نظر می رسد، احتمالاً فایلی را که برای بالای دسته موردنیاز است، مسدود نکردید.

وقتی یکی از این موارد را دریافت می کنید که ظاهر صفحه را خراب می کند، این نشانه ای است برای ارائه محتوای بالای دسته و این فایلی است که می خواهید مجددا preload کنید.

آنچه که درباره preload باید بدانید:

1-شما نیاز به ossorigin روی قلم ها دارید یا یک لود دوبل از فایل را خواهید داشت.

2-شما هنوز به کال های فایل نرمال برای JS + CSS احتیاج دارید، بنابراین آن ها را حذف نکنید.

3-شما می توانید یک فونت را از قبل بارگذاری کنید حتی اگر به یک فایل دیگر مانند یک فایل CSS فراخوانی شود.

4-مراقب باشید که چقدر preload می کنید. با بارگیری بیش از حد بسیاری از فایل ها می توانید به مشکل بخوردید.

Server Push

این بخشی از مشخصات HTTP / 2 (H2) بود.

این به سرور اجازه می دهد فایل را بدون درخواست تحویل دهد. بنابراین به جای زنجیره ای که ممکن است HTML > CSS > Font باشد، به این سایت اجازه می دهد که بگوید من به آن فونت نیاز دارم، آن را ارسال کنید.

Server Push مشکل ساز است و من معمولاً آن را توصیه نمی کنم ، اما اگر شما یک توسعه دهنده عالی هستید یا به یکی از آن ها دسترسی دارید، می توانید از آن استفاده کنید این فایل ها را از سرور بر روی همان اتصال به عنوان رکوئست صفحه، درخواست می کند.

Server Push می تواند دارایی ها را دوبار بارگیری کند.

یک راه حل وجود دارد که از کوکی ها استفاده می کند و بررسی می کند که آیا قبلاً دارایی را به کاربران هدیه داده اید، اما این یک اجرای پیچیده است.

مشکل دیگر در ارتباط با اشکلات اتصال وجود دارد که مانع از بارگذاری فایل ها می شود.

با همه اقدامات اضافی، بازهم ممکن است دستاوردهای قابل توجهی درمقایسه با preload مشاهده نکنید، زیرا مرورگرها حافظه پنهان صفحه (که در آن preload است) را قبل از push cache بررسی می کنند.

Filetype JavaScript

جاوا اسکریپت پیچیده و دارای گزینه های زیادی است و ملاحظات زیادی را نیز در بر دارد.

بعضی اوقات از آن برای تأمین عملکرد استفاده می شود، گاهی از آن برای جلب محتوای اصلی استفاده می شود، و گاهی اوقات حتی برای ایجاد تغییراتی در CSS نیز استفاده می شود.

علاوه بر این، کد معین ممکن است به کد دیگری برای اجرای صحیح نیاز داشته باشد.

اینها به عنوان وابستگی (dependencies) شناخته می شوند و تغییر در نحوه بارگذاری جاوا اسکریپت احتمالا باعث شکستن برخی عملکردهای صفحه شود.

اگر جاوا اسکریپت نقش مهمی در محتوا یا استایل صفحه داشته باشد یا سیستم اصلی آن باشد مانند بسیاری از چارچوب های جاوا اسکریپت در این صورت بسیاری از  قوانین همانند آنچه CSS اعمال می کند برای inlining و preloading اعمال می شوند.

با این حال، شما گزینه Server Side Rendering (SSR) را نیز دارید.

این گزینه، کد را پردازش می کند و یک عکس فوری ارائه می دهد.

به عنوان مثال، اگر جاوا اسکریپت برای جمع آوری موارد در صفحه یا منو استفاده می شود، ممکن است بخواهید این اطلاعات را زودتر بارگذاری کنید و یا برخی از بار مرورگر مشتری را کاهش دهید، ممکن است بخواهید از یک راه حل SSR استفاده کنید.

ساده ترین روش برای اینکه بفهمید آیا JavaScript روی صفحه نیاز است یا خیر، کلیک بر روی padlock در Chrome و باز کردن تنظیمات سایت است.

لیستی از مجوزها را بر روی جاوا اسکریپت مشاهده خواهید کرد که می توانید به آن ها اجازه دهید یا آن ها را مسدود کنید.

مسدود کردن جاوا اسکریپت، بارگیری مجدد صفحه و مقایسه سایت با و بدون JavaScript باید به شما نشان دهد که آیا عناصر در صفحه گم شده اند یا نه.

اگر چیزی از دست رفته است، جاوا اسکریپت را دوباره فعال کنید و همان فرآیند مسدود کردن را (که برای CSS در بالا بیان کردیم) انجام دهید تا بفهمید کدام فایل ها برای محتوای ارائه شده اهمیت دارد.

حرکت به سمت Footer

برای اسکریپت های inline، احتمالا حرکت آن ها به سمت پایین صفحه را درنظر بگیرید .. به یاد داشته باشید که JavaScript در حال بلاک کردن تجزیه است، به این معنی که خواندن HTML را مسدود می کند.

انتقال این اسکریپت ها به پاورقی این اطمینان را می دهد که می توانید بسیاری از داده ها را قبل از هرگونه مسدودی پردازش کنید.

گزینه های دیگری برایرفرنس های اسکریپت دارید مانند defer و async که احتمالا بهتر هم هستند.

Defer/Async

Defer و Async ویژگی هایی هستند که می توانند به یک تگ اسکریپت اضافه شوند.

معمولاً اسکریپت در حال بارگذاری، تجزیه و تحلیل را هنگام دانلود و اجرای مسدود می کند.

Async به شما امکان می دهد تجزیه و بارگیری همزمان انجام شود اما در حین اجرای اسکریپت مسدود است.

Defer تجزیه و تحلیل را هنگام بارگیری مسدود نمی کند و فقط پس از پایان بررسی تجزیه HTML انجام می شود.

منبع:

https://www.growingwiththeweb.com/2014/02/async-vs-defer-attributes.html.

نمونه هایی از کد Defer/Async

Normal:

<script src=”https://www.domain.com/file.js”></script>

Async:

<script src=”https://www.domain.com/file.js” async></script>

Defer:

<script src=”https://www.domain.com/file.js” defer></script>

Addy Osmani عملکرد خوبی در مسدود کردن، async ،defer و preload و نحوه تأثیرگذاری بر اولویت های مرورگر دارد.

پاسخگویی(Responsiveness)

پاسخگویی معمولاً توسط First Input Delay (FID) اندازه گیری می شود، این زمان زمانی است که کاربر با صفحه شما در تعامل است تا زمانی که بتواند پاسخ دهد. Max Potential FID بدترین حالت FID است که ممکن است کاربران شما تجربه کنند.

بسیاری از افراد به طور معمول Time To Interactive (TTI) را اندازه می گیرند، یعنی مدت زمانیکه طول می کشد یک صفحه بطور کامل interactive شود.

به یاد داشته باشید مواردی که قبلاً به آنها اشاره کردیم در main thread درحال اتفاق افتادن بوده است یا خیر؟

بسیارخوب، فقط یک main thread وجود دارد، و جاوا اسکریپت برای این منابع رقابت می کند.

زمانیکه thread مسدود است، نمی تواند به ورودی کاربر پاسخ دهد.

بنابراین صفحه کند می شود. وقتی یک کاربر کلیک کند و صفحه هر اقدامی که کاربران سریعا درخواست کرده اند را انجام نمی دهد، کاربران احساس می کنند سرعت کند است.

هنگامی که این اتفاق می افتد، احتمالا کاربران این موضوع را به شما اطلاع می دهند. البته نه به روش خوب!

کاربران از سرعت کند اپلیکیشن توییتر شکایت می کنند.

JavaScript بر پاسخگویی تاثیر دارد. تمامی جاوا اسکریپت لود شده برای همه موارد مختلفی که می تواند انجام دهد باید در همان مکان اجرا شود.

تصویر بالا همان چیزی است که main thread به نظر می رسد.

این علائم قرمز رنگ در برگه عملکرد در Chrome Dev Tools نشان می دهد که احتمالا مشکلاتی وجود دارد.

معمولاً وظایفی که زمان زیادی برای اجرای main thread وجود دارد، پرچم گذاری می شوند.

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

منبع:

https://web.dev/long-tasks-devtools

در حال اجرای وظیفه، یک صفحه نمی تواند به ورودی کاربر پاسخ دهد.

این تاخیری است که احساس می شود. هرچه وضیفه طولانی تر باشد، تاخیر طولانی تر خواهد بود.

شکاف بین وظایف فرصتی است که در آن صفحه باید به وظیفه ورودی کاربر سوئیچ شود و به خواسته آن ها پاسخ دهد.

تگ های Third-party

این گزارش دیگری است که می توانید در PageSpeed Insights پیدا کنید.

این اندازه و مدت زمان اسکریپت های third-party را که درحال بلاک کردن main thread و تاثیرگذاری روی تعامل (interactivity) هستند را نشان می دهد.

توجه داشته باشید که، به ویژه در مورد تگ منیجرها، برخی موارد احتمالا مربوط به تگ منیجر است و نه اسکریپت.

این ممکن است بخشی از اسکریپت موجود در کانتینر باشد که برای یک تگ منیجر حساب می شود و به طور کامل بسمت third-party script حساب نمی شود.

از اندازه و زمان main thread استفاده کنید تا مشخص شود قادرید از شر چه چیزی خلاص شوید .. به یاد داشته باشید که بیشتر اسکریپت های third-party به نوعی قابلیت عملکرد، ردیابی یا هدف گذاری را اضافه می کنند، اما به ندرت برای عملکرد مناسب یک صفحه ضروری هستند.

از اختیارات خود استفاده کنید تا مشخص شود که آیا داده های به دست آمده ارزش بارگذاری اضافی برای این اسکریپت ها را دارند یا خیر.

منابع رایج JavaScript Bloat

Jquery

سیستم تست A/B

سیستم مانیتورینگ کاربر اصلی (RUM)

سیستم چت زنده

گزینه های Cleanup

1- از tracking/scripts کمتر استفاده کنید: این می تواند یک تصمیم سخت باشد زیرا مارکترها داده ها را دوست دارند، اما گاهی اوقات میزان داده های درحال جمع آوری پوچ است.

2- سیستم هایی که عملکرد مشابه دارند را تقویت کنید: مثلاً اگر در حال اجرای چندین سیستم آنالیز یا چندین سیستم که اطلاعات کاربر دارند هستید.

بسیاری از برنامه ها عملکردهای مختلفی دارند، و گاهی اوقات شما با اسکریپت هایی که عملکرد مشابه اسکریپت دیگر دارند به کار خود پایان می دهید (زمانیکه می توانید بدون یکی از آن ها کار کنید).

3- تقسیم بندی: به عنوان مثال، برخی از سیستم های تست A / B شما را مجبور به بارگذاری لیستی از تمام تست های موجود در سیستم می کند .. در بسیاری از مواقع می توانید براساس بخشی از سایت را بخش بندی کنید و نسخه های کوچکی از فایل را ایجاد کنید.

4- ردیابی سرور محور به جای مشتری محور: tradeoffs هایی با ردیابی این مسیر وچود دارند که من در اینجا به آن ها نمی پردازم. اما شما می توانید منابع زیادی درباره علت استفاده از یکی بر دیگری پیدا کنید.

5- از وب ورک ها برای حرکت دادن پردازش خارج از main thread استفاده کنید: نکته مهم انجام این کار اینست که وب ورکرها به DOM دسترسی نخواهد داشت.

این کار نسبتاً پیشرفته است و به توسعه دهندگان ماهر احتیاج دارد.

6- Service Workers / Edge Workers: من به آینده این  فناوری امیدوارم. در اصل این امکان را به JS می دهد که به جای مرورگر مشتری، در Edge (یا سطح CDN) اجرا شود.

بنابراین قبلاً برای یک سیستم تست A / B، ممکن است یک فایل بارگیری شود و سپس در مرورگر مشتری پردازش و اجرا شود.

از آنجا که این تست ممکن است قسمت هایی از DOM را بازنویسی کند و بعداً در بارگذاری رخ دهد، ممکن است با تغییر همه چیز، فلش های بصری را ببینید.

اکنون، می توانید تغییرات مورد نظر را  قبل از  پردازش ببینید و آن ها را با HTML که به ربات ها و کاربران تحویل داده شده است، تحویل دهید.

در حال حاضر برخی سیستم عامل ها از این مزیت استفاده می کنند.

7- به راحتی اجرای بارگذاری یک فایل را به تعویق بیندازید: اگر عجله ندارید یا فقط رکوئست فایل را براساس عملی مانند کلیک شروع می کنید.

به عنوان مثال، یک سیستم چت زنده احتمالاً در پنج ثانیه اول بارگیری صفحه، موردنیاز نیست، بنابراین آن را به تاخیر بیاندازید.

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

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

مزیت های JS Frameworks:

قالب های JavaScript مانند React ،Angular و Vue مزیت هایی نسبت به سیستم های سنتی دارند.

Tree shaking: فقط کد مورد استفاده در صفحه ارائه می شود. هر فایل یا کد دیگری که ضزوری نیست بارگیری نمی شود، بنابراین فایل های کوچک تر و صفحات کوچک تر می شود.

این کدی را که به طور سنتی برای هر صفحه دیگر موردنیاز است را از بین می برد.

تقسیم فایل ها به بخش های کوچک تر، بنابراین فرصت های بیشتری برای تعامل وجود دارد.

به عنوان مثال، شما یک فایل 1MB JS دارید که به عنوان یک وظیفه طولانی در main thread  اجرا می شود و تعامل را در حین اجرای آن مسدود می کند.

شما می توانید آن را به بخش های 50KB تقسیم کنید تا انجام وظیفه طولانی نشود، و فاصله های بیشتری بین دوره کوتاه تری که یک صفحه بتواند به ورودی کاربر پاسخ دهد، وجود داشته باشد.

فونت های Filetype

با فونت ها، شما گزینه های بسیاری از همان گزینه هایی را که قبلاً ذکر کردیم (به عنوان مثال، وارد کردن یا پیش بارگذاری یک فونت مورد نیاز) دارید.

اگر می خواهید آن مسیر را طی کنید، نمونه هایی از کد را برای بارگیری مجدد فونت ها پیدا خواهید کرد.

با این حال، با فونت ها، توصیه من  استفاده از صفحه نمایش فونت است: swap؛ که تا زمانی که قلم سفارشی آماده شود، به سادگی از یک فونت سیستم پیش فرض استفاده می کند و سپس به فونت سفارشی تبدیل می شود.

انجام این کار در استایل شیت شما بسیار ساده است.

@font-face {

 font-family: ‘Whatever’;

 font-display: swap;

اگر از فونت های Google استفاده می کنید، اینکار ساده ترهم می شود.

تنها کاری که باید انجام دهید اضافه کردن و نمایش=swap به عنوان یک پارامتر در URL است.

<link href=”https://fonts.googleapis.com/css?family=Whatever&display=swap” rel=”stylesheet”>

تصاویر Filetype

نگرانی اصلی در مورد تصاویر اندازه و وزن آن ها است.

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

تصاویر  به طورغیر همزمان بارگیری می شوند، بنابراین نمی توانند بار صفحه را مسدود کنند، اما می توانند به وزن و زمان کلی تعامل اضافه کنند.

مسئله دیگر اولویت بندی است، جایی که احتمالا برخی از تصاویر به درستی اولویت بندی شوند یا قبل از فایل های مهم مانند CSS و JS الویت بندی شوند.

بسیاری از مواردی که ما در مورد آن ها صحبت کرده ایم، مانند inline و preload را می توان برای تصاویر استفاده کرد اما با همان trade-offs ها مانند حافظه کچینگ یا پیچیدگی.

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

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

همیشه بهینه سازی تصویر را به روشی مقیاس پذیر انجام دهید.

گزینه های زیادی برای انجام این کار در سطوح مختلف مانند CDN، سرور، توسط CMS، با API و غیره وجود دارد.

در اینجا چند گزینه وجود دارد:

بهینه سازی تصویر CDNs:

Akamai Image Manager

imgix

Image Engine

Cloudinary

Uploadcare

بهینه سازی تصویر APIs:

ShortPixel

Fastly Image Optimizer

Kraken.io

TinyPNG

Imagify

GUI:

ImageOptim

Squoosh

Command Line: در صورت استفاده از صفحات وب ، gulp یا grunt ، Imagem دارای ماژول npm است

JPEG:

Guetzli

MozJPEG

PNG:

pngquant

Zopfli

GIF:

Gifsicle

SVGO

WordPress/Drupal

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

Lazy Load Images

اگر کسی به شما گفته است که باید “تصاویر offscreen” را به تعویق بیاندازید، این همان چیزی است که شما نیاز دارید.

اساساً این به تاخیر انداختن بارگذاری تصاویری است که در بالای دسته قرار ندارند زیرا هنوز ضروری نیستند.

هنگامی که کاربر شروع به پیمایش کرد، تصاویر بارگیری می شوند.

من ممکن است بگویم شما کتابخانه ای که از IntersectionObserver استفاده می کند را می خواهید اما به دلیل پشتیبانی از مرورگر احتمالاً دارای یک منبع تغذیه است.

محبوب ترین کتابخانه برای این مورد lazysizes ها هستند، اما گزینه های بسیاری برای ست آپ خود پیدا خواهید کرد.

از نظر کروم 76، بارگذاری lazy در مرورگر وارد شده است.

من انتظار دارم مرورگرهای بیشتری نیز به زودی این کار را انجام دهند، اما فعلاً  بخواهیم از این روش برای Chrome با polyfill برای سایر مرورگرها استفاده کنیم. وردپرس بارگیری lazy را به طور پیش فرض در نسخه 5.4 اضافه کرده است.

تصاویر Responsive/Resized

این  قضیه در مورد ارائه تصویر مناسب برای صفحه مناسب است.

بارگیری یک تصویر بزرگ و سپس کاهش اندازه آن، وقت و منابع را هدر می دهد.

برای این کار راه حل های خودکار زیادی وجود دارد.

به عنوان مثال، بسیاری از CDN ها به آن رسیدگی می کنند، و همچنین مواردی مانند پکیج  npm، ابزار ImageMagick CLI یا افزونه ها / ماژول های مختلف برای سیستم های مختلف وجود دارد.

قالب های تصویر درحال تغییر

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

شما یا باید تشخیص و تعویض زیادی انجام دهید یا از خدماتی استفاده کنید که این کار را برای شما انجام دهد. راهنماهای زیادی برای این کار  وجود دارد.

وزن و اندازه صفحه

این اندازه تمام منابع ترکیبی است.

صفحات کوچک تر سریع تر هستند. ما قبلاً در مورد بسیاری از بهینه سازی ها مانند کوچک سازی، فشرده سازی، و به سادگی خلاص شدن از شر هر چیزی که مورد استفاده نیست، صحبت کرده ایم.

هرچه صفحه ای که بار اول لود می شود کوچک تر باشد، سریع تر نمایش داده می شود.

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

بعد از آن می توانید سایر اطلاعات مورد نیاز را در صفحه بارگیری کنی، همه اینها زمانی اتفاق می افتد که همه چیز را تا حد ممکن کوچک نگه دارید.

مشکلات معمولاً از طریق کد، تصاویر و کلیات وب سایت های مرتبط با عملکرد یا ابزارها رخ می دهند.

فرصت های دیگر عملکرد وب

گزینه های زیادی برای بهبود سرعت صفحه سایت تان وجود دارد. من می خواهم موارد مهم دیگری را پوشش دهم، اما فرصت های بسیار زیادی وجود دارد زیرا سرعت صفحه موضوعی پیچیده است.

کچینگ (cache)

کچینیک نسخه ذخیره شده از یک فایل است. بدون نیاز به بارگیری مجدد آن ها، می توانید از فایلهای ذخیره شده در صفحه بعد مجددا استفاده کنید.

Server Cache

این جایی است که مرورگر به آن ها ریکوئست می دهد و پرونده ها ایجاد می شوند.

در حالت ایده آل، می خواهید به نزدیکترین cache به کاربر ضربه بزنید.

یعنی این cache ها می توانند در سطوح مختلف زیادی با TTL های متنوع برای هر کدام که باعث انقضا cache است، ذخیره شوند.

بین ذخیره سازی برای دوره های طولانی تر و بروزرسانی سریع محتوا با تغییرات، تعادل وجود دارد.

این موضوع خیلی ساده نیست زیرا می توانید هنگام بروزرسانی، cache را از طریق لایه های مختلف پاک کنید، که این روش ایده آل برایاین کار به همراه سیستم گرمایش cache است.

سیستم های گرمایش cache بجای اینکه منتظر یک کاربر برای درخواست فایل باشند، یک ربات ارسال می کنند، به این معنی که کاربر هرگز مجبور نیست منتظر بماند که cache اولیه ساخته شود.

یک بررسی معمولاً شبیه موارد زیر است: CDN cache > Server cache (like Varnish) > Origin  (باید صفحه را در fly بسازد).

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

به عنوان مثال، در یکی از سایت های من در Cloudflare که در زیر نشان داده شده است، من برای سطح CDN کمی بیشتر از 50٪ حافظه نهان دارم.

متأسفانه، این بدان معناست که بسیاری از درخواست ها توسط CDN ارائه نمی شوند و باید به حافظه نهان سطح سرور برگردند.

یا اگر نسخه حافظه پنهان فعلی در آنجا وجود ندارد، مجبور است صفحه را در fly بسازد، که از منابع پایگاه داده زیادی استفاده می کند و برای یک کاربر کندتر خواهد بود.

Browser Cache

حتی اگر یک وب سایت بزرگ دارید که سرعت آن را ضعیف است، می توان تفاوت  قابل توچهی بین بارگذاری دفعه اول و دوم یک صفحه یا navigation بین صفحات وجود داشته باشد بسیاری از مواردی که تاکنون در مورد آن صحبت کرده ایم روی سریع تر کردن بارگذاری اولیه متمرکز است.

این همان چیزی است که اکثر ابزارهای آزمایشی اولین تصور کاربر از وب سایت شما را مشاهده می کنند.

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

به عنوان مثال، به اختلاف بین لود شدن دفعه اول و دوم را برای سایت Ahrefs نگاهی بیندازید.

بیشتر فایل ها که باید بار اول بارگیری شوند در سمت مشتری (مرورگر) ذخیره می شوند، به این معنی که در لودشدن دوم فقط می توان از مواردی که قبلاً بارگیری شده اند برای ساخت صفحه استفاده کنید.

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

در این حالت، First Paint تقریباً دو برابر سریع تر از بارگذاری دوم رخ می دهد.

بارگذاری اول

بارگذاری دوم

موارد کچینگ پرچم گذاری شده در ابزارهایی مانند Lighthouse به عنوان “سرویس دهی به دارایی آماری با یک سیاست  ذخیره کارآمد” قابل مشاهده خواهد بود. تعیین مدت زمان حافظه پنهان براساس سیستم متفاوت است، اما به طور کلی، آنچه باید انجام دهید، استفاده از یک هدر پاسخ Cache-Control HTTP است.

حداکثر سن، زمانی است که می خواهید آن را در چند ثانیه ذخیره کنید و می تواند به اینصورت تنظیم شود:

Cache-Control: max-age = 31536000

تنظیم بودجه (احتمالی) عملکرد

بودجه عملکرد مجموعه ای از محدودیت های تحمیل شده بر معیارهایی است که بر عملکرد تأثیر می گذارد.

این می تواند مواردی مانند اندازه، تعداد نوع خاصی از فایل ها یا برخی از معیارهای سرعتی باشد که در مورد آن ها صحبت کرده ایم.

تعیین بودجه می تواند به شروع گفتگو کمک کند.

بارگذاری تطبیقی (Adaptive Loading)

بارگذاری تطبیقی، آنچه بارگذاری شده است را تنظیم می کند و زمان سایت ها را در نحوه بارگیری آن ها پیشرفته تر می کند.

ابتدا ویژگی ها و عملکردهای اولویت بندی بارگیری می شوند و بقیه بر اساس چیزهایی مانند CPU، حافظه یا سرعت شبکه بارگیری می شوند.

بنابراین، داشتن منابع کمتر به این معنی است که احتمالا نسخه  stripped-down (سلب شده )  شده سایت، تحویل داده شود ، اما افرادی که منابع بیشتری در دسترس دارند ، کل تجربه را بدست می آورند.

بخشی از این برنامه اطلاعات شبکه API است که اطلاعاتی در مورد اتصال کاربر به شما ارائه می دهد.

شما می توانید تصاویر یا محتوای خود را تغییر داده و یا کارهایی مانند خاموش کردن ویدئو ها بر اساس اطلاعات شبکه رکوئست ورودی انجام دهید.

بسیاری از CDN های تصویر این کار را به کمک  اطلاعات شبکه API انجام می دهند.

از نکات منابع دیگر استفاده کنید

Prefetch(مقدمه)

prefetch یک منبع hint است که قبل ازاینکه ضرورت پیدا کند، فایل را دریافت می کند.

این می تواند برای کل صفحات، اسکریپت ها یا فایل های CSS باشد.

یکی از بهترین راه ها استفاده از  Guess.js است که از prefetching پیش بینی استفاده می کند.

فرض کنید به Analytics متصل است و بر اساس رفتار کاربر فعلی، به احتمال زیاد به صفحه بعدی می روید.

Preload

قبلاً در مورد preload.صحبت کرده ایم، اما این یک مورد متفاوت است.

می توانید منابع را براساس مواردی مانند اینکه کاربر موس خود را روی یک لینک یا لینک هایی درون viewport فعلی حرکت می دهد، از قبل بارگذاری کنید.

اگرچه این می تواند تا حدی روی منابع متمرکز باشد، اما سرعت بیشتر بارگذاری صفحه بارگذاری شده بعدی را تضمین می کند.

AMP

AMP در SERP از قبل بارگیری می شود، بنابراین بخشی از سایت، قبل از کلیک بارگیری می شود.

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

AMP هنگام رسیدن به نتایج جستجو سریع تر از صفحات وب عادی به نظر می رسد زیرا قسمت قابل مشاهده صفحه در حال بارگیری است.

منبع :

https://www.ampproject.org/latest/blog/why-amp-caches-exist/

بسیاری از بهبود عملکرد و محدودیت اندازه فایل در AMP وجود دارد که آن را ارزشمند می کند.

با این وجود، این یک سیستم دیگر برای نگهداری است و برخی از tradeoffs های دیگر که احتمالاً می خواهید قبل از دایوینگ شدن به آن بپردازید، دارد.

تست سرعت صفحه و ابزارها

Lab Data vs. Field Data

Lab Data: ویژگی ها یک محیط کنترل شده، فرایند تکرار شونده و کنترل تنظیمات است.

PageSpeed Insights یک مثال عالی است. این تست در یک محیط با همان تنظیمات انجام می شود و نتایج تقریباً یکسان خواهد بود.

Field Data

مانیتورینگ واقعی کاربر (RUM) نحوه تجربه کاربران صفحه است.

همه چیز مانند کچینگ، دستگاه ها، شبکه ها و غیره را در نظر می گیرد، اما در معیارها و امکان اشکال زدایی محدود است.

نکته: مراقب باشید که چه مدت از ابزار واقعی Monitor Monitor (RUM) که به شما امکان جمع آوری داده های زمینه را می دهد، استفاده می کنید.

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

هدف شما این است که سرعت سایت بیشتر شود و این ابزارها در تشخیص مشکلات مفید هستند، نادیده گرفتن آن ها می تواند باعث کندتر شدن صفحات شما شود.

ابزارهایی برای اندازه گیری سرعت سایت

ابزارهای گوگل

TestMySite: دارای کارت امتیازی با سرعت است که می توانید سرعت خود را با رقبا ارزیابی کنید، یک ماشین حساب تأثیر دارد بنابراین می توانید سرعت تأثیر در کسب و کار خود را تخمین بزنید، و به شما امکان می دهد گزارشی تهیه کنید که شامل این موارد و برخی از توصیه ها باشد.

Lighthouse (در ابزارهای Chrome Dev) – امکان تست عملکرد صفحات و برنامه ها را می دهد.

PageSpeed Insights- Lighthouse را اجرا می کند و توصیه هایی را ارائه می دهد.

اجرای Lighthouse در مرورگر شما تحت تأثیر موارد زیادی مانند رایانه، شبکه شما، برنامه های افزودنی در مرورگر شما، و غیره قرار می گیرد.

PageSpeed Insights: یک محیط تست نسبتاً پایدار را فراهم می کند که حتی از منابع سرورتان مانند Lighthouse در تنظیم مقیاس استفاده نمی کند.

Chrome Dev Tools: بسیاری از ویژگی های مفید برای دیدن چه چیزی و چگونگی بارگذاری یک صفحه مانند تب های شبکه و عملکرد را دارد.

Chrome User Experience Report (CrUX): یک دیتابیس عمومی از داده های تجربه کاربر واقعی برای کسانی است که قصد اشتراک گذاری در Chrome را دارند و میلیون ها نفر را پوشش می دهد.

Field Data (داده های کاربران واقعی) برای سرعت صفحه.

Web.dev: یکی دیگر از ابزارهای تست Google با پشتیبانی Lighthouse است.

دارای بخشی برای کسب اطلاعات بیشتر در مورد سرعت صفحه است.

سایر ابزار های شناخته شده :

WebPageTest

Sitespeed.io

SpeedCurve

Calibre

Rigor

New Relic

Boomerang

Batch Speed

GTmetrix

Pingdom

SpeedMonitor.io

Site Audit > Performance

ابزار Ahrefs’ Site Audit اطلاعاتی در مورد سرعت صفحه دارد.

یک گزارش درباره  TTFB و زمان  بارگذاری وجود دارد، که نشان می دهد دانلود صفحه چقدر طول کشیده است.

پیشنهاد من ابزارهای زیر است :

Pagespeed Insights: چک کردن صفحات فردی. من API آن ها را دوست دارم. این امکان تست های 25 کیلو در روز را بدون هزینه را به شما می دهد و معیارهای زیادی از جمله داده

های CrUX page-level  را به شما باز می گرداند. من به نمره کلی توجه زیادی نمی کنم، اما بسیاری از افراد روی این معیار تمرکز می کنند.

همانطور که مشاهده کردیم، سرعت مقوله پیچیده ای است، و ممکن است شما در برخی از معیارها بهبود پیدا کنید، این در حالی است که به شما هیچ کمکی در نمراه تان نمی کند زیرا وزن زیادی دارد.

WebPageTest: عملکرد بلاک کردن، filmstrips، ویدئو، waterfall و نقشه رکوئست ونیز API آن ها برای مسدود شدن در تست مقیاس (به مراه گزارشات lighthouse).

GTmetrix: گزارش درخواست های زنجیر شده

CrUX: تحقیقات منطقه، هیستوگرام، مقایسه رقبا.

Web.dev: مستندات عالی است.

گوگل از چه داده هایی برای سرعت صفحه استفاده می کند؟

طبق گفته جان مولر وبمستر Trends Analyst گوگل در این ویدیو: گوگل از سرعت تئوری یک صفحه (با استفاده از lab data) و داده های میدانی واقعی از کاربرانی که درحال استفاده از صفحات هستند، استفاده می کنند.

او می گوید این شبیه به داده های گزارش تجربه کاربری Chrome است.

درحقیقت  هیچ تأیید عمومی از منبع داده های مورد استفاده آن ها وجود نداشته است.

جان نمی گوید که آن ها از داده های PageSpeed Insights و CrUX استفاده می کنند، بلکه معتقد است داده های این اطلاعات احتمالاً نمایانگر داده هایی است که توسط Google استفاده می شود.

حدس من این است که آن ها از اقدامات انجام شده در طی مراحل ارائه خود به عنوان lab data استفاده می کنند (به طور بالقوه بوسیه lighthouse، اما شاید این طور نباشد)، و آن ها به احتمال زیاد یک منبع داخلی مشابه CrUX دارند که از آن ها برای داده های میدانی استفاده می کنند.

ارزیابی تاثیر تغییرات

ساده ترین روش برای ارزیابی تأثیر، تهیه یک نسخه استاتیک از یک صفحه است.

کد را در سرور خود کپی کنید و صفحه را تست کنید تا یک متریک پایه دریافت کنید.

تغییراتی در صفحه ایجاد کنید و دوباره تست کنید.

باید تأثیر تقریبی تغییرات را بدست آورید، تا زمانی که آنها را در سایت زنده خود قرار می دهید، تاثیر تقریبی اش را بدانید.

سخن پایانی

شما باید سایت خود را در اسرع وقت برای کاربران بسازید.

معیارهایی را انتخاب کنید که نشان می دهد چگونه کاربر بارگذاری و تعامل صفحه را تجربه کند و آن ها را بهبود ببخشید.

واقعاً مرزی برای رساندن سرعت صفحه به آن نقطه وجود ندارد.

اما اغلب مرحله ای وجود دارد که مزیت ارزش وقت، تلاش، هزینه و یا tradeoffs های بالقوه را ندارد (مانند از دست دادن داده های یک ابزار).

به طور کلی، من تلاش می کنم از رقبا اندکی سریع تر باشم.