Core web vitals — обичайните заподозрени

1. Page Speed Insights - The Usual Suspects
oa.netpeak.bg
June 23 | Sofia
Владимир Драгиев Петър Николов
CLS
FID LCP
TTFB
FCP

2. Владимир Драгиев
• Управляващ партньор в ID Consult с Благовест Йорданов
• Ex-Inhouse SEO експерт в NetInfo(сега външен контрактор)
и няколко агенции.
• 12+ години опит с SEO, SEM, Analytics, Data Collection
• Стандартните сертификати + няколко нестандартни ☺
• Нямам претенции да съм браншово гуру ☺
• Цел в живота: Вечно лято по северното Черноморие

3. Петър Николов
● Разработчик с над 19 години опит. Преди 6 години
основава своя собствена компания.
● От 7 години в Mobilio се занимава само с мобилни
разработки и десктоп приложения предимно за Apple
платформи.
● Привърженик е на Mobile First идеологията и вярва, че
тепърва ще се удивляваме на нови постижения на
мобилния фронт.

4. The Plot
1. Измерване на Pagespeed Insights през
потребителския браузър
1. Сегментиране - 4G, 3G, 2G, Slow 2G и др.
1. Четене на данните и визуализация
1. Оптимизиране

5. Как да измерим през
браузъра на
потребителите
• Google Chrome report-ва!
• Един екип от Google са ни улеснили като са направили
https://web-vitals-report.web.app/
• Скриптът се инсталира директно на сайта, но може и през
GTM

6. Разликата с Core Web Vitals в GSC, Pagespeed Insights и
Lighthouse и други
• Виждаме в GA потребителските данни в (почти) реално време и
лесно забелязваме къде са изкривяванията, за разлика от
симулираните данни, които дават инструментите.
• Не чакаме 30 дни, за да видим ефекта от промените по сайта.
• Работим на ниво цял сайт с огромна възможност за сегментиране
и значително по-висока ефективност.
• Значително повече данни в сравнение с API използването през
Screaming Frog или друг туул.

7. Имплементиране на
един конкретен код
• Стреля по 5 евента към GA на pageview!
• При много трафик към сайта трябва да се
семплира, защото удря hit limit-a на акаунта.
• Ако го слагате през GTM, трябва да посочите
ID-то на акаунта. A може да се оптимизира и да
стане по-елегантно, както посочи
Благовест.
• 2-4 седмици е оптимално време за замерване,
според зависи от количеството на трафика. Ако
е ниско, увеличете периода.

8. Сегментиране - 4G, 3G,
2G, Slow 2G
• Chrome report-ва effective connection type на
потребителя, понеже го измерва.
• Добавяме ги към event action името
• Видовете са 4:
4g - тук влизат и desktop и хората с бърз интернет
3g - и тук също има desktop
2g - учудващо, но и тук има desktop
Slow 2g - Зоната на здрача!

9. Четене на данните
• От GA гледаме композицията по скорост на връзката
на потребителите, като филтрираме по един action,
примерно FCP.
• На база на композицията - решаваме къде да се
концентрираме. В нашия пример 96% от
потребителите са на 4G, затова няма смисъл изобщо
да се занимаваме с другите скорости.
• Все пак, трябва да се съобразим с типа на бизнеса.
При сайт за пътна помощ, например, ситуацията би
била доста различна, там, искаме тези с 2g и slow-2g
да нямат никакъв проблем, докато ни търсят от гората
или пустинята.
• Ако имате отделни мобилни и десктоп страници,
внимавайте кое analytics view сте избрали!

10. Четене на данните
• Ако замерваме connection type - трябва да коригираме
имената на event-ите, за да видим данни.
• Сегментираме по mobile/desktop задължително.
Можем да сегментираме и по предварително
създадени сегменти в GA. Например,
логнати/нелогнати. Дори и googlebot-a да няма достъп
до въпросните страници зад логин, chrome ще
репортне скоростта на потребителя и ще я отнесе
към общото представяне на сайта, така че,
забързайте си админ панелите!

11. Визуализация
• В този пример ясно се вижда разликата в
дистрибуцията на LCP_4g във времето и
има очевидно забавяне при мобилните
устройства.
• Можем да следим как се отразяват
промените с времето, при това в реално
време!

12. Визуализация
• Идентична ситуация с предходната.
Видимо забавяне при мобилните на 4G,
докато при десктоп нещата работят
супер.

13. Визуализация
• Surprise, …!
• Нещо, някъде изкривява много лошо!
Сега ще видим какво.
• С течение на времето няма промяна,
значи е постоянен казус.

14. Оптимизация
• Винаги е добра идея да разгледаме по
държави.
• В случая в USA светим в червено за LCP,
което означава, че зареждането на някой
ресурс се бави там. Ако трафикът от там
е голям - трябва да направим нещо по
въпроса.
• Създаваме си сегмент за USA и почваме
да ровим в него.

15. Оптимизация
• Разглеждаме по страници и “светва”, че
всъщност имаме проблем на началната
страница и на друга страница, но само на
десктоп.
• За да се задълбаем в страниците, трябва
да отидем в GA.

16. Влизаме в Web Vitals event category, добавяме page като secondary dimension, филтрираме по CLS_4g, сортираме по total events и гледаме Avg. Value и
така ще изолираме кои страници правят проблем.
Оптимизация

17. Тук вече започваме с добре познатите ни стандартни методи за
оптимизация на скоростта на зареждане, които сме говорили хиляди
пъти:
● Работим на ниво страница с Lighthouse
● Емулираме съответния connection type
● Емулираме съответния device type
● Стараем се максимално да постигнем идентична тестова среда, при
която възниква съответния проблем
● След направа на промените следим данните и преценяваме дали е бил
достатъчен ефекта
Оптимизация

18. Thank you
Въпроси?
June 23 | Sofia
Владимир Драгиев
vlado@idconsult.bg
linkedin.com/in/vladimirdragiev/
idconsult.bg
Петър Николов
peter@mobiliodevelopment.com
linkedin.com/in/peternikolow/
mobiliodevelopment.com