ما ۵.۲ میلیون از صفحات موبایل و دسکتاپ را تجزیه و تحلیل کردیم
آن چیزی که درباره سرعت صفحه یاد گرفتیم
ما ۵ میلیون صفحه دسکتاپ و موبایل را تجزیه و تحلیل کردیم تا بدانیم چه عواملی بر سرعت صفحه تأثیر می گذارند.
ما در ابتدا، معیارهای جهانی برای TTFB (مدت زمان انتظار برای دریافت اولین داده از سرور)، استانداردهای تکمیل شدن جلوه بصری (Visual Complete) و زمان لود شدن کامل صفحه را ایجاد کردیم.
سپس به چگونگی تاثیر فشرده‌سازی تصویر، CDNها (شبکه توزیع محتوا) و هاست روی سرعت بارگذاری سایت، نگاهی انداختیم.
داده‌های ما بینشی بسیار جالب (و تعجب برانگیز) به ما دادند.
خلاصه‌ای از یافته‌های کلیدی ما:
1. در تجزیه و تحلیل ما از ۵.۲ میلیون صفحه، میانگین سرعت TTFB (زمان برای اولین بایت) در دسکتاپ ۱.۲۸۶ ثانیه در دسکتاپ و ۲.۵۹۴ ثانیه در موبایل است. زمان متوسط که برای لود شدن کامل یک وبسایت طول می‌کشد، در دسکتاپ ۱۰.۳ و در موبایل ۲۷.۳ ثانیه طول می‌کشد.
2. لود شدن یک صفحه وب متوسط روی موبایل %87.84 بیشتر از لود شدن روی دسکتاپ به طول می‌انجامد.
3. وقتی CMSهای بزرگ با یکدیگر مقایسه می‌شوند، Squarespace و Weebly بهترین کارایی از نظر سرعت صفحه در موبایل را دارند. جایگاه Wix و WordPress در قعر جدول است.
4. در دسکتاپ، CDNها بزرگترین تاثیر را روی TTFB دارند. با این حال به نظر می‌رسد در موبایل‌ها، تعداد درخواستهای HTML بیشترین تاثیر را روی TTFB دارد.
5. سایز کلی صفحه تاثیر قابل توجهی روی سرعت لود Visually Complete دارند. بارگذاری بصری صفحات بزرگتر %۳۱۸ بیشتر از صفحات کوچکتر طول می‌کشد. ما همچنین متوجه شدیم متد فشرده سازی gzip به تصاویر کمک می‌کند تا روی دسکتاپ و موبایل سریعتر لود شوند.
6. حجم کل صفحه تعیین کننده شماره یک سرعت بارگذاری کامل صفحه سایت است. صفحات سبک ۴۸۶ درصد سریعتر از صفحات بزرگ لود می‌شوند.
7. Wink و Gatsby سریع‌ترین فریم‌ورک‌های جاوااسکریپت هستند. Meteor و Tweenmax کندترین هستند. سریع‌ترین فریم‌ورک %۲۱۳ سریعتر از کندترین آن است.
8. عملکرد سرعت صفحات با فشرده‌سازی فایل خیلی کم یا بسیار زیاد، بالاتر از متوسط است (اندازه‌گیری شده توسط اولین Contextual Paint).
9. اسکریپت‌های ثالث سرعت بارگذاری صفحه را به میزان قابل توجهی کاهش می‌دهند. با اضافه شدن هر اسکریپت ثالث به یک صفحه زمان لود به اندازه 34.1 میلی‌ثانیه افزایش می‌یابد.
10. ما کشف کردیم که استفاده از تصاویر ریسپانسیو منجر به بهترین عملکرد در بارگذاری تصاویر می‌شود. استفاده از WebP در کاهش زمان بارگذاری تصویر به طور قابل توجهی تاثیر کمی داشت.
11. هاست‌های وب GitHub و Weebly سریع‌ترین عملکرد کلی TTFB را دارند. از بین ارائه دهندگان هاستی که تجزیه و تحلیل کردیم Siteground و Wix کندترین بودند.
12. چین، ژاپن و آلمان سریع‌ترین زمان بارگذاری TTFB را دارند. استرالیا، هند و برزیل کندترین زمان TTFB را دارند.
13. استفاده از CDN با عملکرد بدتر سرعت صفحه مرتبط است. این به احتمال زیاد به این دلیل است که CDNهای خاص عملکرد قابل توجهی نسبت به سایرین دارند.
معیارها و استانداردهای اندازه‌گیری مدت زمان لود شدن صفحات اصلی
اولین کار ما ایجاد معیاهایی برای اندازه گیری سرعت صفحات اصلی بود.
همانطور که می‌دانید، “سرعت صفحه” از مراحل مجزای مختلفی تشکیل شده است.
برخی از این مراحل در سطح سرور اتفاق می‌افتند. و بقیه در مرورگر کاربر انجام می‌شوند.
و برای درک درست سرعت بارگذاری صفحات، باید هر کدام از این مراحل را به طور دقیق واکاوی کنیم.
به طور خاص، ما سرعت متوسط را برای موارد زیر اندازه گرفتیم:
. TTFB: زمان رسیدن اولین بایت از محتوای پاسخ HTML.
. StartRender: وقتی رندر کردن (اجرا) شروع می‌شود.
. Visual Complete: کاربر می‌تواند موجودی تمام صفحات را ببیند.
. Speed Index: سرعتی که کابر بارگذاری صفحه را مشاهده می‌کند.
. onLoad: وقتی همه منابع صفحه (CSS، تصاویر و…) دانلود می‌شوند.
. Fully Loaded: وقتی یک صفحه %100 در مرورگر کاربر لود می‌شود.
میانگین سرعت TTFB روی دسکتاپ 1.286 ثانیه و در موبایل 2.594 ثانیه است.
میانگین سرعت Render در دسکتاپ 2.834 ثانیه و در موبایل 6.709 ثانیه است.
میانگین سرعت visual complete در دسکتاپ 8.225 ثانیه و در تلفن همراه 21.608 ثانیه است.
میانگین سرعت ایندکس در دسکتاپ 4.782 ثانیه و در موبایل 11.455 ثانیه است.
میانگین سرعت بارگذاری روی دسکتاپ 8.875 ثانیه و در موبایل 23.608 ثانیه است.
متوسط سرعت لود شدن کامل در دسکتاپ 10.3 ثانیه و در تلفن همراه 27.3 ثانیه است.
نکته کلیدی: متوسط بارگذاری برای یک صفحه وب 10.3 ثانیه در دسکتاپ و 27.3 ثانیه در تلفن همراه است. به طور متوسط، صفحات روی موبایل 87.84% دیرتر از دسکتاپ لود می‌شوند.
Weebly و Squarespace بهترین عملکرد را به طور کلی در سرعت دارند. WordPress یکی از بدترین عملکردها را دارد.
وقتی نوبت سرعت صفحه می‌رسد، کدام CMS بهترین است؟
برای پاسخ به این سوال، ما CMSهای استفاده شده برای همه سایتها را در مجموعه داده‌های خود مشخص کردیم. سپس عملکرد TTFB را برای هر CMS که کشف کردیم مقایسه کردیم.
طبق اطلاعات ما، Weebly و Squarespace در صدر جدول برای دسکتاپ قرار دارند.
در رتبه بندی عملکرد سرعت صفحه برای موبایل، Squarespace شماره یک است و همراه با Adobe Experience Manager و Weebly ، سه جایگاه برتر را بدست می‌آورند.
نکته جالب توجه این است که، وقتی صحبت از سرعت موبایل می شود، وردپرس فقط در جایگاه 14همین CMS از بین آنالیزهای ما قرار می‌گیرد.
یکی دیگر از محبوب ترین سیستم های مدیریت محتوا ، Wix ، همچنین از نظر سرعت بارگیری روی دسکتاپ و موبایل ضعیف است.
اگرچه وردپرس تقریباً 30٪ از کلیه وب سایتها را تأمین می‌کند، اما به وضوح برای سرعت بارگذاری صفحه بهینه نیست. به معنای این نیست که WordPress سیستم مدیریت محتوای بدی است. مزایای دیگری دارد (استفاده راحت، کتابخانه گسترده‌ای از افزونه‌ها و سئو) که آن را به یک CMS قابل اعتماد برای بسیاری از صاحبان سایت تبدیل می‌کند. با این حال، هنگامی که به سرعت بارگیری وب سایت توجه می‌کنید، به نظر می‌رسد که سایر CMSها دارای مزیت مشخصی نسبت به وردپرس هستند.
نکته کلیدی: در میان عمده CMSها، Squarespace و Weebly بهترین عملکرد صفحه را در موبایل دارند. WordPress و Wix تقریبا در رده آخر قرار دارند.
استفاده از یک CDN ممکن است به دسکتاپ TTFB کمک کند.به حداقل رساندن درخواست HTML برای TTFB است.
ما تأثیر ویژگی های مختلف صفحه در TTFB را روی تحلیل کردیم. (مدت زمان برای بایت اول)
چیزی که فهمیدیم:
به نظر می‌رسد استفاده از یک CDN، TTFB را برای دسکتاپ و موبایل بهبود می‌بخشد. با این حال به نظر می‌رسد CDNها روی دسکتاپ مفیدتر از موبایل هستند.
در صفحات لود شده از طریق موبایل، تعداد درخواست های HTML بیشترین تأثیر را روی TTFB داشته است.
در حالی که ما بین خصوصیات صفحه مدت زمان TTFB رابطه ای پیدا کردیم، فاکتورهای page-level باعث درست شدن یا خراب شدن TTFB نمی‌شوند. TTFB تا حد زیادی توسط زمان پاسخ سرور تعیین می شود، چیزی که کمی بعد به آن خواهیم پرداخت.
نکته کلیدی: استفاده از CDN و به حداقل رساندن درخواستهای HTML ممکن است TTFB را در دسکتاپ و موبایل سرعت ببخشد.
صفحات بزرگ %۳۸۱ بیشتر از صفحات کوچکتر Visually Complete را طولانی‌تر می‌کنند.
Visually Complete وقتی است که کل محتوای تصویری یک صفحه وب داخل مروگر کاربر بارگذاری شود.
ممکن است اسکریپت‌ها و موجودی‌های دیگری خارج از صفحه بارگذاری شوند. اما از دید کاربر صفحه باگذاری می‌شود.
تکمیل شدن بصری یک استاندارد سرعت صفحه مهم است زیرا این موضوع که یک صفحه چقدر سریع یا کند بارگذاری می‌شود بر تجربه ذهنی تاثیر می‌گذارد.
تا زمانی که کاربر بتواند صفحه را ببیند و از آن استفاده کند، کاملا لود می‌شود… حتی اگر همچنان سایر موجودی‌ها در پشت صحنه در حال بارگذاری و اجرا باشند.
ما فهمیدیم که اندازه صفحه (بایت‌های کل) تاثیر قابل توجهی روی زمان لود شدن تکمیل بصری موبایل و دسکتاپ دارد.
با این حال، اندازه صفحه نسبت به دسکتاپ در موبایل از اهمیت بیشتری برخوردار است.
در دسکتاپ، استفاده از CDN با سرعت بارگذاری سریعتر Visually Complete کاملا ارتباط داشت.
در دستگاه‌های تلفن همراه، CDN تنها پنجمین عامل مهم بود.
بنابراین اگر بهبود سرعت بارگذاری تلفن همراه برای شما اولویت اصلی است، فکر می‌کنم که باید همه سعی خود را برای کاهش سایز صفحات بکنید.
این ممکن است به معنای حذف اسکریپت‌های ثالث باشد. یا فشرده کردن تصاویر. ترتیب دقیق مراحل به سایت شما بستگی دارد. با این حال، واضح است که، وقتی صحبت از سرعت Visually Complete می‌شود، به اندازه HTML وابسته است.
نکته کلیدی: CDN به طور قابل توجهی سرعت Visually Complete صفحه را روی موبایل و دسکتاپ افزایش می‌دهند. با این حال ، CDN ها تأثیر بسیار بیشتری روی بارگذاری در دسکتاپ دارند. برای موبایل، اندازه کل صفحه مهم‌ترین عامل برای زمان لود Visually Complete است.
حجم کلی صفحه تقریبا به سرعت «لود شدن کامل» صفحه وابسته است
در نهایت، ما به فاکتورهایی که بر سرعت «لود شدن کامل» صفحه تاثیر می‌گذارد، پرداختیم.
همانطور که از نام آن پیدا است، لود شدن کامل زمانی اتفاق می‌افتد که صد در صد موجودی‌های صفحه بارگذاری و اجرا شده‌اند.
وقتی به سرعت لود شدن کامل صفحه می‌رسد، اندازه کل صفحه مهم‌ترین فاکتور روی دسکتاپ و موبایل است.
تعداد درخواست‌ها نیز در سرعت بارگذاری صفحه نقش دارند.
نکته جالب در مورد این داده این است که اشتراک بسیاری میان دسکتاپ و موبایل وجود دارد. برخلاف بسیاری از معیارهایی که قبلا آنالیز کردیم، به نظر می‌رسد لود شدن کامل دسکتاپ و موبایل تحت تاثیر همان مجموعه متغیرها (یعنی اندازه صفحه و درخواستهای کلی HTML) قرار می‌گیرد.
با این حال، اهمیت اندازه صفحه و درخواستهای HTML نباید شگفت آور باشد.
فشرده سازی تصاویر، کشینگ (ذخیره سازی داده‌ها) و سایر موارد معمولا مدت زمان بارگذاری صفحه را کاهش می‌دهند. اما فقط تا همین حد می‌توانند پیش بروند. در پایان روز برای اینکه یک صفحه در حالت لود شدن کامل باشد، مرورگر باید همه موجودی روی صفحه را بارگذاری کند. و هر چه موجودی بیشتری برای بارگذاری وجود داشته باشد، بارگذاری بیشتر طول می‌کشد.
احتمالا به همین دلیل به نظر نمی‌رسد که CDN تاثیر زیادی روی سرعت لود شدن کامل صفحه داشته باشد (از نظر اهمیت کلی در دسکتاپ رتبه سوم و در موبایل رتبه دهم را دارد). CDNها می‌توانند زمان لود تصویر را بهبود بخشند. اما آنها نمی‌توانند کمک زیادی به اسکریپت‌های ثالث و سایر موجودی‌ها کنند که این قضیه باعث کند شدن سرعت می شود.
نکته کلیدی: اندازه کلی بیش از هر متغیر دیگر روی دسکتاپ و موبایل سرعت لود شدن کامل صفحه تاثیر می‌گذارد. صفحات بزرگ (3.48MB<) برای بارگذاری کامل در مقایسه با صفحات کوچکتر (0.83MB>)
%486 بیشتر طول می کشد.
Wink و Gatsby سریع‌ترین فریم‌ورک‌های جاوااسکریپت برای صفحات وب متوسط هستند
وقتی زمان اولویت‌بندی بارگذاری روی صفحه می‌رسد، فریم ورک‌های جاوااسکریپت کارهای سنگین زیادی انجام می‌دهد.
به همین دلیل است که تقریباً %۷۶ از کل وب سایت ها از این فریم ورک برای ایجاد صفحات کارآمد، ایمن و استاندارد استفاده می کنند.
ما ابتدا الگویی برای اینکه هر چند وقت از هر فریم‌ورک در سراسر وب استفاده می‌شود، فراهم کردیم.
React تقریباً متداول ترین فریم ورک JS است (%25.3 سایتها از آن استفاده می کنند). (TweenMax (10.3٪ و (RequireJS (9.5٪ نیز نسبتاً محبوب هستند.
در مرحله بعد می خواهیم بدانیم کدام فریم‌ورک‌های JavaScript در صفحات کوچک (1,264,374> Bytes) متوسط (1,264,374 و 4,019,332 Bytes) و بزرگ (4,019,332< Bytes) بهترین عملکرد را دارند.
برای صفحات کوچک RightJS در صدر جدول قرار می‌گیرد.
برای صفحات متوسط، Wink و Gatsby بهترین کارایی را دارند.
و برای صفحات بزرگ، Gatsby و Riot سریع‌ترین زمان FCP را دارند.
به طور کلی، انتخاب یک فریم‌ورک جاوا اسکریپت می تواند تأثیر بسزایی در زمان FCP داشته باشد. در واقع، برای صفحات متوسط بهترین فریم‌ورک JS (Wink)، 213% سریعتر از کندترین فریم‌ورک (Meteor) بارگیری می‌شود.
اگرچه کاملا کمی اشتراک برای بهترین و بدترین ارائه‌دهنده وجود دارد. مثلا Gatsby و RightJS جز پنج تای برتر در هر سه دسته‌بندی سایز صفحه بودند. به نظر می‌رسد برخی از فریم‌ورک های JS در صفحات با اندازه خاص کارایی بهتری دارند.
به عنوان مثال، Riot یک فریم‌ورک عالی برای صفحات بزرگ است (در همه جا دوم است).
با این وجود، برای صفحات کوچک، Riot به طور قابل توجهی بدتر است (در همه جا پانزدهم است).
نکته کلیدی: هیچ کدام از فریم‌ورک جاوااسکریپت در همه حالت‌ها بهترین نیستند. برای سایت‌هایی با تعداد زیادی صفحه کوچک، RightJS بهترین انتخاب شما است. برای سایت‌هایی با صفحات عمدتا بزرگ Gatsby ایده‌آل به نظر می‌رسد.
صفحات با سطوح کم یا زیاد فشرده سازی سریع‌ترین سرعت بارگذاری را دارند
فشرده‌سازی فایل‌ها روی یک سرور مثل شیمشیری دو لبه است. از یک طرف فشرده کردن فایل‌ها حجم صفحه را به طور قابل توجهی کاهش می‌دهد.
با این وجود، فشرده کردن فایل‌ها پیش از فرستادن آنها از سرور مستلزم کار اضافی در مرورگر است، زیرا کاربرد باید قبل از اجرا آنها را از حالت فشرده خارج کند.
به عنوان بخشی از این آنالیز، ما شروع به پاسخ دادن به این سوال می‌کنیم: آیا خارج کردن فایل‌ها از حالت فشرده واقعا سرعت صفحه را افزایش می‌دهد؟
برای پاسخ به این سؤال، FCP را به سه دسته (سریع، متوسط، آهسته) طبقه بندی کردیم:
سریع: 0-1000ms
متوسط: 1000ms-2500ms
کند: 2500ms>
سپس سرعت FCP و میزان فشرده‌سازی را بین صفحات کوچک، متوسط و بزرگ مقایسه کردیم.
برای صفحات کوچک، سطوح پایین‌تر از فشرده سازی زمان بارگذاری FCP سریعتری را به همراه داشت. با این حال، زمان بارگذاری در سطوح بالای فشرده سازی (%100-90) مجددا سرعت می‌گیرد.
صفحات متوسط دارای توزیع مشابهی بودند:
صفحات بزرگ حتی دارای منحنی توزیع زنگوله‌ای معکوس شدیدتر بودند:
اگرچه توزیع دقیق بین اندازه صفحه متفاوت است، اما نکته واضح است: صفحات با سطوح بالا یا پایین فشرده سازی سریع‌ترین بارگذاری را دارند.
در صفحاتی که تعداد محدودی از فایل‌های آنها فشرده شده‌اند، در حقیقت می‌توانید افت عملکرد FCP را مشاهده کنید.
مخصوصا، صفحاتی که %80-60 پرونده های خود را فشرده می کنند، بدترین عملکرد را دارند.
بنابراین، هنگامی که زمان بهبود سرعت صفحه می‌رسد، سطح فوق‌العاده بالا یا پایین از فشرده سازی تمایل دارد بهترین عملکرد را به نمایش بگذارد. سطح پایین فشرده سازی، کار مورد نیاز مرورگر را کاهش می‌دهد. و سطح بالای فشرده‌سازی با بسته‌های اطلاعاتی کوچکتر، کار چالش برانگیز سنگین‌تری در سمت کاربر است.
نکته کلیدی: صفحاتی که فشرده‌سازی بسیار کم یا بسیار زیاد دارند، در برابر صفحات با فشرده‌سازی متوسط عملکرد بهتری دارند.
تاثیر منفی زمان بارگذاری اسکریپت‌های ثالث
تعجب نکردیم وقتی فهمیدیم، اسکریپت‌های ثالث (مانند گوگل آنالیتیکس، دکمه های گذاری شبکه‌های اجتماعی و هاست‌های ویدیو) منجر به کندتر کردن زمان FCP می شوند.
در واقع، ما متوجه شدیم که هر اسکریپت ثالث زمان بارگذاری صفحه را 34.1 میلی ثانیه افزایش می دهد.
یافته‌های ما منطبق با آنچه دیگران پیدا کردند (مثل این مورد) نشان می‌دهد که اسکریپت‌های ثالث تاثیر گسترده‌ای روی سرعت صفحه دارند.
واضح است که این تاثیر وابسته به نوع اسکریپت استفاده شده است. بعضی اسکریپت‌های ثالث مثل Hotjar سریعا بارگذاری می‌شوند. بقیه، از جمله Salesforce بسیار آهسته هستند.
به طور مختصر، اسکریپت‌های شخص ثالث باعث مدت زمان بارگذاری طولانی‌تر می‌شوند. و هر چه صفحه اسکریپت بیشتری داشته باشد، بارگذاری آن طولانی‌تر می‌شود.
نکته کلیدی: هر اسکریپت ثالث روی صفحه، زمان بارگذاری را 34.1 میلی‌ثانیه افزایش می‌دهد.
تصاویر ریسپانسیو بیش از لود تنبل و استفاده از فرمت WebP باعث بهبود زمان بارگذاری صفحه می‌شوند
تصاویر به دو دلیل نقش بسیار مهمی در ظاهر وبسایت ایفا می‌کنند:
اول اینکه تصاویر مقدار قابل ملاحظه‌ای از اندازه کلی صفحه را پر می‌کنند.
دوم اینکه توجه کاربرد تمایل به تمرکز روی تصایر ظاهر شده روی صفحه دارد. و اگر آن تصاویر کند بارگذاری شوند، روی تجربه کاربری تاثیر منفی می‌گذارد.
از آن‌جایی که تصاویر می‌توانند سرعت لود سایت را بالابرده یا پایین بیاورند، ما تصمیم به مقایسه عملکرد چهار روش مختلف برای بهینه سازی تصاویر گرفتیم:
. فرمت WebP: توسط گوگل توسعه یافته است. فرمتی تصویری است که می‌تواند در مقایسه با سایر فرمت‌های فایل اندازه کوچک‌تری داشته باشد اما همچنان کیفیت را حفظ کند.
. تصاویر بهینه یافته: وقتی نسخه‌های مختلف تصویر بسته به دستگاه، مکان و غیره ارائه می‌شوند، تصاویر بهینه سازی شده به وجود می‌آیند.
ما استفاده از یک شبکه تحویل محتوا (CDN)، فشرده سازی تصویر و سایر خدمات وب بهینه سازی تصویر را در این بخش گنجانده‌ایم.
. به تعویق انداختن عکس‌های خارج از صفحه: وقتی کاربر به نقطه‌ای از صفحه می‌رود که تصاویر تحت لود شدن هستند، نمایش تصاویر و محتوای خارج از آن نقطه به تعویق می‌افتد. که این عمل به عنوان لود تنبل نیز شناخته شده می‌شود.
. تصاویر ریسپانسیو: وقتی تصاویر به صورت پویا با اندازه پنجره مرورگر سازگار می شوند.
و هنگامی که ما این رویکردهای مختلف را برای امتیازات سرعت Lighthouse مقایسه کردیم، تصاویر پاسخگو در صدر قرار گرفتند.
ما همچنین آنالیز کردیم که کدام رویکرد منجر به بیشترین امتیاز ۱۰۰ از ۱۰۰ در Lighthouse می‌شود. و نتایج بسیار مشابه بودند.
ما همچنین آنالیز کردیم که کدام رویکرد منجر به بیشترین امتیاز ۱۰۰ از ۱۰۰ در Lighthouse می‌شود. و نتایج بسیار مشابه بودند.
Github ، Weebly وAcquia سه ارائه دهنده برتر دسکتاپ TTFB بودند. Automattic ، Wix و Siteground بد بدترین وضعیت را داشتند.
ما مشابه این آنالیز را برای TTFB موبایل انجام دادیم.
همانطور که ملاحظه می‌کنید، Github Pages در موبایل و دسکتاپ بسیار خوب عمل می کند. با توجه به اینکه صفحات Github فقط به منابع پایدار خدمات رسانی می‌کند، جای تعجبی نیست. در بسیاری جهات به معنی این است که Github قابلیت مقایسه برابر با هاست معمولی را ندارد.
Seravo ،Netlify و Weebly در صدر جدول رده‌بندی قرار دارند Wix. و Automattic در پایین لیست هستند.
نکته این تجزیه و تحلیل چیست؟
TTFB تنها یکی از فاکتورهای بسیاری است که هنگام انتخاب هاست باید در نظر داشته باشید. موارد دیگری از جمله هزینه، زمان فعال بودن یک سیستم، پشتیبانی مشتری، قابلیت‌ها و… وجود دارند.
گفته می شود، وقتی نوبت به بار بارگذاری سریع صفحه در دسکتاپ و موبایل می رسد، صفحات Github بهترین انتخاب در میان هاست اصلی است.
هاست‌های Wix و Automatticتمایل به داشتن لحظات TTFB کند دارند.
نکته کلیدی: در میان ارائه دهندگان هاست، Github و Weebly بهترین عملکرد را روی دسکتاپ دارند. طبق آنالیز ما GitHub و Seravo سریع‌ترین هاست موبایل بودند. با این حال، باید توجه داشت که صفحات Github فقط به صفحات پایدار خدمات رسانی می‌کنند، که این یک مزیت ذاتی نسبت به سایر هاست‌هایی است که آنالیز کردیم.
چین، ژاپن و آلمان سریع‌ترین زمان بارگذاری TTFB را دارند.
ما زمان بارگذاری TTFB را برای یازده کشور با استفاده از مجموعه داده‌هایمان مقایسه کردیم.
نکته کلیدی: چین بهترین عملکرد TTFB را برای موبایل و دسکتاپ دارد. در مرحله بعدی ژاپن و آلمان با سرعت بالای بارگذاری صفحه بالاتر از میانگین جهانی قرار دارند. فرانسه، انگلیس، کانادا، ایالات متحده و روسیه سرعت صفحه متوسطی دارند. سرعت استرالیا، برزیل و هند کمتر از میانگین جهانی است.
صفحات دارای CDN از صفحاتی که CDN ندارند عملکرد بدتری دارند
یکی از شگفت آورترین یافته‌های ما این بود که صفحاتی که از CDN استفاده می کردند در حقیقت از آنها که از CDN استفاده نمی‌کردند، بدتر بودند.
چطور این اتفاق می‌افتد؟
از لحاظ تئوری، چون محتوا را نزدیک جایی که کاربرد قرار دارد تحویل می‌دهد، یک CDN باید سرعت صفحه را در طول بورد افزایش دهد.
با این حال، این مورد در تجزیه و تحلیل ما این گونه نبود.
ما فرض کردیم که همه CDNها برابر ساخته نشدند. در بسیاری از موارد، استفاده از یک CDN با بهینه‌سازی ضعیف در واقع می‌تواند سرعت را کاهش دهد.
و زمانی که ما عملکرد ۱۸ نفر برتر از ارائه دهندگان برتر CDN را تجزیه و تحلیل کردیم، اختلاف بزرگی را در عملکرد کشف کردیم.
به طور خاص، متوجه شدیم که (در دسکتاپ) بهترین سی دی ان، 3.6x برابر بهتر از بدترین 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, GitHub Pages, Google Cloud, KeyCDN, MaxCDN, Netlify
متوسط: Fireblade, Incapsula, Sucuri
بد: Akamai, ArvanCloud, Cloudflare
نکته کلیدی: استفاده از CDN به طور خودکار عملکرد سرعت صفحه را بهبود نمی‌بخشد. برخی از CDNها بطور قابل توجهی بهتر از سایرین عمل می کنند.
نتیجه گیری
اگر می‌خواهید بیشتر درباره چگونگی انجام این تجزیه و تحلیل بیاموزید. نگاهی به فایل PDFهای متدهای مطالعه ما بیندازید.
حالا دوست دارم از شما بشنوم:
کدام یک از یافته‌های این مطالعه به نظر شما متمایز بود؟
یا
قصد دارید در کدام مورد اقدام کنید؟
در هر صورت، نظر خود را با گذاشتن کامنت به بگویید.
منبع: