Швидкість для одного і швидкість для тисячі — різні речі
PageSpeed 95 нічого не каже про те, що станеться під навантаженням. Він міряє одну сторінку для одного відвідувача на швидкому каналі. Реальне падіння виглядає інакше: усе гаразд до трьохсот людей, а на трьохстах пʼятдесяти час відповіді зростає з пів секунди до дванадцяти, і далі сайт просто перестає відповідати.
Найгірше, що це стається саме тоді, коли трафік нарешті прийшов: перший день розпродажу, ефір, згадка в новинах.
Що я роблю
Повторюю реальну поведінку. Не «тисяча запитів на головну» — так тестують для галочки. Сценарій включає те, що люди роблять насправді: дивляться каталог, відкривають картки, кладуть у кошик, оформлюють. Найважчі місця майже завжди не на головній.
Підіймаю навантаження поступово. Від десятків до сотень одночасних відвідувачів, поки не зʼявиться деградація. Фіксую точку, де час відповіді починає рости.
Показую, де саме вузько. Хостинг уперся в ліміт процесів? База не встигає з запитами каталогу? Зовнішній віджет тримає сторінку? У звіті — графіки й конкретна причина, а не «треба оптимізувати».
Найчастіші знахідки
Дешевий тариф хостингу з обмеженням на одночасні зʼєднання — виправляється за годину переходом на інший план. Запити до бази, які виконуються для кожного товару окремо замість одного разу. Сторонні скрипти — чат, аналітика, віджет відгуків, — які на повільному зʼєднанні блокують показ.
Приємна новина: більшість цього виправляється дешевше, ніж здається, і без переписування сайту.
Супровід події
Окремий формат, коли дата піку відома. Перед подією підсилюємо хостинг, у день я стежу за навантаженням наживо, після — повертаємо звичайний режим. Так ви не платите за потужність, яка потрібна тричі на рік.
Разом із іншим
Якщо сайт повільний сам по собі — спершу прискорення: навантажувальний тест на повільному сайті просто підтвердить те, що видно й так. Перевірку на вразливості можна зробити тим самим заходом — це опція, і разом виходить дешевше, ніж окремо.