دسته: بلاگ

چگونه 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

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

LCP چیست؟

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

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

Largest Contentful Paint
Largest Contentful Paint

چه امتیاز LCP خوب است؟

طبق استانداردی که گوگل در Web Vital تعریف کرده است، برای اینکه کاربر از تجربه کاربری خوبی در سایت بهره ببرد، باید 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

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

سه پارامتری که در 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 استفاده نکنید.

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

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

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

شبیه ساز موبایل گوگل کروم

جهت استفاده از شبیه ساز موبایل مرورگر کروم، ابتدا با فشردن دکمه F12 در گوگل کروم، وارد محیط DevTools شوید و سپس با انتخاب آیکون موبایل و یا فشردن Ctrl+Shift+M در محیط ویندوز و Cmd+Shift+M در سیستم عامل مکینتاش، شبیه ساز موبایل کروم باز خواهد شد و می توان صفحه وب مورد نظر را در ابعاد یک گوشی موبایل، تبلت (با قابلیت انتخاب مدل گوشی و همچنین امکان نوشتن سایز مورد نظر در حالت Responsive) مشاهده نمود.
جهت آموزش دیباگ کردن صفحه با مرورگر گوگل کروم، به صفحه “آموزش شبیه ساز موبایل Google Chrome” مراجعه کنید.

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

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

مرحله 1: فعال کردن Developer options در دستگاه اندروید

Developer options در اندروید نسخه 4.1 به قبل به طور پیش فرض فعال است و از اندروید 4.2 به بعد، باید آن را به صورت دستی فعال کرد.

نکته: این آموزش بر اساس گوشی Nokia 7.1 با سیستم عامل اندروید تهیه شده است. احتمال دارد که گزینه Build number در مکان دیگری از تنظیمات گوشی وجود داشته باشد. برخی از دستگاه های اندرویدی مانند سامسونگ، ممکن است تنظیمات بیشتری نیاز داشته باشند.

برای انجام این کار ابتدا وارد قسمت About (درباره دستگاه) در تنظیمات گوشی اندروید شده و 7 مرتبه روی Build number (شماره ساخت) ضربه بزنید. سپس پیغامی مبنی بر You are now a developer! به شما نمایش داده خواهد شد.

مراحل فعال سازی Developer options در دستگاه اندرویدی
مراحل فعال سازی Developer options در گوشی موبایل با اندروید 10

فعال سازی Developer options در نسخه های مختلف اندروید

سیستم عامل اندروید 9 و بالاتر:

Settings > About Phone > Build Number

سیستم عامل اندروید 8.0.0 و اندروید 8.1.0:

System > About Phone > Build Number

سیستم عامل اندروید 7.1 و پایین تر:

Settings > About Phone > Build Number

مرحله 2: فعال کردن USB debugging در دستگاه اندروید

وارد منوی System در تنظیمات اندروید شوید و در Developer options گزینه USB debugging را فعال کنید.

فعال سازی USB debugging در Developer options
فعال سازی USB debugging در Developer options در اندروید 10

فعال سازی USB debugging در نسخه های مختلف اندروید

سیستم عامل اندروید 9 و بالاتر:

Settings > System > Advanced > Developer Options > USB debugging

سیستم عامل اندروید 8.0.0 و اندروید 8.1.0:

Settings > System > Developer Options > USB debugging

سیستم عامل اندروید 7.1 و پایین تر:

Settings > Developer Options > USB debugging

مرحله 3: صفحه Devices را در گوگل کروم باز کنید.

در مرورگر گوگل کروم به آدرس chrome://inspect/#devices بروید.

رفتن به صفحه Devices در مرورگر گوگل کروم دسکتاپ
رفتن به صفحه Devices در مرورگر گوگل کروم دسکتاپ

نکته: در قبل از گوگل کروم نسخه 80، برای دسترسی به صفحه devices باید از طریق DevTools اقدام می شد ولی از کروم نسخه 80 دسترسی به صفحه مذکور فقط از طریق آدرس chrome://inspect/#devices امکان پذیر است.

مرحله 4: اطمینان از فعال بودن Discover USB devices در صفحه Devices

در صفحه Devices، از فعال بودن گزینه Discover USB devices اطمینان حاصل کنید.

اطمینان یافتن از فعال بودن گزینه Discover USB devices
اطمینان یافتن از فعال بودن گزینه Discover USB devices

مرحله 5: اتصال گوشی به کامپیوتر

گوشی را با استفاده از کابل USB به کامپیوتر متصل نمایید. سپس پیغام “Allow USB debugging” بر روی گوشی نمایش داده می شود که باید آن را Accept کنید.

پذیرفتن پیام Allow USB debugging بر روی گوشی
پذیرفتن پیام Allow USB debugging بر روی گوشی اندروید

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

نمایش مدل گوشی اندروید و ورژن کروم موبایل در مرورگر کروم دسکتاپ
نمایش مدل گوشی اندروید و ورژن کروم موبایل در مرورگر کروم دسکتاپ

نکته: در قسمت تنظیمات صفحه نمایش در موبایل و کامپیوتر، هر دو دستگاه را در وضعیتی قرار دهید که به حالت sleep نروند.

مرحله 6: باز کردن صفحه وب بر روی گوشی موبایل (دستگاه اندرویدی)

صفحه وب مورد نظر را بر روی مرورگر کروم گوشی باز کنید. سپس در صفحه Devices نام همان صفحه به شما نمایش داده خواهد شد.

نمایش نام صفحه وب باز شده در گوشی اندروید
نمایش نام صفحه وب باز شده در گوشی اندروید

مرحله 7: باز کردن URL بر روی موبایل توسط DevTools

در DevTools، قسمت New tab یک URL وارد کنید و بر روی Open، کلیک نمایید. سپس مشاهده می کنید که همان URL در گوشی شما بر روی یک تب جدید باز می شود.

وارد کردن URL در دسکتاپ و باز شدن آن در کروم موبایل
وارد کردن URL در دسکتاپ و باز شدن آن در کروم موبایل

مرحله 8: باز کردن DevTools مرورگر کروم موبایل توسط مرورگر گوگل کروم کامپیوتر

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

DevTools گوگل کروم موبایل بر روی کروم دسکتاپ
DevTools گوگل کروم موبایل بر روی کروم دسکتاپ

به قسمت Elements در DevTools جدیدی که باز شده است، بروید. با hover بر روی یکی از المان های صفحه، آن قسمت در گوشی شما هایلایت می شود. با ضربه زدن بر روی یک المان صفحه در گوشی، می توانید آن بخش را در Elements انتخاب کنید. بر روی Select element در DevTools کلیک کرده و پس از آن بر المنت در گوشی اندرویدی خود ضربه بزنید. توجه داشته باشید که پس از هر مرتبه انتخاب، Select element غیرفعال شده و برای استفاده مجدد از آن، باید بر روی Select element کلیک نمایید.

گزینه Select element در DevTools مرورگر گوگل کروم
گزینه Select element در DevTools برای انتخاب المان های صفحه وب

با کلیک بر روی Toggle screencast می توانید محتوای صفحه گوشی خود را بر روی کامپیوتر مشاهده نمایید.

گزینه Toggle screencast در DevTools مرورگر گوگل کروم
گزینه Toggle screencast در DevTools برای مشاهده صفحه وب باز شده در مرورگر کروم گوشی

نکته: شما می توانید به امکاناتی مانند reload، focus و close a tab نیز دسترسی داشته باشید.

پرسش های متداول در مورد دیباگ صفحه با گوشی موبایل

1- آیا در صورت موفقیت آمیز بودن تست صفحه در شبیه ساز موبایل گوگل کروم، باز هم نیاز به ریموت دیباگینگ با گوشی اندروید است؟

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

2- آیا امکان ریموت دیباگینگ با کروم برای گوشی یا تبلت اپل و سیستم عامل iOS وجود دارد؟

خیر. در حال حاضر امکان remote debugging با گوگل کروم فقط برای گوشی و تبلت اندرویدی وجود دارد. البته شما می توانید با استفاده از مرورگر Safari و سیستم عامل MAC این کار را انجام دهید.

3- اگر در هنگام اتصال گوشی به کامپیوتر، پیام Allow USB Debugging مشاهده نشد، چه کاری انجام دهیم؟

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

4- گوشی را به کامپیوتر متصل کردم، ولی ویندوز آن را نشناخت. چه کاری باید انجام دهم؟

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

5- آیا می شود جهت اتصال گوشی به کامپیوتر از هاب USB استفاده کرد؟

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