دسته: سئو

بهینه سازی بیشتر با استفاده از prefers-reduced-data

بهینه سازی بیشتر با استفاده از prefers-reduced-data

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

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

prefers-reduced-data یک تکنولوژی experimental یا آزمایشی است که هنوز به صورت گسترده مورد استفاده قرار نگرفته است و می تواند به کاربرانی که با کندی لود صفحات مواجه هستند کمک می کند که تجربه کاربری بهتری از نظر سرعت لود داشته باشند. برای اینکه prefers-reduced-data را بهتر درک کند، لازم است که save-data request header را بشناسید.

save-data request header چیست؟

save-data یک HTTP request header است که بیانگر این است که تنظیمات مرورگر کاربر در حالت استفاده از دیتای کمتر برای لود صفحات یا همان  است. مرورگر می تواند save-data: on را در HTTP request header به سرور ارسال کند و دلیل آن می تواند کانکشن با سرعت کم، کندی ناشی از رم و پردازنده ضعیف و یا هر دلیل دیگری که منجر به کندی سرعت لود صفحه شود، باشد.

در نمونه زیر می توانید save-data: on را در request header مشاهده کنید:

Host: webyooz.com
accept-encoding: gzip, deflate, br
save-data: on

کدام مرورگرها از Save-data پشیبانی می کنند؟

طبق مستندات موزیلا، بیشتر مرورگرهای معروف از save-data request header پشتیبانی می کنند. مرورگر گوگل کروم از ورژن 49 از save data پشتیبانی می کند و در حال حاضر تنها مرورگر معروفی که از save-data پشتیبانی نمی کند، مرورگر Safari شرکت اپل است.

مقایسه مرورگرهایی که از save-data پشتیبانی می کنند
مقایسه مرورگرهایی که از save-data پشتیبانی می کنند

مدیا کوئری چیست؟

توسط مدیا کوئری می توانیم شرایطی را برای لود شدن یک داکیومنت تعیین کنیم. به عنوان نمونه می توانیم از عرض viewport، نوع دستگاه یا جهت دستگاه (افقی یا عمودی) به عنوان شرایط لود یک داکیومنت استفاده کنیم. مدیا کوئری در طراحی سایت موبایل فرندلی بسیار کاربردی است.

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

نمونه های مدیا کوئری:

@media only screen and (max-width: 768px) {
body {
background-color: green;
}
}

@media only screen and (orientation: landscape) {
body {
background-color: green;
}
}

@media print {
body {
background-color: white;
}
}

مدیا کوئری prefers-reduced-data

آقای اندی عثمانی در همایش گوگل دولوپر سال 2019، مدیا کوئری prefers-reduced-data را معرفی کرد. ایشان توضیح داد که مدیا کوئری prefers-reduced-data به شما این امکان را می دهد که بتوانید یک ورژن با حجم کمتر یا data-reduced از سایت خود را برای کاربرانی که مشکل سرعت لود دارند را طراحی کنید.

اندی عثمانی در حال صحبت در مورد prefers-reduced-data در همایش توسعه دهندگان گوگل سامیت 2019
اندی عثمانی در حال صحبت در مورد prefers-reduced-data در همایش توسعه دهندگان گوگل سامیت 2019

prefers-reduced-data می تواند “reduce” یا “no-preference” باشد. reduce به معنی آن است که کاربر، data saver را روشن کرده است و یا به عبارت دیگر، درخواست های کاربر با save-data: on به سرور فرستاده می شود. No-preference بیانگر این است که درخواست های کاربر به وب سرور بدون save-data: on است.

کدام مرورگر ها از prefers-reduced-data پشتیبانی می کنند؟

prefers-reduced-data یک تکنولوژی experimental یا آزمایشی است. مرورگرها گوگل کروم 86+ و گوگل کروم اندروید 85+ و مایکروسافت Edge کرومیوم 85+ از این تکنولوژی پشتیبانی می کنند. بنابراین از prefers-reduced-data به صورت هوشمندانه استفاده کنید.

از prefers-reduced-data می توان مانند مدیاکوئری های دیگر استفاده کرد. به عنوان نمونه شما می توانید از prefers-reduced-data در CSS یا در HTML استفاده کنید.

چگونه از مدیا کوئری prefers-reduced-data در HTML استفاده کنیم؟

همان طور که گفتیم، prefers-reduced-data می تواند در HTML نیز به کار برده شود. به عنوان نمونه امکان استفاده از آن در تگ <picture> و <link> و هر جای دیگری که امکان استفاده از مدیا کوئری وجود داشته باشد هست.

در نمونه زیر، فایل font.woff2 تنها زمانی preload می شود که data-saver روشن نباشد یا به عبارت دیگر save-data: on در HTTP request header نباشد.

<head>
<link rel="preload" href="font.woff2" as="font" media="(prefers-reduced-data: no-preference)" crossorigin>
</head>

در نمونه زیر، کاربران با سرعت لود صفحه پایین یا سرعت اینترنت کم یا در حالت روشن بودن data saver مرورگر، عکس data-sever-on.png را خواهند دید و دیگر کاربران نیز عکس data-sever-off.png را مشاهده خواهند کرد.

<picture>
<source media="(prefers-reduced-data: reduce)" srcset="/data-sever-on.png" type="image/png" >
<source media="(prefers-reduced-data: no-preference)" srcset="/data-sever-off.png" type="image/png">
<img src="/data-sever-off.png" alt="prefers data savar test image" width="618" height="314">
</picture>

HTML picture element with or without save data HTTP request header

چگونه از مدیا کوئری prefers-reduced-data در CSS استفاده کنیم؟

در نمونه زیر، از آنجایی که مدیا کوئری prefers-reduced-data: no-preference به معنی این است که save-data: on در request header وجود نداشته باشد، می توانیم از نوشتن این مدیا کوئری صرف نظر کنیم و فقط از مدیا کوئری prefers-reduced-data: reduce برای لود عکس small-image.jpg برای درخواست هایی که با save-data: on ارسال می شود استفاده کنیم.

@media (prefers-reduced-data: reduce) {
/* Save-Data: On */
.body {
background-image: url("small-image.jpg");
}
}

@media (prefers-reduced-data: no-preference) {
/* Save-Data: Off */
.body {
background-image: url("large-image.jpg");
}
}

چگونه prefers-reduced-data را در گوگل کروم شبیه سازی کنیم؟

جهت فعال کردن شبیه سازی prefers-reduced-data در گوگل کروم نسخه 86 به بعد، طبق راهنمای زیر عمل نمایید:

1- قابلیت experimental web platform features گوگل کروم 86+ را فعال کنید.

به آدرس chrome://flags/#enable-experimental-web-platform-features بروید و Experimental Web Platform features را در حالت Enabled قرار داده و بروزر خود را ببندید و مجدد باز کنید.

فعال کردن Experimental Web Platform Features در گوگل کروم
فعال کردن Experimental Web Platform Features در گوگل کروم

2- command menu را در DevTools گوگل کروم باز کنید.

ابتدا با فشار دادن دکمه های Control+Shift+C یا دکمه F12 در ویندوز، لینوکس یا کروم OS، یا با فشار دادن دکمه های Command+Option+C محیط DevTools گوگل کروم را باز کنید. سپس با فشردن دکمه های Control+Shift+P منوی command را باز کنید و کلمه render را تایپ کنید و روی گزینه Show Rendering کلیک نمایید.

منوی کامند در DevTools گوگل کروم
منوی کامند در DevTools گوگل کروم

3- روی تب Rendering کلیک کنید.

تب Rendering در DevTools گوگل کروم
تب Rendering در DevTools گوگل کروم

4- گزینه prefers-reduced-data: reduce را در Emulate CSS media feature انتخاب کنید

در قسمت Emulate CSS media feature prefers-reduced-data، گزینه No emulation را به “prefers-reduced-data: reduce

Change “No emulation” to “prefers-reduced-data: reduce” from the “Emulate CSS media feature prefers-reduced-data” drop down.

انتخاب prefers-reduced-data در تب Rendering در DevTools گوگل کروم
انتخاب prefers-reduced-data در تب Rendering در DevTools گوگل کروم

نکته: با توجه به اینکه تعداد 5 عدد Emulate CSS media محتلف در تب Rendering وجود دارد، دقت کنید که تغییر لازم را در گزینه Emulate CSS media feature prefers-reduced-data انجام دهید.

نمونه عملی برای prefers-reduced-data

اگر طبق راهنمای بالا، شبیه ساز prefers-reduced-data را در حالت reduce یا در حالت No emulation بگذارید، با هر بار سوییچ کردن گزینه های مذکور، بدون ریلود شدن صفحه، عکس زیر تغییر خواهد کرد. فقط دقت داشته باشید که این امکان در گوگل کروم نسخه 86 به بعد وجود دارد.nt images. HTML picture element with or without save data HTTP request header

جمع بندی

prefers-reduced-data یک تکنولوژی آزمایشی است که امکان داشتن تجربه کاربری یا UX بهتر را برای کاربرانی که به هر دلیل با مشکل کندی لود صفحه مواجه هستند می دهد. صفحاتی که با prefers-reduced-data لود می شوند، در حقیقت با استفاده از دیتای کمتر نسبت به حالتی که مشکل کندی سرعت وجود ندارد، صفحه را در اختیار کاربر قرار می دهند. از آنجایی که prefers-reduced-data یک مدیا کوئری است، شما می توانید از آن در هر المانی که از مدیا کوئری پشتیبانی می کند استفاده کنید. به عنوان نمونه می توانیم به <picture> و <video> و <link> اشاره کرد.

پرسش های متداول در مورد prefers-reduced-data

1- آیا همه مرورگر های از prefers-reduced-data پشتیبانی می کنند؟

خیر. در حال حاضر مرورگر های گوگل کروم نسخه 86 به بعد در دسکتاپ و گوگل کروم نسخه 85 به بعد در اندروید و مرورگر Microsoft Edge Chromium نسخه 85 به بعد از prefers-reduced-data پشتیبانی می کنند.

2- آیا می توانیم از prefers-reduced-dataجهت بارگذاری فرمت های مختلف ویدیو استفاده کنیم؟

شما می توانید از prefers-reduced-data در هر المانی که از مدیا کوئری پشتیبانی می کند استفاده کنید. به عنوان نمونه امکان استفاده از prefers-reduced-data در تگ video، picture، link و CSS وجود دارد.

3- چگونه می توانیم prefers-reduced-data را روی دسکتاپ تست کنیم؟

امکان شبیه سازی prefers-reduced-data در DevTools گوگل کروم نسخه 86 به بعد در ویندوز، لینوکس یا مک وجود دارد.

چگونه FID را اپتیمایز کنیم

چگونه FID را اپتیمایز کنیم؟

برای اندازه گیری سرعت پاسخگویی صفحه وب در مقابل تعامل کاربر، المانی به نام First Input Delay (FID) وجود دارد. First Contentful Paint (FCP) و Largest Contentful Paint (LCP)، هر دو معیارهایی برای اندازه گیری زمان رندر یک صفحه هستند. نکته مهمی که در مورد این دو معیار وجود دارد، این است که این دو معیار، سرعت پاسخ یک صفحه نسبت به عمل یک کاربر را اندازه گیری نمی کنند بنابراین برای اندازه گیری این سرعت، از FID استفاده می کنیم.

FID یکی دیگر از معیارهای اندازه گیری در Core Web Vitals می باشد که اولین تعامل و پاسخگویی یک صفحه وب با کاربر را اندازه گیری می کند. FID، بازه زمانی را که یک کاربر برای اولین بار با یک صفحه وب تعامل برقرار می کند تا زمانی که یک مرورگر قادر به پاسخگویی به دستورات کاربر باشد را اندازه گیری می کند. برای اندازه گیری میزان تاخیر در پاسخگویی به دستورات کاربر، به یک تعامل واقعی کاربر نیاز است. برای کسب اطلاعات بیشتر در مورد سه معیار اندازه گیری عملکرد یک صفحه می توانید مطلب LCP و FID و CLS در Web Vitals را مطالعه کنید.

First Input Delay

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

اجرای جاوااسکریپت های سنگین

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

کاهش میزان جاوااسکریپتی که بر روی یک سینگل پیج لود می شود، از طریق شکستن آن به task های کوچیکتر و غیر همزمان، تاثیر بسزایی در کاهش FID خواهد داشت.

شکستن Long Task ها

Long Task ها، بازه های زمانی اجرای جاوااسکریپت می باشند که ممکن است منجر به غیر پاسخگو بودن یک صفحه از دید کاربر شود. هر قطعه کدی که thread اصلی را به مدت 50 میلی ثانیه یا بیشتر بلاک کند، یک task طولانی محسوب می شود. Long Task ها، نشانه لود و اجرای جاوااسکریپت بیش از نیاز یک کاربر در آن صفحه می باشند. بنابراین قطعه بندی جاوااسکریپت ها می تواند در کاهش delay input موثر باشد.

Long tasks در DevTools گوگل کروم در پنل Performanc
Long tasks در DevTools گوگل کروم در پنل Performance

بهینه سازی صفحه وب برای interaction readiness

دلایل زیادی برای ضعیف بودن امتیاز FID در وب اپ ها وجود دارند که به جاوااسکریپت ها بستگی دارند:

تاثیر اجرای اسکریپت های First-party در تاخیر interaction readiness

اجرای اسکریپت های First-party (اسکریپت های اصلی که با فشردن F12 کیبورد می توانیم آنها را در DevTools مشاهده کنیم) می تواند باعث تاخیر interaction readiness شود.
سایز زیاد جاوااسکریپت و دفعات زیاد اجرای فایل های سنگین جاوااسکریپت می تواند زمان پاسخگویی یک صفحه وب به دستورات (تعاملات) کاربر را کاهش داده و بر روی امتیازات FID، Total Blocking Time (TBT) و Time To Interactive (TTI) تاثیر بگذارد. اجرای تصاعدی کدها می تواند باعث بهبود interaction readiness گردد.

در تصویر زیر، امتیازات TBT، قبل و بعد از اپتیمایز کردن لود اسکریپت های First-party برای یک اپلیکیشن آمده است. همانطور که مشاهده می کنید، با انتقال لود اسکریپت های غیر ضروری به مسیرهای غیر بحرانی، کاربران قادر هستند تا با صفحه، خیلی زودتر تعامل پیدا کنند.

امتیاز TBT، قبل و بعد از اپتیمایز کردن لود اسکریپت های First-party
امتیاز TBT، قبل و بعد از اپتیمایز کردن لود اسکریپت های First-party

تاثیر اجرای اسکریپت های Third-party در افزایش interaction latency

عواملی چون تگ های Third-party و آنالیتکیس که باعث مشغول شدن شبکه و thread اصلی می گردند، نیز می توانند بر روی زمان تاخیر تعاملات کاربر تاثیر بگذارند.

در برخی از موارد، اسکریپت های Third-party به علت اولویت اجرا و پهنای باند مصرفی در thread اصلی، مانع از اجرای اسکریپت های First-party می شوند و همچنین باعث تاخیر در سرعت پاسخگویی به تعامل (interaction) می گردند. بنابراین سعی کنید تا لود اسکریپت ها را به خوبی اولویت بندی کنید تا میزان تاخیر در پاسخگویی به کاربران را به حداقل برسانید.

استفاده از Web Worker

یکی از دلایل اصلی Input delay، مسدود بودن thread اصلی است. استفاده از Web workers این امکان را به وجود می آورد تا جاوااسکریپت ها در یک thread فرعی یا ثانویه اجرا شوند و اینگونه با انتقال عملیات های غیر مرتبط به UI به یک thread جداگانه، مدت زمان مشغول و مسدود بودن thread اصلی کاهش می یابد و بر روی امتیاز FID تاثیر قابل توجهی خواهد داشت.

کاهش زمان اجرای جاوااسکریپت

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

برای کاهش مقدار جاوااسکریپت در یک صفحه می توان جاوااسکریپت هایی که در Above-the-fold صفحه کاربرد ندارند را Defer نمود.

Defer (به تعویق انداختن اجرا) جاوااسکریپت های بدون استفاده

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

Defer کردن هرگونه جاوااسکریپت غیر ضروری از جمله اسکریپت های Third-party با استفاده از defer یا استفاده از async برای جلوگیری از بلاک شدن رندر‎

<script defer src="…"></script>
<script async src="…"></script>

‎همانگونه در ویدیوی زیر مشاهده می کنید، در صورت استفاده از async در تگ <script>، اسکریپت های موجود در صفحه، کاملا مستقل هستند و رندر صفحه برای async scripts ها به تعویق نمی افتد. اسکریپت های که با defer در تگ <script> قرار می گیرند، رندر صفحه را بلاک نمی کنند و هر زمان که DOM آماده بود، اجرا می شوند اما این اتفاق پیش از DOMContentLoaded می افتد.‎‎

با فشردن کلید F12 در گوگل کروم به محیط DevTools بروید، سپس با فشردن کلیدهای Ctrl+Shift+P در ویندوز و Command+Shift+P در مک، باکس run command را باز کنید و پس از آن با سرچ Coverage می توانید این گزینه را به کنسول DevTools اضافه نمایید.

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

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

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

جاوااسکریپت های بدون استفاده در تب Coverage در DevTools
جاوااسکریپت های بدون استفاده در تب Coverage در DevTools

جمع بندی

FID یکی از معیارهای Core Web Vitals می باشد که مدت زمان اولین تعامل کاربر با یک صفحه وب و پاسخگویی صفحه به درخواست وی را اندازه گیری می کند. هرچه این مدت زمان کوتاهتر باشد، سرعت پاسخگویی به درخواست کاربر، بیشتر بوده و در نتیجه امتیاز FID، بهتر خواد بود. عدم اجرای جاوااسکریپت های غیر ضروری در یک صفحه و دسته بندی باندل جاوااسکریپت به قطعات کوچکتر، تا حد زیادی در امتیاز FID تاثیرگذار هستند.

اپتیمایز کردن Largest Contentful Paint

چگونه LCP را اپتیمایز کنیم؟

پارامترهای مختلفی برای اندازه گیری سرعت رندر صفحه یا محتوا وجود دارند. یکی از پارامترها که تا قبل از ماه می 2020 توسط گوگل استفاه می شد، پارامتر FCP یا First Contentful Paint بود که بیانگر مدت زمانی است که اولین محتوای صفحه رندر شود. معیار FCP هنوز برای اندازه گیری Performance صفحه استفاده می شود ولی گوگل در آپریل 2020 پارامتر دیگری به نام LCP که مخفف Largest Contentful Paint را معرفی کرد که کارایی آن از FCP بیشتر است.

LCP چیست؟

پارامتر LCP بیانگر مدت زمانی است که مهمترین المان صفحه در viewport دستگاه کاربر، رندر شود. مهمترین المنت می تواند یک عکس، یک ویدیو و یا یک متن باشد که در حقیقت مهمترین قسمت صفحه از دید کاربر است و در نتیجه هر چقدر سریعتر لود و رندر شود، تاثیر مثبتی در تجربه کاربری یا UX دارد.

LCP بهینه چند ثانیه است؟

با توجه به استانداردی که گوگل در حال حاضر مشخص کرده است و بر اساس آن نیز گزارش Core Web Vitals در گوگل سرچ کنسول را ارائه می کند، در صورتیکه محتوای اصلی صفحه در کمتر از 2.5 ثانیه لود و رندر شود، امتیاز LCP را به صورت کامل دریافت می کنید و اگر این مدت زمان بین 2.5 تا 4 ثانیه باشد، نیاز است که نسبت به بهبود LCP اقدام شود و در صورت بیشتر از 4 ثانیه بودن زمان LCP، وضعیت صفحه از نظر LCP ضعیف است و بهتر است که برای بهبود آن برنامه ریزی جدی داشته باشید.

Largest Contentful Paint

از کجا بدانیم که کدام المان صفحه در LCP تاثیرگذار است؟

یکی از راه های اینکه متوجه شوید که از نظر Core Web Vitals گوگل، کدام المان صفحه به عنوان مهمترین المان صفحه در نظر گرفته می شود، استفاه از Lighthouse نسخه 6 به بعد است. به عنوان مثال می توانید از سایت WebPageTest برای آنالیز صفحه با Lighthouse استفاده کنید. در نتیجه گزارش Performance لایت هاوس، با توجه به عکس زیر، یک قسمت به نام Largest Contentful Paint element وجود دارد که با کلیک بر روی آن می توانید متوجه شوید که Lighthouse از کدام المان صفحه در محاسبه LCP استفاده کرده است.

Largest Contentful Paint element
Largest Contentful Paint element

ضمنا در DevTools گوگل کروم نیز با توجه به ویدیو زیر در قسمت Performance می توانید با کلیک بر روی LCP، المانی که در viewport به عنوان LCP مد نظر بوده را مشاهده کنید.

مهمترین عوامل تاثیر گذار در LCP

عوامل زیادی در LCP تاثیر گذار هستند که در ادامه در مورد مهترین آنها توضیح داده شده است:

1. کند بودن زمان پاسخ گویی سرور

زمان پاسخ گویی سرور یا همان Slow server response times یکی از عوامل تاثیرگذار در LCP است. هر چقدر مرورگر بتواند محتوا را سریعتر از سرور دریافت کند، صفحه سریعتر رندر خواهد شد و هر چقدر صفحه سریعتر رندر شود، پارامترهایی که برای اندازه گیری سرعت لود صفحه هستند، بهبود می یابند و یکی از آن پارامترها، Largest Contentful Paint است.

یکی از مواردی که برای بهبود سرعت پاسخ گویی سرور باید در نظر داشت، پارامتر TTFB یا Time To First Byte است که برای بهبود آن نیاز است که موارد زیر را مد نظر داشته باشید:

  • اپتیمایز کردن سرور از نظر سخت افزاری
  • بهینه کردن دیتابیس و کوئری ها
  • بهینه کردن کدهای سمت سرور با هدف ارتقا سرعت لود صفحات
  • کش کردن صفحات و asset ها به صورت HTML بر روی سرور
  • ایجاد کانکشن زودهنگام با third-party ها (به عنوان نمونه با قرار دادن <link> های زیر در <head>)

<link rel="preconnect" href="https://example.com">

<link rel="dns-prefetch" href="https://example.com">

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

تاثیر preconnect بر زمان دانلود
تاثیر preconnect بر زمان دانلود

2. وجود جاوااسکریپت و CSS های که رندر را بلاک می کنند

در صورتیکه فایل های JavaScript یا CSS وجود داشته باشند که Render blocker تلقی شوند، باعث به تعویق افتادن رندر صفحه خواهند شد و در نتیجه امتیاز LCP را کاهش می دهند. برای بهبود این موضوع از تکنیک های زیر استفاده کنید:

  • فایل های CSS را minify کنید
  • فایل های js را minify کنید
  • CSS هایی که برای رندر above-the-fold صفحه استفاده می شوند (Critical CSS) را inline کنید.
  • لود شدن CSS های non-critical را به تعویق بیندازید (defer کنید)
  • لود شدن JavaScript های non-critical را به تعویق بیندازید (defer کنید)
  • CSS هایی که در صفحات استفاده نمی شوند را حذف کنید.

3. کند بودن سرعت لود منابع

سرعت لود المان های <img> و <video> به همراه عکس پوستر ویدیو، <image> در <svg>، المان های با بکگراند که از url() استفاده کرده باشند و همچنین المان های Block-level در LCP تاثیرگذار هستند. بنابراین توصیه می کنم که از موارد زیر برای بهینه کردن سرعت بارگذاری موارد ذکر شده استفاده کنید:

  • اپتیمایز کردن عکس ها
  • استفاده از فرمت های مدرن عکس مانند JPEG 2000 یا JPEG XR یا WebP
  • استفاده از عکس های رسپانسیو
  • در صورت امکان، استفاه نکردن از یک عکس به عنوان اولین المان مهم صفحه
  • کمپرس کردن متن ها با استفاده از تکنیک هایی مانند Gzip یا Brotli
  • preload منابع مهم صفحه مانند نمونه های زیر:

<link rel="preload" as="script" href="important-script.js">

<link rel="preload" as="style" href="important-style.css">

<link rel="preload" as="image" href="important-image.png">

<link rel="preload" as="video" href="video.webm" type="video/webm">

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

بهبود LCP با فعال کردن Brotli
بهبود LCP با فعال کردن Brotli

منبع Web.dev

Web Vitals چیست

LCP و FID و CLS در Web Vitals

Core Web Vitals در آپریل 2020 توسط گوگل معرفی شد و حاوی سه پارامتر برای اندازه گیری Performance یا کارایی صفحه وب، Responsiveness یا سرعت پاسخگویی صفحه و همچنین سرعت لود صفحه است. پارامتر های Core Web Vitals به نام های LCP و FID و CLS هستند و هر سه تاثیر مستقیم در تجربه کاربری یا UX و رنکینگ دارند و توصیه می شود که سئوکاران به آنها توجه ویژه ای داشته باشند. نحوه محاسبات Core Web Vitals چندین بار نغییر کرده است و گوگل همیشه قصد دارد که علاوه بر بالا بردن دقت محاسبات، راه های فریب الگوریتم ها را نیز شناسایی و خنثی کند.

نکته: LCP و FID و CLS به صورت جداگانه برای موبایل و دسکتاپ محاسبه می شوند.

LCP چیست؟

همیشه سرعت لود صفحه برای سئوکارها و دولوپرها از اهمیت بالایی برخوردار است.‎ یکی از پارامترهای مهمی که برای بررسی سرعت بارگذاری صفحه از آن استفاده می شود، LCP است که در Core Web Vitals بیشتر به آن پرداخته شده است. LCP مخفف Largest Contentful Paint است و به معنای مدت زمانی است که صرف می شود تا بزرگترین المان محتوا در صفحه، لود و رندر و در viewport به کاربر نمایش داده شود.

پارامترهای قدیمی تر مانند Load یا DOMContentLoaded الزاما به معنی اینکه یوزر در چه زمانی می تواند محتوای اصلی را به صورت رندر شده ببیند نبود و حتی FCP یا همان First Contentful Paint که قبلا توسط گوگل معرفی شده بود نیز به دلیل اینکه بیانگر اولین محتوایی بود که در صفحه لود می شد، مانند LCP نمی تواند اطلاعات ارزشمندی در مورد UX کاربر به ما بدهد.

Largest Contentful Paint
Largest Contentful Paint

چه مدت زمانی به عنوان LCP مطلوب در نظر گرفته می شود؟

طبق استانداردی که گوگل در Core Web Vitals تعریف کرده است، برای اینکه کاربر از تجربه کاربری خوبی در سایت بهره ببرد، باید Largest Contentful Paint یا همان بزرگترین المان محتوا در کمتر از 2.5 ثانیه از زمان شروع لود صفحه، در صفحه نمایش کاربر رندر شده باشد.

بنابراین در صورتیکه LCP کمتر از 2.5 ثانیه باشد، صفحه مد نظر شما از نظر LCP دارای وضعیت مطلوبی است و اگر بین 2.5 تا 4 ثانیه باشد، نیاز به اصلاحات وجود دارد و اگر LCP بیش از 4 ثانیه بود، صفحه در وضعیت نامطلوبی قرار گرفته و بهتر است که هر چه سریعتر، بررسی های لازم در خصوص Largest Contentful Paint انجام شود.

کدام المان ها در LCP مد نظر گرفته می شود؟

در حال حاضر المان های زیر توسط LCP در نظر گرفته می شوند:

  • المان <img>
  • المان <image> درون یک المان <svg>
  • المان <video> (عکس پوستر ویدیو نیز در نظر گرفته می شود)
  • المانی که بکگراند عکس آن از طریق فانکشن url() بارگذاری شده باشد. مانند
    url(https://www.webyooz.com/wp-content/uploads/2020/05/largest-contentful-paint.jpg)
  • المان های Block Level در HTML که دارای متن هستند.

FID چیست؟

FID مخفف First Input Delay است و پارامتری است که برای اندازه گیری Load responsiveness است. از Load responsiveness برای اندازه گیری سرعت لود صفحه و اجرای جاوااسکریپت های لازم برای پاسخ گویی به تعامل کاربر استفاده می شود. هر چه کاربر بتواند سریعتر با صفحه تعامل داشته باشد، تجربه کاربری بهتری خواهد داشت.

به عبارت دیگر FID فاصله زمانی بین تعامل کاربر با صفحه (مانند کلیک روی یک لینک یا دکمه و یا tap کردن روی یک المان تعاملی) و زمانی است که مرورگر به تعامل کاربر پاسخ می دهد.

First Input Delay
First Input Delay

چه مدت زمانی به عنوان FID مطلوب در نظر گرفته می شود؟

همان طور که در تصویر بالا نیز مشاهده می کنید، در صورتی که FID صفحه کمتر از 100 میلی ثانیه باشد، صفحه از نظر First Input Delay در وضعیت مطلوبی است و اگر بین 100 تا 300 میلی ثانیه باشد، نیاز به انجام اصلاحات وجود دارد و در نهایت اگر FID بیشتر از 300 میلی ثانیه باشد، صفحه در وضعیت نامطلوبی قرار دارد و بهتر است که هر چه زودتر بررسی و اصلاح گردد.

CLS چیست؟

CLS مخفف عبارت Cumulative Layout Shift است و برای اندازه گیری Visual Stability استفاده می شود. برای درک بهتر، یک مثال می زنم. حتما برای شما پیش آمده که در حال خواندن یک صفحه هستید و قصد دارید روی یک لینک یا دکمه کلیک یا tap کنید و درست همان لحظه، متن یا یک لینک حرکت می کند و جابجا می شود و شما به اشتباه روی یک لینک دیگر کلیک می کنید. این جابجایی layout برای کاربر آزاردهنده است.

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

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

Cumulative Layout Shift
Cumulative Layout Shift

چه مدت زمانی به عنوان CLS مطلوب در نظر گرفته می شود؟

با توجه به تصویر بالا، در صورتی که زمان CLS کمتر از 0.1 ثانیه باشد، وضعیت صفحه از نظر Cumulative Layout Shift مطلوب است و اگر بین 0.1 تا 0.25 ثانیه بود، نیاز به اصلاح دارد و در صورتی که CLS بیشتر از 0.25 ثانیه بود، وضعیت نامطلوب است و بهتر است که تلاش کنید که این زمان را کاهش دهید.

ابزارهای اندازه گیری LCP و FID و CLS در Web Vitals

هر سه پارامتر LCP و FID و CLS در Web vitals که در مورد آنها صحبت شد، توسط ابزار Lighthouse که به عنوان مثال در PageSpeed Insights وجود دارد قابل اندازه گیری هستند. اطلاعات LCP و FID و CLS توسط CrUX که مخفف Chrome UX Report است جمع آوری می شود. همچنین می توانید این پارامتر ها را در گزارش Core Web Vitals سرچ کنسول مشاهده کنید.

ابزارهای اندازه گیری LCP و FID و CLS در Web Vitals
ابزارهای اندازه گیری LCP و FID و CLS در Web Vitals

همچنین می توانید از اکستنشن گوگل کروم Web Vitals نیز برای اندازه گیری سه پارامتر مذکور استفاده کنید.

Web Vitals Chrome Extension
Web Vitals Chrome Extension

جمع بندی در مورد Core Web Vitals:

سه پارامتری که در Core Web Vitals اندازه گیری می شوند در راستای بهبود تجربه کاربری هستند و دولوپرها و سئوکاران نیاز است که در جهت سئوی حرفه ای نگاه ویژه ای به آنها داشته باشند و تلاش کنند که دست کم 75 درصد از بازدیدهایی که دارند از نظر LCP و FID و CLS در وضعیت مطلوب باشند.

 

LCP و FID و CLS در Web Vitals
LCP و FID و CLS در Web Vitals

پرسش های متداول در مورد LCP و FID و CLS در Web Vitals

1- آیا سرعت هاست تاثیری در بهبود Largest Contentful Paint دارد؟

بله. هر چه سرعت هاست یا سرور بالاتر باشد و Response time سرور پایین تر باشد، امتیاز LCP بهتر خواهد بود.

2- آیا کمپرس کردن فایل های جاوااسکریپ تاثیری در بهبود پارامتر First Input Delay صفحه دارد؟

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

3- برای بهبود Cumulative Layout Shift چه نکاتی را در مورد عکس باید رعایت کنیم؟

همه عکس ها در HTML باید دارای ابعاد width و height باشند که مرورگر قبل از لود آنها، بداند که ابعاد عکسی که باید رندر کند چقدر است. اگر ابعاد عکس در HTML مشخص نشده باشد ممکن است کم منجر به تاثیر منفی در امتیاز CLS شود.

منبع: Web Vitals essential metrics for a healthy site 

سایت مپ

نقشه سایت

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

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

آیا شما به نقشه سایت احتیاج دارید؟

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

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

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

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

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

انواع فرمت نقشه سایت

گوگل از فرمت های مختلف سایت مپ پشتیبانی می کند. همه سایت مپ ها مجاز هستند که حداکثر حاوی 50 هزار URL باشند و سایز فایل آنها در حالت غیر فشرده از 50 مگابایت بیشتر نشود. منظور از حالت غیر فشرده، حالتی است که فایل نقشه سایت با تکنیک هایی مانند GZIP فشرده نشده باشد.

سایت مپ XML

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

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

<url>

<loc>http://www.example.com/foo.html</loc>

<lastmod>2020-04-24</lastmod>

</url>

</urlset>

RSS, mRSS, and Atom 1.0

اگر شما بلاگی دارید که از RSS یا Atom feed پشتیبانی می کند، شما می توانید آدرس همه feed ها را به عنوان سایت مپ به موتور جستجو معرفی کنید. گوگل از RSS نسخه 2 و Atom feed نسخه 1 پشتیبانی می کند. همچنین می توانید با استفاده از mRSS feed جزئیات محتوای ویدیویی سایت را به گوگل بدهید.

سایت مپ Text

اگر سایت مپ شما فقط حاوی URL است و هیچ متادیتایی در آن وجود ندارد، می توانید یک سایت مپ متنی با فرمت txt داشته باشید که در هر خط آن فقط یک URL وجود داشته باشد. توجه داشته باشید که:

• فایل سایت مپ متنی به صورت UTF-8 ذخیره شده باشد.

• فایل سایت مپ هر نامی مانند sitemap.txt می تواند داشته باشد.

• فایل متنی سایت مپ فقط می تواند شامل URL باشد مانند:

http://www.example.com/file1.html

http://www.example.com/file2.html

اصول کلی نقشه سایت

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

• آدرس ها نباید شامل پارامترهایی مانند session ID که تغییری در محتوای صفحه ایجاد نمی کنند باشند.

• نقشه های سایت بزرگ باید به تکه های کوچک تر تقسیم شوند. حداکثر تعدا URL در یک نقشه سایت تعداد 50000 آدرس و حداکثر سایز فایل نقشه سایت می تواند 50 مگابایت باشد. نقشه های سایت بزرگ را به تکه های کوچک تر تقسیم کنید و به جای یک فایل، چندین فایل نقشه سایت را به موتورهای جستجو معرفی کنید و یا یک نقشه سایت داشته باشید که در آن آدرس سایت مپ هایتان را مشخص کرده باشید.

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

• فایل نقشه سایت باید به صورت UTF-8 ذخیره باشد.

• نام فایل نقشه سایت و آدرس های URL درون نقشه سایت باید entity escaped باشند و نمی تواند شامل کاراکترهایی مانند * و { و } باشد. در جدول زیر 5 کاراکتر را می توانید مشاهده کنید که برای استفاده کردن از آنها باید از entity escaped آنها استفاده کنید.

نحوه استفاده از کاراکترهای ممنوعه در سایت مپ
نحوه استفاده از کاراکترهای ممنوعه در سایت مپ

معرفی نقشه سایت به گوگل

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

1- آدرس نقشه سایت را در فایل robots.txt به صورت زیر قرار دهید.

Sitemap: https://www.example.com/sitemap.xml

2- از طریق بخش Sitemaps در گوگل سرچ کنسول، نقشه سایت را به گوگل معرفی کنید.

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

http://www.google.com/ping?sitemap=https://example.com/sitemap.xml

تگ های استفاده شده در نقشه سایت

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

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

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

<url>

<loc>http://www.example.com/page1.html</loc>

<lastmod>2019-05-19T13:10:55+03:30</lastmod>

<changefreq>hourly</changefreq>

<priority>0.9</priority>

</url>

</urlset>

• استفاده از تگ های <urlset> و <url> و <loc> اجباری است.

• استفاده از تگ های <lastmod> و <changefreq> و <priority> اختیاری است.

• تگ اجباری <loc> باید با یک پروتکل مانند http یا https شروع شود و حداکثر تعداد کاراکتر مجاز آن 2048 عدد می باشد.

• تگ اختیاری <lastmod> بیانگر زمان آخرین تغییر صفحه است و از استانداردهای زمانی W3C پشتیبانی می کند. به عنوان نمونه فقط می توان تاریخ را مشخص کرد مانند 2020-05-01 و یا علاوه بر تاریخ، زمان دقیق را با مشخص کردن اختلاف زمان نسبت به GMT برای موتور جستجو مشخص کرد مانند 2020-05-01T22:10:58+03:30.

• تگ <changefreq> می تواند hourly، daily، weekly، yearly، never و always باشد. گزینه always هنگامی استفاده می شود که با هر بار باز کردن صفحه، همه یا بخشی از محتوای صفحه تغییر کند. مورد استفاده never نیز برای صفحاتی مانند صفحات آرشیو شده است که قرار نیست که دیگر تغییری بکنند.

• تگ <priority> نیز برای تعیین میزان اهمیت آدرس ها نسبت به یکدیگر استفاده می شود و مقدار آن از 0 تا 1.0 می باشد. از اوایل سال 2019 دیگر گوگل تگ <priority> را مد نظر قرار نمی دهد.

نقشه سایت عکس

این امکان وجود دارد که نقشه سایت را برای عکس های سایت نیز ایجاد کرد. نقشه سایت زیر یک نمونه از Image sitemap است.

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">

<url>

<loc>http://example.com/sample.html</loc>

<image:image>

<image:loc>http://example.com/image.jpg</image:loc>

<image:caption>Image Caption</image:caption>

<image:geo_location>Toronto, Canada</image:geo_location>

<image:title>Image Title</image:title>

</image:image>

</url>

</urlset>

تگ های استفاده شده در نقشه سایت عکس به شرح زیر می باشد:

• استفاده از تگ <loc> اجباری است و حاوی آدرس صفحه ای است که قصد دارید عکس های آن را در نقشه سایت معرفی کنید.

• استفاده از تگ <image:image> اجباری است و حاوی اطلاعات عکس است. هر تگ <loc> می تواند حداکثر 1000 تگ <image:image> داشته باشد.

• استفاده از تگ های <image:caption> و <image:title> اختیاری است و حاوی اطلاعات caption و title عکس است.

• استفاده از تگ <image:geo_location> اختیاری است و همانگونه که از نام آن مشخص است، این تگ حاوی موقعیت جغرافیایی عکس است.

• استفاده از تگ <image:license> اختیاری است و حاوی URL لایسنس عکس می باشد.

پرسش های متداول در مورد سایت مپ

1- آیا ایرادی دارد که سایت مپ را به صورت استاتیک ایجاد کنیم؟

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

2- سایت مپ من هر یک ساعت یکبار توسط افزونه در پرستاشاپ ایجاد می شود. آیا این کار درست است؟

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

3- تقسیم یک سایت مپ بزرگ به چند نقشه سایت چه مزیتی دارد؟

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

4- ایجاد سایت مپ توسط سایت های آنلاین و یا نرم افزار ایرادی دارد؟

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