در این مقاله که پیش روی شما بازدید کننده گرامی هست ما به عنوان گروه وب سما ( یکی از گروه های فعالیت در حوزه توسعه وب سایت های اینترنتی ) ، ابتدا استانداردهای جهانی با معیارهای ( TTFB ( Time to First Byte و Visual Complete and Fully Loaded ایجاد کردیم ( روشی که با آن اولین بایت لود شدن سایت و در بخش بعدی کامل بارگزاری شدن یک صفحه از سایت بررسی و تحلیل می گردد ). سپس، چگونگی فشرده سازی تصویر، CDN ها و سرعت بارگزاری اطلاعات از هاست را برای سرعت صفحه با آنالیز ۵.۲ میلیون صفحه وب سایت را بررسی کردیم.
داده های به دست آمده در بررسی سرعت صفحه با آنالیز ۵.۲ میلیون صفحه وب سایت در این تحقیق و بررسی بدست آمده، چشم اندازهای بسیار جالب و شگفت آوری را برای ما و شما عزیزان طراح و توسعه دهنده وب سایت آشکار ساختند.
فهرست مطالب قرار گرفته در این مقاله
در این بخش ابتدا خلاصه ای از یافته های کلیدی ما آورده شده است :
1. در تجزیه و تحلیل ما از 5.2 میلیون صفحه، میانگین سرعت TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML )، 1.286 ثانیه در دسکتاپ و 2.594 ثانیه در موبایل است. میانگین زمان لازم برای بارگیری کامل یک صفحه وب 10.3 ثانیه در دسکتاپ و 27.3 ثانیه در موبایل است.
2. به طور متوسط بارگیری صفحه وب روی موبایل در مقابل بارگیری صفحه وب روی دسکتاپ، 87.84٪ بیشتر طول می کشد( سرعت بارگیری صفحه ها در دسکتاپ سریع تر می باشد ) .
3. هنگام مقایسه CMS های اصلی با یکدیگر( برترین cms های موجود که در بازار توسعه وب سایت دنیا مورد استفاده قرار می گیرد) ، Squarespace و Weebly بهترین عملکرد سرعت صفحه ( سایت ) روی موبایل را دارند. Wix و WordPress ( وردپرس که یکی از پرکاربردترین cms های مورد استفاده در بازار جهانی و حتی ایران با داشتن قالب های متفاوت وردپرسی و افزونه های زیادی میباشد ) در رتبه بندی پایین تری از این 2 cms قرار گرفتند.
4. در این بررسی سرعت لود سایت در دسکتاپ استفاده از CDN سی دی ان ها بیشترین تأثیر را روی TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) دارند. با این حال، به نظر می رسد در دستگاه های تلفن همراه، تعداد درخواست های HTML بیشترین تأثیر را بر TTFB دارند.
5. اندازه كل صفحه ، تأثير به سزايي در سرعت بارگزاري Visually Complete ( کاربر می تواند تمام ظاهر صفحه را مشاهده کند ) در دسکتاپ و موبایل دارد. صفحات بزرگتر برای بارگیری کامل 318٪ بیشتر از صفحات کوچکتر در سرعت بارگزاري طول می کشد. همچنین طی بررسی های گروه وب سما ، به این نتیجه رسیدیم که فشرده سازی gzip به تصاویر کمک می کند تا با سرعت بیشتری در دسکتاپ و موبایل در صفحات وب سایت بارگزاری شوند.
6. حجم کل صفحه ، تعیین کننده شماره 1 در سرعت کامل بارگیری صفحه است. صفحات کوچک 486٪ سریعتر از صفحات بزرگ بارگیری می شوند.
7. Wink and Gatsby از سریعترین فریم ورک های جاوا اسکریپت ( Javascript frameworks ) مورد بررسی قرار گرفته هستند. Meteor و Tweenmax هم کمترین سرعت را در فریم ورک های جاوا اسکریپت ( Javascript frameworks ) دارند. سریعترین فریم ورک ها ( وینک و گتسبی Wink and Gatsby ) دویست و سیزده درصد 213٪ سریعتر از کندترین فریم ورک ها (تویین مکس و متوور Meteor و Tweenmax ) می باشند.
8. صفحاتی با فشرده سازی فایل بسیار کم یا بسیار بالا دارای عملکرد سرعت صفحه، متوسطی هستند ( اندازه گیری شده از طریق اولین محتوای رنگی در متن صفحه )
9. اسکریپت های Third-party ، سرعت بارگیری صفحه را به میزان قابل توجهی کاهش می دهد. هر اسکریپت Third-party که به یک صفحه اضافه می شود ، زمان بارگیری صفحه را 34.1 میلی ثانیه افزایش می دهد.
10. ما متوجه شدیم با استفاده از تصاویر ریسپانسیو ( واکنش گرا در هر اندازه از صفحه و سخت افزار مختلف مانند موبایل یا تبلت و دسکتاپ ) ، نتایج بهتری در عملکرد بارگیری تصاویر در صفحات به دست می آید. استفاده از فرمت WebP ( فرمت تصویری گوگل با فشرده سازی بالا )، کاهش زمان بارگیری در صفحات را به طور قابل توجهی کمتر می کند.
11. میزبان وب ( توسعه دهنده و خدمات دهنده وب ) GitHub و Weebly سریعترین عملکرد در TTFB را دارند. Siteground و Wix کندترین عملکرد در بین ارائه دهندگان میزبانی هستند که ما آنالیز کردیم.
12. در بین کشورهای مورد بررسی در این مقاله توسط گروه وب سما چین ، ژاپن و آلمان سریعترین زمان بارگذاری TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) را دارند. استرالیا، هند و برزیل کمترین زمان بارگزاری TTFB را دارند.
13. استفاده از CDN با عملکرد پایین همانند عملکرد سرعت صفحه بد برای یک سایت است. این به احتمال زیاد به این دلیل است که CDN های خاص عملکرد بهتری از سایرین CDN ها دارند.
معیارهای اندازه گیری زمان بارگزاری سرعت صفحه اصلی
در این مقاله اولین و مهمترین کار ما ایجاد معیارهایی برای اندازه گیری سرعت صفحه می باشد.
همانطور که می دانید ، “سرعت صفحه“ در واقع از چندین مرحله (پارامترهای ثابت در سرعت یک صفحه ) مشخص تشکیل شده است.
برخی از این مراحل در سطح سرور ( عملیاتی که در بخش سرور وب سایت شما انجام می گردد ) اتفاق می افتد. و دیگر مراحل در مرورگر کاربر انجام می شوند.
و برای درک کامل چگونگی سرعت بارگیری صفحات، لازم است که هر یک از این مرحله ها را که در تصویر بالا گفته شده است بررسی کنیم.
به طور مشخص، ما میانگین سرعت را برای مراحل زیر تعیین کرده و برای تمامی وب سایتها بررسی نمودیم :
1. TTFB : زمان خواندن اولین بایت از درخواست پرونده HTML
2. StartRender : لحظه ای که مرورگر کاربر شروع به نمایش محتوا می کند.
3. Visual Compl3ete : کاربر می تواند تمام ظاهر صفحه را مشاهده کند.
4. Speed Index : شاخص سرعتی که کاربر صفحه را مشاهده می کند.
5. OnLoad : وقتی همه منابع صفحه (کدها و CSS ، تصاویر و غیره) بارگیری می شوند.
6. Fully Loaded : وقتی یک صفحه 100٪ ( به طور کامل )در مرورگر کاربر بارگیری می شود.
میانگین سرعت TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) طبق تصویر پایین روی دسکتاپ 1.286 ثانیه و در موبایل 2.594 ثانیه است.
در این تصویر مشاهده میتوایید که TTFB در دسکتاپ بهتر از موبایل عمل میکند.
میانگین سرعت Render Start ( لحظه ای که مرورگر کاربر شروع به نمایش محتوا می کند ) طبق تصویر پایین در دسکتاپ 2.834 ثانیه و در موبایل 6.709 ثانیه است.
میانگین سرعت Visual Complete ( زمانی که کاربر می تواند تمام ظاهر صفحه را مشاهده کند ) طبق تصویر پایین در دسکتاپ 8.225 ثانیه و در موبایل 21.608 ثانیه است.
میانگین سرعت Speed Index ( شاخص سرعتی که کاربر صفحه را مشاهده می کند ) طبق تصویر پایین در دسکتاپ 4.782 ثانیه و در موبایل 11.455 ثانیه است.
میانگین سرعت OnLoad ( وقتی همه منابع صفحه (CSS ، تصاویر و غیره) بارگیری می شوند ) طبق تصویر پایین روی دسکتاپ 8.875 ثانیه و در موبایل 23608 ثانیه است.
میانگین سرعت Fully Loaded ( وقتی یک صفحه 100٪ در مرورگر کاربر بارگیری می شود ) طبق تصویر پایین در دسکتاپ 10.3 ثانیه و در موبایل 27.3 ثانیه است.
نکته کلیدی : میانگین سرعت بارگیری صفحه برای یک WEB PAGE صفحه وب 10.3 ثانیه روی دسکتاپ و 27.3 ثانیه در موبایل است. به طور متوسط، بارگیری صفحات وب روی دستگاه های موبایل 87.84٪ بیشتر از بارگیری صفحات وب نسبت به دسکتاپ می باشد.
Weebly و Squarespace بهترین عملکرد کلی سرعت ( طی پارامترهای تست شده تا به حال ) را دارند. اما وردپرس از عملکرد سرعت پایین تری برخوردار است .
وقتی صحبت از سرعت صفحه می شود ، کدام CMS بهترین است؟
برای پاسخ به این سوال، ما CMS مورد استفاده برای همه سایت هایی با مجموعه اطلاعات (داده) خودمان ( در تصویر زیر لیست این CMS ها را می توانید مشاهده کنید ) را مشخص کردیم . سپس عملکرد TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) را برای هر CMS که محاسبه کردیم ( به دست آوردیم ) با هم مقایسه کردیم.
طبق اطلاعات گروه وب سما، Weebly و Squarespace روی دسکتاپ، در بالای لیست قرار می گیرند.
لیست CMS های مورد بررسی در این تحقیق و رتبه بندی آنها
طبق تصویر زیر که مشاهده می نمایید برای عملکرد سرعت صفحه CMS روی موبایل، Squarespace شماره 1 می باشد … و بعد از آن، Adobe Experience Manager و سپس Weebly امتیاز 3 را بدست آوردند.
نکته جالب توجه این است که، وقتی صحبت از عملکرد سرعت صفحه CMS روی موبایل می شود، وردپرس، 14 چهاردهمین CMS مناسبی است که ما آنالیز کرده و به آن رسیدیم .
یکی دیگر از CMSهای محبوب، Wix است که از نظر سرعت بارگیری روی دسکتاپ و موبایل در رده نسبتا پایینی ( حتی پایین تر از دروپال و وردپرس ) قرار دارد.
در این تحقیق که در وبلاگ گروه وب سما منتشر کرده ایم ، اگرچه وردپرس یکی از CMS هایی است که تقریباً 30٪ از کل وب سایت ها ( در دنیا و ایران بیشترین استفاده از وردپرس در بین تمامی CMS ها می شود ) از آن استفاده می کنند اما به وضوح برای سرعت بارگزاری صفحه بهینه نیست. این بدین معنا نیست که وردپرس یک CMS بدی است. وردپرس مزایای زیاد دیگری ( مانند سهولت استفاده، open source، رایگان بودن، یک مجموعه گسترده از افزونه ها و قالب ها و سئو خوب ) دارد که آن را برای بسیاری از دارندگان سایت تبدیل به CMS محبوب می کند.
با این حال، هنگامی که به سرعت بارگیری وب سایت نگاه می کنید، به نظر می رسد که سایر CMS ها دارای وجه مشخصی نسبت به وردپرس هستند.
نکته کلیدی : در میان تعداد زیادی از CMS ها، Squarespace و Weebly بهترین عملکرد صفحه در موبایل را دارند. WordPress و Wix در رده نسبتا پایین تری قرار دارند.
ما تأثیر ویژگی های مختلف صفحه بر روی TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) را تحلیل کردیم.
این چیزی است که ما یافتیم و میتوانید در تصویر زیر مشاهده نمایید :
همانطور که مشاهده می کنید، به نظر می رسد استفاده از CDN برای دسکتاپ و موبایل، TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) را بهبود می بخشد. با این حال، به نظر می رسد CDN ها در مقایسه با موبایل، در دسکتاپ مفیدتر هستند. در صفحات لود شده از طریق دستگاه موبایل، تعداد درخواست های HTML بیشترین تأثیر را روی TTFB داشته است.
در حالی که ما بین خصوصیات صفحات مختلف و تعداد دفعات TTFB رابطه ای پیدا نکردیم، اما این ویژگی ها ( عوامل سطح صفحه ) TTFB را ساخته اما از بین نمی برند. TTFB تا حد زیادی توسط پاسخ های سمت سرور تعیین می شود.
مجموعه وب سما، بعدا مفصل تر به این موضوع رسیدگی کرده و آن را توضیح خواهد داد.
نکته کلیدی : استفاده از CDN و به حداقل رساندن درخواست های HTML ممکن است TTFB را در دسکتاپ و موبایل سرعت ببخشد.
“visually complete” صفحات بزرگ در مقایسه با صفحات کوچکتر 381٪ بیشتر طول می کشد.
“Visually Complete” ( کاربر می تواند تمام ظاهر صفحه را مشاهده کند ) وقتی است که تمام محتوای نمایشی یک صفحه وب در داخل مرورگر کاربر بارگیری شود تا کاربر بتواند کاملا یک صفحه را مشاهده نماید.
نکته مهم و قابل توجه در این بخش که تیم تحقیقاتی ما به آن رسیده است ( وب سما ) این می باشد که ممکن است اسکریپت ها و عوامل دیگری در خارج از صفحه ( BackGround ) بارگیری شوند. اما از دید کاربر، فقط صفحه بارگیری می شود.
Visually Complete ( کاربر می تواند تمام ظاهر صفحه را مشاهده کند ) یک معیار اندازه گیری مهم برای سرعت صفحه است زیرا تجربه ذهنی کاربر را در بارگیری سریع یا آهسته صفحه نشان می دهد.
تا زمانی که کاربر بتواند صفحه را ببیند و از آن استفاده کند، صفحه کاملاً بارگیری می شود … حتی اگر هنوز عواملی ( کدهایی ) در پشت صحنه در حال بارگیری و ارائه باشد.
ما فهمیدیم که اندازه صفحه ( bytesTotal ) تأثیر قابل توجهی بر تعداد دفعات بارگزاری Visually Complete در موبایل و دسکتاپ دارد.
در تصویر زیر میتوانید عواملی که روی Visually Complete در موبایل و دسکتاپ تاثیر دارند را مشاهده نمایید.
با این حال، اندازه صفحه روی موبایل در مقایسه با دسکتاپ از اهمیت بیشتری برخوردار است.
در دسکتاپ، استفاده از CDN ارتباط مستقیم با Visually Complete ( کاربر می تواند تمام ظاهر صفحه را مشاهده کند ) در سرعت بارگزاری سریعتر را دارد. تاثیر اندازه صفحه بر Visually Complete نیز مانند CDN زیاد است.
CDN در دستگاه های موبایل، 5اُمین عامل مهم در Visually Complete است.
بنابراین اگر بهبود سرعت بارگزاری موبایل برای شما اولویت اصلی است، ما ( گروه وب سما ) پیشنهاد می دهم تا حد امکان اندازه صفحات خود را کاهش دهید. این ممکن است به معنای حذف اسکریپت های third party یا فشرده سازی تصاویر باشد. تمامی این مراحل به سایت شما بستگی دارد. با این حال، واضح است که، وقتی صحبت از سرعت Visually Complete می شود، ارتباط مستقیم با اندازه HTML دارد.
نکته کلیدی : CDN ها می توانند سرعت صفحات Visually Complete را به طور قابل توجهی روی دسکتاپ و موبایل بهبود بخشند. با این حال، CDN ها تأثیر بسیار بیشتری در بارگیری دسکتاپ دارند. برای موبایل، اندازه کل صفحه مهمترین عامل برای تعداد دفعات بارگزاری Visually Complete است.
حجم کل صفحه به سرعت صفحه ” Fully Loaded ” گره خورده است
سرانجام، ما به عواملی که بر سرعت صفحه ” Fully Loaded ” تأثیر می گذارد، پرداختیم.
همانطور که از نام آن پیداست، Fully Loaded وقتی است که 100٪ محتویات صفحه بارگیری و ارائه می شوند.
وقتی صحبت از سرعت صفحه Fully Loaded می شود، اندازه کل یک صفحه، مهمترین عامل روی دسکتاپ و موبایل است.
در این بخش با بررسی به عمل آمده به این نکته رسیده ایم که تعداد درخواست ها همچنین در چقدر سریع بودن Fully Loaded ( وقتی یک صفحه 100٪ در مرورگر کاربر بارگیری می شود ) نقش دارند.
آنچه در مورد این داده ها جالب می باشد این است که همبستگی شدید بین دسکتاپ و موبایل وجود دارد. برخلاف بسیاری از معیارهای دیگر که مورد تجزیه و تحلیل قرار دادیم، به نظر می رسد Fully Loaded بر روی دسکتاپ و موبایل تحت تأثیر همان مجموعه متغیرها ( یعنی اندازه صفحه و تمامی درخواست های HTML ) قرار دارند.
با این حال، اهمیت اندازه صفحات و درخواست های HTML برای Fully Loaded در مقایسه با همین عوامل برای Visually Complete ( کاربر می تواند تمام ظاهر صفحه را مشاهده کند ) و TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML )، نتایج شگفت آوری نداشته است.
فشرده سازی تصاویر، ذخیره سازی ( caching ) و سایر مراحل، معمولاً مدت زمان بارگزاری صفحه را کاهش می دهند. اما این موارد تا یک حدی می توانند در کاهش زمان بارگزاری صفحات موثر باشند.
- در آخر، برای اینکه صفحه ای به طور Fully Loaded ( بارگزاری کامل ) شود، یک مرورگر مجبور است تمام محتویات را در صفحه بارگیری کند. و هرچه محتویات بیشتری برای بارگیری وجود داشته باشد، بارگیری صفحه بیشتر طول خواهد کشید.
احتمالاً به همین دلیل به نظر نمی رسد CDN تأثیر زیادی روی سرعت صفحه Fully Loaded داشته باشد (Fully Loaded از نظر اهمیت طبق تصویر بالا ، در جایگاه سوم بر روی دسکتاپ و جایگاه دهم در موبایل دارد ). CDN ها می توانند تعداد دفعات بارگزاری تصویر را بهبود بخشند. اما آنها کمک زیادی به اسکریپت های third party ( پس زمینه ) و سایر محتویات نمی کنند که این عوامل باعث کندی صفحات می شود.
نکته کلیدی : اندازه کل صفحه در Fully Loaded بیشتر از هر متغیر دیگری در سرعت صفحه بر روی دسکتاپ و موبایل تاثیرگزار است. صفحات بزرگ ( > 3.49 مگابایت ) برای Fully Loaded در مقایسه با صفحات کوچکتر ( < 0.83 مگابایت ) 486٪ بیشتر طول می کشد.
Wink و Gatsby، سریعترین فریم ورک های جاوا اسکریپت ( JavaScript Frameworks ) برای صفحات وب با سایز متوسط هستند.
در برنامه نویسی برای وب سایت ها که داراری زبان های برنامه نویسی مختلفی در دنیای وب میباشند که دارای فریم ورک های متفاوت تری هستند، وقتی صحبت از اولویت بندی در اینکه چه چیزی در یک صفحه (و چه زمانی) بارگزاری می شود، فریم ورک های جاوا اسکریپت ( JavaScript Frameworks ) کارآیی بالایی از خود نشان می دهند.
به همین دلیل است که تقریباً 76٪ از کل وب سایت ها از این فریم ورک های جاوا اسکریپت ( JavaScript Frameworks ) برای ایجاد صفحات کارآمد، ایمن و استاندارد استفاده می کنند.
ما برای اولین بار معیارهایی را برای استفاده از هر فریم ورک در وب جمع آوری می کنیم. در تصویر زیر می توانید این مقایسه را برای انواع فریم ورک ها مشاهده نمایید.
در دنیای طراحی و توسعه نرم افزار و وب سایت React تقریباً متداول ترین فریم ورک جاوا اسکریپت است (25.3٪ سایت ها از آن استفاده می کنند). (10.3٪) TweenMax و RequireJS (9.5٪) نیز نسبتاً محبوب هستند.
در مرحله بعد ما ( تیم گروه وب سما ) به این مساله پی بردیم که فریم ورک های جاوا اسکریپت در صفحات کوچک ( کمتر از 1،264،374 بایت )، صفحات متوسط ( ما بین 1،264،374 و 4،019،332 بایت ) و صفحات بزرگ ( بیشتر از 4،019،332 بایت ) به بهترین شکل اجرا می شوند.
برای صفحات کوچک، فریم ورک RightJS در رتبه بالایی قرار دارد.
برای صفحات متوسط (ما بین 1،264،374 و 4،019،332 بایت)، Wink وGatsby بهترین عملکرد را داشتند.
و در صفحات بزرگ ( بیشتر از 4،019،332 بایت )، Gatsby و Riot سریعترین تعداد دفعات FCP را داشتند.
به طور کلی، انتخاب یک فریم ورک جاوا اسکریپت ( استفاده از کتاب خانه های جاوا اسکریپت ) می تواند تأثیر قابل توجهی بر روی تعداد دفعات FCP داشته باشد. در واقع، برای صفحات متوسط، بهترین فریم ورک جاوا اسکریپت ( Wink ) 213٪ سریعتر از کندترین فریم ورک ( Meteor ) بارگزاری می شود.
اگرچه برای بهترین و بدترین عمل کننده ( استفاده کننده از فریم ورک جاوا اسکریپت ) تقریباً همپوشانی زیادی وجود دارد ( به عنوان مثال، Gatsby و RightJS در بین هر سه تصویر در رده اول تا پنجم قرار دارند )، اما به نظر می رسد که برخی فریم ورک های جاوا اسکریپت خاص در صفحات با سایز خاص بهتر عمل می کنند.
به عنوان مثال ، Riot یک فریم ورک عالی برای صفحات بزرگ است ( طبق تصاویر در کل در رده دوم قرار دارد ).
با این حال، برای صفحات کوچک، Riot به طور قابل توجهی عملکرد بدی دارد (طبق تصاویر در کل در رده پانزدهم قرار دارد).
نکته کلیدی : هیچ فریم ورک جاوا اسکریپتی را نمی توان به عنوان بهترین عملکرد برای تمام موقعیت ها مدنظر قرارداد. برای مثال سایت هایی که تعداد زیادی صفحه کوچک دارند، RightJS به عنوان بهترین گزینه در نظر گرفته می شود. برای وب سایت های دارای صفحات عمدتا بزرگ، Gatsby ایده آل به نظر می رسد.
صفحات به میزان فشرده سازی کم یا زیاد، سرعت متفاوتی در زمان بارگزاری دارند
نکته خیلی مهمی که گروه وب سما به شما پیشنهاد میکند که حتما در طراحی وب سایت و یا استفاده از CMS خود مئ نظر قرار بدهید این است که فشرده سازی فایل های صفحه روی یک سرور، شمشیر دو لبه است. از یک طرف، فشرده سازی فایل ها باعث کاهش چشمگیر وزن صفحه می شوند.
با این حال، فشرده سازی فایل ها قبل از ارسال آنها از سرور مستلزم انجام کارهای اضافی در مرورگر است، زیرا کاربر قبل از ارائه آنها باید فایل ها را از حالت فشرده خارج کند.
به عنوان بخشی از این تجزیه و تحلیل، ما سعی کردیم پاسخی برای این سوال بیابیم :
- آیا فشرده سازی فایل ها در واقع سرعت صفحه را بهبود می بخشد؟
برای پاسخ به این سؤال، FCP را به سه دسته (سریع، متوسط و آهسته) طبقه بندی کردیم :
سریع : 0 – 1000ms
متوسط : 1000ms – 2500ms
آهسته : < 2500ms
سپس سرعت FCP و میزان فشرده سازی را بین صفحات کوچک، متوسط و بزرگ مقایسه کردیم.
برای صفحات کوچک، میزان فشرده سازی کمتر با سریعتر بودن تعداد دفعات بارگزاری FCP مرتبط بود. با این حال، فشرده سازی بسیار بالا ( 90 – 100 ) باعث دوباره بالا رفتن زمان بارگزاری می شود.
صفحات با سایز متوسط دارای نمودار منحنی مشابهی بودند :
صفحات بزرگ دارای نمودار منحنی واضح تری هستند :
اگرچه نمودار مقایسه بین اندازه صفحات متفاوت است، اما میزان مصرف آن کاملاً واضح است : صفحاتی که سطح فشرده سازی آنها بسیار کم یا بسیار زیاد است به همان میزان سرعت متفاوتی در زمان بارگزاری دارند.
در حقیقت، می توانید برای صفحاتی که مقدار متوسطی از فایل های آنها را فشرده می کنند، افت عملکرد FCP را مشاهده کنید.
همانطور که در تصویر بالا مشاهده مینمایید به طور خاص، صفحاتی که 60٪ – 80٪ فایل های خود را فشرده می کنند، بدترین عملکرد را دارند.
بنابراین، وقتی می توان سرعت صفحه را بهبود بخشید، فشرده سازی فوق العاده کم یا فوق العاده زیاد به سمت عملکرد بهتر می رود.
فشرده سازی کم، کار مورد نیاز مرورگر را کاهش و فشرده سازی بالا باعث بالا رفتن فعالیت در سمت کاربر می شود.
نکته کلیدی : صفحات با فشرده سازی بسیار کم یا بسیار زیاد، عملکرد بهتری در مقابل صفحات با میزان فشرده سازی متوسط دارند.
اسکریپت های Third-Party روی زمان بارگزاری تأثیر منفی می گذارد
جای تعجب نیست که ما متوجه شدیم اسکریپت های Third-Party ( مانند گوگل آنالیتیکس، دکمه های اشتراک اجتماعی و میزبانی ویدیو ) منجر به کندتر شدن زمان FCP می شوند.
در واقع، ما دریافتیم که هر اسکریپت Third-Party زمان بارگزاری صفحه را به 34.1 میلی ثانیه افزایش می دهد.
یافته های ما منطبق با دیگران است مانند این که متوجه شدند اسکریپت های Third-Party تأثیر گسترده ای در سرعت صفحه دارند.
- بدیهی است که این تأثیر بستگی به اسکریپت مورد استفاده دارد.
برخی اسکریپت های Third-Party ( مانند Hotjar ) به سرعت، بارگیری می شوند. دیگر اسکریپت ها، از جمله Salesforce، بسیار آهسته هستند.
به طور خلاصه، اسکریپت های Third-Party منجر به زمان بارگیری طولانی تر می شوند. و هرچه یک صفحه دارای اسکریپت بیشتری باشد، به همان مقدار زمان بارگزاری آن آهسته تر می شود.
نکته کلیدی : هر اسکریپت Third-Party که در یک صفحه استفاده می شود، زمان بارگزاری صفحه را به 34.1 میلی ثانیه افزایش می دهد.
تصاویر ریسپانسیو باعث بهبود بارگزاری صفحه، بیشتر از Lazy Loading (بارگزاری موقت) و Use of WebP می شوند
تصاویر به دو دلیل اصلی در عملکرد وب سایت نقش بسیار مهمی دارند :
اول، تصاویر مقدار قابل توجهی از اندازه کلی صفحه را در خود جای می دهند.
دوم، توجه کاربر تمایل دارد تا روی تصاویر نشان داده شده در یک صفحه متمرکز شود. و اگر آن تصاویر به آرامی بارگیری شوند، این می تواند UX را تحت تأثیر قرار دهد.
از آنجا که تصاویر می توانند سرعت بارگزاری یک سایت را کم یا زیاد کنند، ما تصمیم گرفتیم عملکرد چهار روش مختلف را برای بهینه سازی تصویر مقایسه کنیم :
• WebP : توسط Google ایجاد شده، WebP فرمت تصویری است که می تواند در مقایسه با سایر قالب ها، فایل اندازه کوچکتر داشته باشد، اما هنوز هم سطح مشابهی از کیفیت تصویر نسبت به دیگر فرمت های تصویر را در پی دارد.
• تصاویر بهینه شده : زمانی تصاویر بهینه می شود که نسخه های مختلف یک تصویر بسته به دستگاه، مکان و موارد دیگر کاربر ارائه شود. برای این منظور ما در این مقاله استفاده از یک شبکه تحویل محتوا (CDN)، نحوه فشرده سازی تصویر و سایر خدمات وب و بهینه سازی تصویر را در این بخش گنجانده ایم.
• تصاویر خارج از دید صفحه نمایش : زمانی که کاربر در حال دیدن بخشی از یک صفحه وب سایت هست در بخش دیگری از همان صفحه سایت تصاویری قرار دارد که این تصاویر نباید قبل از اینکه کاربر به آنها برسد بارگزاری شوند و نمایش این تصاویر باید به صورت “lazy loading” باشد.
• تصاویر ریسپانسیو : هنگامی که تصاویر به صورت پویا با اندازه پنجره مرورگر یا سیستم مورد نظر سازگار می شوند.
و هنگامی که ما این روش های مختلف را برای رده بندی سرعت Lighthouse مقایسه کردیم، تصاویر پاسخگو در بالاترین رتبه قرار گرفتند.
ما همچنین تجزیه و تحلیل کردیم که کدام رویکرد منجر به بیشترین نمره برای رسیدن به 100/100 Lighthouse شده است. در این بررسی ها، نتایج بسیار مشابه بود.
نکته کلیدی : اگرچه ممکن است WebP فشرده سازی تصویر را در مقایسه با PNG و JPEG بهبود بخشد، اما در حال حاضر تعداد بسیار کمی سایت، این فرمت جدید تصویر را پیاده سازی کرده است.
میزبانی GitHub و Weebly بهترین عملکرد TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) را دارد. Siteground وWix بدترین عملکرد میزبانی را دارند.
ما عملکرد سرعت صفحه ارائه دهندگان اصلی میزبانی وب را با هم مقایسه کردیم.
ما با توجه به اینکه زمان پاسخگویی سرور بیشترین تأثیر را روی TTFB دارد، چگونگی عملکرد میزبان های مختلف را بر روی این پارامتر کلیدی تجزیه و تحلیل کردیم.
به طور خاص، ما TTFB را به سه دسته (سریع، متوسط و آهسته) طبقه بندی کردیم. و ما درصدی را که هر میزبان در هر دسته، به دست آورده مشاهده کردیم.
در اینجا عملکرد TTFB هر ارائه دهنده میزبانی وب روی دسکتاپ وجود دارد :
Github ،Weebly و Acquia سه تا از برترین عملکردها را برای TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) دسکتاپ دارند. Automattic ،Wix و Siteground بدترین ها هستند.
ما این تحلیل مشابه را برای TTFB موبایل اجرا کردیم. در اینجا نتایج آمده است :
عملکرد TTFB در بین ارائه دهندگان اصلی میزبانی وب (موبایل)
همانطور که مشاهده می کنید، Github در موبایل و دسکتاپ بسیار خوب عمل می کند. که با توجه به اینکه صفحات Github فقط در خدمت منابع استاتیک است، نباید جای تعجب داشته باشد. این بدان معنی است که، از بسیاری جهات، Github یک مقایسه 1:1 با میزبان وب “معمولی” ندارد.
- Seravo ،Netlify و Weebly در صدر جدول رده بندی قرار دارند. Wix و Automattic در پایین لیست هستند.
نتیجه گیری این تحلیل چیست؟
TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) تنها یکی از عوامل بسیاری است که هنگام انتخاب میزبان باید در نظر بگیرید. همینطور هزینه، زمان به موقع، پشتیبانی مشتری، ویژگی ها و موارد دیگر را نیز باید لحاظ کنید.
گفته می شود، وقتی نوبت به بارگزاری سریع صفحه در دسکتاپ و موبایل می رسد، صفحات Github بهترین گزینه در بین میزبان های اصلی است. میزبان های Wix و Automattic تمایل دارند زمان TTFB کند را داشته باشند.
نکات کلیدی : در بین ارائه دهندگان اصلی میزبانی، Github و Weebly بهترین عملکرد را در دسکتاپ دارند. طبق آنالیز ما GitHub و Seravo سریعترین میزبان موبایل بودند. با این حال، باید توجه داشت که صفحات Github فقط به صفحات ایستا خدمت می کند، که این یک مزیت ذاتی نسبت به میزبان های دیگر است که ما آنالیز کردیم.
چین، ژاپن و آلمان سریعترین زمان بارگزاری TTFB را دارند.
ما زمان بارگزاری TTFB را برای 11 کشور از مجموعه داده های مان مقایسه کردیم.
در اینجا بخش بندی از کشور به کشور برای سرعت دسکتاپ ارائه شده است :
و در این بخش نمایش سرعت از کشور به کشور برای موبایل ارائه شده است :
نکات کلیدی : چین بهترین عملکرد TTFB ( زمان خواندن اولین بایت از درخواست پرونده HTML ) موبایل و دسکتاپ را دارد. در مرحله بعدی ژاپن و آلمان با سرعت بالای صفحه در بالای میانگین جهانی هستند. فرانسه، انگلیس، کانادا، ایالات متحده و روسیه سرعت متوسط صفحه دارند. استرالیا، برزیل و هند سرعتی دارند که کمتر از میانگین جهانی است.
صفحات دارای CDN از کسانی که CDN ندارند بدتر عمل می کنند
یكی از شگفت آور ترین یافته های ما این بود كه صفحاتی كه از CDN استفاده می كردند در حقیقت از آنچه كه از CDN استفاده نمی كردند ، بدتر بودند.
این برای هر دو دسکتاپ و موبایل درست بود :
و موبایل :
چگونه امکان دارد همچین اتفاقی افتاده باشد؟
از نظر تئوری، زیرا محتوا را نزدیک به جایی که کاربر در آن قرار دارد تحویل می دهد، یک CDN باید سرعت صفحه را در صفحه بورد بهبود بخشد.
با این حال، این مورد در تحلیل ما اینگونه نبود.
ما فرض کردیم که همه CDN ها برابر نیستند. در بسیاری از موارد، استفاده از CDN با بهینه سازی ضعیف در واقع می تواند سرعت را کاهش دهد.
و هنگامی که ما عملکرد 18 تا از ارائه دهندگان برتر CDN را تجزیه و تحلیل کردیم، در واقع، تفاوت بزرگی را در عملکرد کشف کردیم.
در زیر لیست 18 مورد از ارائه دهنده های CDN در دنیا که ما بررسی کرده ایم را مشاهده می نمایید:
- CACHEFLY ( CacheFly یک شبکه ارائه دهنده محتوای مستقر در آمریکا و شیکاگو ، ایلینوی است. )
- FASTLY ( درسان فرانسیسکو، کالیفرنیا، آمریکا که در سال 2011 تاسیس شده وشرکت تابعه: Signal Sciences Corporation است )
- GITHUB PAGES
- AZURE CDN ( سی دی ان شرکت مایکروسافت با کیفیت و قیمت عالی اما محدودیت برای ایرانیان دارد )
- NETLIFY ( باز هم شرکتی دیگر در سانفرانسیسکو که در سال 2014 تاسیس شده است )
- KEYCDN ( یکی از شرکتهای معتبر در این حوزه با امکان انتخاب سرور نزدیکتر کاربری )
- EDGECASE
- GOOGLE CLUDE ( این سرویس که دیگر قابل تعریف نیست چون برای بزرگترین شرکت خدماتی دنیا در زمینه وب ، یعنی گوگل می باشد و با کیفیت بالا و امنیت بی نظر برای هر نوع وب سایت اما کمی گرون برای ایرانی ها که در سال 2008 تاسیس شده )
- CDN77
- AMAZON CLOUDFRONT ( سرویس cdn شرکت آمازون با طرفداران زیاد در دنیا که به ایرانیان عزیز سرویس دهی نمی کند. 🙁 خجالت هم نمیکشن . مگه ما چیکار کردیم 🙁
- AIREE ( با بیش از 20 سرور در تمام دنیا و لیست سرورها که بیشتر آنها در آمریکا و اروپاست )
- MAXCDN ( MAXCDN در حال حاضر به شرکت StackPath پیوسته است . یکی از برترین و اولین شرکت های خدمات دهنده cdn در دنیا که خوشبختانه ما ایرانی ها رو تحریم کرده و خدمات نمیده )
- INCAPSULA ( باز هم یک شرکت دیگر آمریکایی با خدمات عالی در دنیا برای cdn )
- CLOUDFLARE ( بعید میدونم کسی در دنیای وب CDN آشنا باشه و خدمات رایگان و با کیفیت کلود فلر آشنا نباشد. البته در همین لحظه که شما در حال خاندن این مطلب هستید بیش از 60 درصد از وب سایت های ایرانی که از cdn استفاده می کنند از خدمات رایگان همین شرکت استفاده می کنند.)
- SUCURI ( یکی از شرکتهای پر قدرت در ضمینه امنیت در دنیا و حتی در زمینه وردپرس که خدمات cdn نیز ارائه می دهد)
- ARVANDCLOUD ( شرکت ابر آروان که در ایران فعالیت می کند را میتوان با افتخار یکی از بهترین خدمات دهنده های cdn در دنیا دانست که خدمات تخصصی این حوزه را به ایرانیان عزیز و حتی تمامی وب سایت های دنیا ارائه میدهد. شرکت ابرآروان یا arvancloud با افتخار یکی از 10 خدمات دهنده برتر و با کیفیت cdn در دنیا می باشد که با کمی جستجو در وب سایت های انگلیسی زبان هم به این نتیجه می رسید.) مجموعه وب سما نیز از خدمات همین شرکت استفاده می کند.
- FIREBLADE ( این شرکت نیز مثل شرکت maxcdn توسط کمپانی stackpath خریداری شده و در حال حاظر زیر مجوعه این کمپانی پر قدرت می باشد )
- AKAMAI ( این شرکت نیز در آمریکا مستقر بوده و مجموعه های بزرگی مثل IBM , FIAT , FOX , ADOBE از آن استفاده می کنند. البته کمی گران هست ولی خدمات با کیفیت و عالی ارائه می کند.)
در انتها اگر شما هم از شرکتهای ارائه دهنده هخدمات توضیع محتوا یا CDN استفاده کرده اید . خوشحال میشویم که تجربیات خود را با ما در میان بگذارید.
به طور خاص، ما متوجه شدیم که ( بر روی دسکتاپ ) بهترین CDN،ب3.6 برابر بهتر از بدترین CDN کار می کند. این به توضیح اینکه چرا CDN به طور خودکار عملکرد را بهبود نمی بخشد، کمک می کند.
برای اینکه مکان های جغرافیایی ضعیف را آسان تر درک کنیم ، عملکرد CDN را با میانگین جهانی مقایسه کردیم.
در ادامه برای تست بهتر و با کیفیت تر ما هر CDN را در یکی از سه وضعیت زیر قرار می دهیم :
خوب (سریع٪ و آهسته٪ از همه ارائه دهندگان بهتر از میانگین است)
متوسط (سریع٪ یا آهسته٪ از میانگین در کلیه ارائه دهندگان بهتر است)
بد (سریع٪ و آهسته٪ از کل ارائه دهندگان بدتر از میانگین است)
در اینجا خلاصه ای از عملکرد برای هر ارائه دهنده وجود دارد :
دسکتاپ
خوب: Airee ، Amazon Cloudfront ، Azure CDN ، CacheFly ، EdgeCast ، Fastly، GitHub Pages ، Google Cloud ، KeyCDN ، MaxCDN ، Netlify
میانگین: CDN77
بد: Akamai ، ArvanCloud ، Cloudflare ، Fireblade ، Incapsula ، Sucuri
موبایل
خوب: Airee ، Amazon Cloudfront ، Azure CDN ، CDN77 ، EdgeCast ، Fastly ، Pages GitHub ، Google Cloud ، KeyCDN ، MaxCDN ، Netlify
متوسط: Fireblade، Incapsula ، Sucuri
بد: Akamai ، ArvanCloud ، Cloudflare
راه حل اصلی : با استفاده از CDN عملکرد سرعت صفحه وب سایت شما به طور خودکار بهبود نمی یابد. برخی از CDN ها بطور قابل توجهی بهتر از سایرین عمل می کنند. بنابراین، مهم است که با CDN کار کنید که هم در دسکتاپ و هم در موبایل عملکرد خوبی داشته باشد. البته این نکته بستگی زیادی به موقعیت جغرافیایی شما دارد.
نتیجه گیری نهایی را از شما خواننده گرامی می خواهیم بشنویم :
- کدام یافته از این مطالعه در این مطلب برای شما برجسته و مفید تر بود؟
- در مورد کدام نتیجه در این تحقیق می خواهید استفاده و اقدام کنید؟
- این مطلب چه دیدی برای بهبود عملکرد وب سایت به شما داد؟
- آیا تغییراتی در دیدگاه شما برای توسعه بیشتر و بهتر وب سایت شما و استفاده از خدمات ارائه نمود؟
در هر صورت، با گذاشتن نظری در زیر به تیم گروه وب سما اطلاع دهید تا با هم بیشتر به توسعه بهتر دنیای وب کمک کنیم.
2 دیدگاه در “آمار سرعت صفحه با آنالیز 5.2 میلیون صفحه وب سایت”
حسین اکبرزاده
با سلام
اول که دیدم نوشتین 27 دقیقه طول میکشه تا مطلبو بخونی به خودم گفتم مگه اینقدر بیکار هم پیدا میشه
اما وقتی مقالرو پله پله جلو میرفتم دیدم
اینقدر جذابه که بیشتر هم طول بکشه باز ادامه میده آدم
عالی بود مطلب
از صفر تا انتها توضیح دادین که چجور یک صفحه معیار بندی میشه برای سرعت
ممنون
websama
سلام دوست عزیز
ممنون که وقت گذاشتین و مطالعه کردین
این مطلب به مرور زمان آپدیت های بیشتری دریافت می کند و استانداردهای جدید گوگل به آن اضافه می گردد