Привіт, друзі!
Нещодавно прочитав цікавий тред від Barry Pollard (Web Performance Developer Advocate Google Chrome). Далі приводжу його основні думки.
Я часто бачу повільний LCP, спричинений дуже повільним TTFB.
Якщо ваш TTFB високий, як 2,6 секунди в цьому прикладі, то ви не можете отримати 2,5 секунди LCP, тому ви починаєте з задньої ноги.
Як
@csswizardry каже: "Хоча хороший TTFB не обов'язково означає, що у вас буде швидкий сайт,
поганий TTFB майже напевно гарантує повільний [сайт]".Зараз більшість людей зосереджуються на своєму бек-енді, намагаючись оптимізувати TTFB, оскільки, безсумнівно, саме це є причиною повільності.
Подивіться на свій хостинг, або посильте свої сервери, або оптимізуйте свою базу даних.
Іноді TTFB виникає не через ваш сайт, а через ваш трафік. Якщо є затримка навіть у відправленні запиту на ваш сервер, то незалежно від того, наскільки ви оптимізуєте свою технологію, ви не зможете це виправити.
Крім того, частина цього залежить від вас.
Причина такої повільності, поза оптимізацією серверів, зазвичай зводиться до одного з наступних факторів:
- Відстань - ваші програми знаходяться далеко від ваших серверів
- Перенаправлення - ваші користувачі долають довгий шлях до вашого сервера.
Зрозумійте своїх користувачів, звідки вони приходять і як вони потрапляють на ваш сайт, щоб зрозуміти, що саме він з себе представляє. Аналітика тут ваш друг.
І зосередьтеся на цільових сторінках вашого сайту, оскільки це найдорожчі сторінки з точки зору TTFB і LCP.Першу проблему (відстань) найкраще вирішити за допомогою CDN, щоб розмістити копію вашого сайту поруч з користувачем.
Друга проблема (перенаправлення) - це те, що ми також можемо покращити. Поговоріть зі своїми маркетологами і з'ясуйте, з яких джерел користувачі переходять на ваш сайт. Чи переходять вони через численні скорочувачі посилань.
Повний тред
https://twitter.com/tunetheweb/status/1745046170320126243