Більшість із нас шукає відповіді на свої запитання в Google або питає штучний інтелект. Та чи можемо ми довіряти знайденій інформації?
Оскільки одна з наших основних спеціалізацій — робота над швидкістю сайтів, ми вирішили подивитися, що пишуть про це колеги по галузі. І були шоковані: серед перших результатів видачі не знайшлося жодного сайту, який би коректно відповідав на питання цієї теми.
Це пояснює й те, чому штучний інтелект на загальні запитання видає схожу, часто хибну інформацію — адже він навчається саме на таких сайтах. Щоб отримати від ШІ коректнішу відповідь, йому потрібно ставити доволі специфічне питання — те, яке навряд чи сформулює людина, яка тільки починає розбиратися в темі.
Інформація в тематичних статтях у кращому разі буває розкрита неповно й потребує уточнень. Наприклад, коли в одному переліку «обов'язкових» рекомендацій поруч подають речі, необхідні практично кожному сайту (як−от GZIP−стиснення), і речі, потрібні лише в рідкісних специфічних умовах (як−от CDN) — так, ніби все перераховане однаково необхідне кожному сайту.
Але трапляються й твердження, які виходять далеко за межі здорового глузду.
Імовірно, це пов'язано з тим, що подібні статті часто пишуть копірайтери, які самі не розбираються в темі. Хоча, якщо чесно, фахівців, які справді добре володіють питанням швидкості сайтів, теж небагато.
На подібних статтях вчаться й розробники — і згодом впроваджують речі, яких самі не розуміють. Ми нерідко стикаємося з цим у роботі й навіть ввели внутрішній термін для сайтів, що отримали проблеми через бездумне впровадження таких рекомендацій, — «жертва оптимізації».
Тож, щоб таких жертв оптимізації ставало менше, ми вирішили прокоментувати найбільш хибні тези з подібних статей, а також найпопулярніші твердження, які хоч і близькі до істини, але потребують уточнення.
Якою має бути швидкість сайту?
Почнемо з питання, за скільки секунд має завантажуватись ваш сайт. На різних ресурсах ці цифри відрізняються, але річ навіть не в конкретних цифрах — річ у тому, що граничного показника як такого не існує. Не можна сказати, що сайт, який завантажився за 2,9 секунди, — це добре, а за 3,1 секунди — вже погано. Швидкість — це параметр, який має сенс лише в порівнянні. Питання в тому, з чим саме порівнювати.
Можна порівнювати зі швидкістю конкурентів — якщо є ризик, що клієнт піде до них через повільніший сайт. Можна порівнювати із середньою швидкістю сайтів у своїй ніші — щоб розуміти, чого взагалі очікує типовий користувач. Можна порівнювати з нормою для конкретного технологічного стека чи двигуна сайту. А можна — з теоретичним ідеалом. Кожен із цих підходів по−своєму корисний і разом дає повну картину. Але жодного разу серед них немає точки, після якої про швидкість можна забути раз і назавжди — бо сама швидкість нестабільна: завтра може зрости навантаження на сервер, і показник, який ще вчора був «нормальним», просяде.
І головне — не можна підганяти всі сайти під один критерій. Якщо ми вимірюємо швидкість, треба щоразу уточнювати: на яких пристроях, з якою швидкістю мережі, під навантаженням чи без, і про який тип сайту взагалі йдеться. Те, що буде відмінним показником для інтернет−магазину з тисячами товарів, може виявитись абсолютно неприйнятним для простого одностторінкового лендінгу.
Також у цьому уривку згадується дослідження 2012 року, яке нібито виявило, що люди помічають уповільнення сайту на 4 мілісекунди. Насправді тут помилка: мова в оригінальному дослідженні йшла про 400 мілісекунд, а не про 4. Цю цифру часто згадують у статтях про швидкість, і на одному із сайтів навіть стояло посилання на першоджерело — що мене спершу приємно вразило. Але виявилось, що це посилання веде на журналістську статтю, а не на саме дослідження. І що особливо кумедно: саме дослідження провели ще в 2009 році, а в 2012−му вийшла та сама журналістська стаття - і саме на неї, судячи з усього, всі й посилаються, коли пишуть про «дослідження 2012 року»
Тож я знайшов оригінал. Мова там ідеться не про сайти взагалі, а конкретно про сторінку результатів пошуку Google. На жаль, дослідники не зазначили, якою була початкова швидкість завантаження — вони просто почали штучно уповільнювати видачу й дивитись на реакцію користувачів. Перші зміни в поведінці зафіксували вже при затримці в 100 мс, а максимальний ефект — при затримці в 400 мс (чомусь саме на цьому дослідження й зупинилось). Так от: при затримці в 400 мс пошуком стали користуватись менше — лише на 0,59%. І ця цифра стала статистично помітною лише завдяки мільярдним масштабам аудиторії Google. Якби подібний експеримент проводили на кількості користувачів, яка в середнього інтернет−магазину не набереться навіть сумарно за все життя сайту, ефект цілком міг би загубитись у звичайному шумі даних і взагалі нічим не проявитися. Тож будьте обережні з подібними маніпуляціями цифрами — те, що статистично доведено на мільярдах, автоматично не означає застосовність до вашого проєкту.
Швидкість справді дуже важлива для першого враження. Але наш досвід показує: коли в середньостатистичного сайту трапляються проблеми зі швидкістю, які не перевищують поріг адекватності (умовно 5−6 секунд), це майже непомітно позначається на продажах. Звісно, для проєктів з аудиторією рівня Розетки навіть невелике уповільнення буде відчутним. Але не варто забувати, що швидкість — далеко не основний критерій вибору сайту. Якщо ваша пропозиція нічим не краща за конкурентів, а сайт при цьому працює значно повільніше — ви дійсно ризикуєте. Але якщо у вас є реальні переваги, то ці самі 400 мс бізнесу не зламають.
Що впливає на швидкість завантаження сайту?
Нам пропонують перелік значущих чинників, які впливають на швидкість сайту. Розглянемо кожен із них.
«Чистота» HTML−коду та його обсяг
Під чистотою коду зазвичай мають на увазі його охайність і відсутність зайвих елементів. Ця чистота жодним чином не впливає на швидкість — так само, як і валідність коду, про яку теж нерідко пишуть у подібному контексті. Зайві елементи справді можуть збільшити обсяг коду, і саме це вже відобразиться на швидкості. Але хоча теоретично можна отримати HTML−файл вагою в кілька мегабайт, на практиці ми ніколи не бачили, щоб розмір цього конкретного файлу був хоч скільки-небудь схожим на реальну проблему. Тож незрозуміло, що цей пункт узагалі робить у переліку значущих факторів.
Якість і формат зображень на сторінці
Якість і формат зображень навіть опосередковано не обов'язково на щось вказують. Має значення саме вага цих зображень — а якість і формат лише інструменти, якими цю вагу регулюють.
Наявність відео на сайті
Відео стане проблемою, тільки якщо завантажувати його разом зі сторінкою. Але існує декілька способів додати відео на сайт без уповільнення завантаження.
Кількість запитів від браузера
На жаль, цей пункт досить часто трапляється навіть у свіжих статтях. Проблема кількості HTTP−запитів була актуальною за часів протоколу HTTP першої версії, коли браузер міг одночасно завантажувати з одного домену не більше двох файлів. Сьогодні кількість запитів практично втратила актуальність.
Кількість встановлених плагінів
Хоча можна помітити, що на сайтах із великою кількістю плагінів часто виникають проблеми зі швидкістю, сама по собі кількість плагінів не є причиною. Є плагіни, які взагалі не впливають на швидкодію сайту. Точніше буде сказати, що на швидкість впливає кількість неякісних (повільних) плагінів, задіяних у формуванні фронтенду.
Що пропущено в цьому переліку
У ньому бракує кількох дуже важливих факторів.
- Якість програмного коду. Це один із найзначніших факторів, нерозривно пов'язаний із потужністю сервера. Програмний код ставить завдання на обчислення, а сервер надає потужність для цих обчислень. Тож завдання мають бути сформульовані так, щоб вимагати якомога менше обчислень, а потужностей має вистачати, щоб обробляти більше завдань одночасно.
- Якість і структурованість бази даних. Найпростіше, що можна сказати про базу даних, — це індекси. Це щось на кшталт алфавітного чи хронологічного покажчика в бібліотеці, який дозволяє швидко знаходити потрібне за певними параметрами. Але робота з базами даних може бути значно специфічнішою за цей приклад.
- Швидкість інтернету. Швидкість мережі нерозривно пов'язана з вагою файлів сайту. Чим швидша мережа, тим швидше передаються файли.
- Кількість вільних ресурсів на пристрої користувача. Ми часто забуваємо, що половину роботи виконує сервер, а другу половину — пристрій користувача. І якщо у користувача обмаль вільних ресурсів, сайт гальмуватиме навіть за ідеальної роботи сервера.
Про тезу «немає нічого, що неможливо виправити»
Не хочеться чіплятись до буквальної фізичної можливості на щось вплинути — хоча, наприклад, на швидкість мережі чи пристрій користувача ми справді не маємо впливу. Але навіть якщо відкинути це, в реальності залишається чимало інших обмежень.
Наприклад, як розробники ми не можемо вплинути на розташування сервера, якщо замовник вирішив під час війни тримати його за кордоном. Є й економічні фактори, що впливають на обсяг серверних ресурсів, — вони не безкоштовні, і можуть коштувати дуже дорого. Тож обмежень вистачає. Але навіть із ними залишається величезна кількість інструментів для роботи над швидкістю.
Заміна або оптимізація хостингу
Дуже часто пишуть про заміну хостингу, але через невдалі формулювання це нерідко призводить до непорозуміння і зайвих переїздів.
Буквально, хостинг — це просто процес розміщення сайту на сервері. Але в нашій культурі хостингом зазвичай називають те, що в англомовному світі відоме як shared hosting — специфічне розміщення багатьох сайтів на одному сервері, де вони ділять між собою обчислювальні ресурси.
Якщо сайт почав повільно працювати на такому хостингу, найімовірніше, справа саме в нестачі процесорних ресурсів. І на іншому такому ж shared−хостингу ви навряд чи знайдете їх більше — адже проблема не в конкретному провайдері, а в самій моделі розміщення. На цьому етапі вам потрібні вже гарантовані ресурси, а отже — варто планувати переїзд на VPS, а не черговий переїзд між shared−хостингами.
Стиснення зображень
У цьому прикладі є рекомендації, які я б назвав небезпечними.
Ви можете відкрити сайт на смартфоні чи на десктопному пристрої, і виглядатиме він по−різному, але коректно (сподіваюсь). Це не випадковість — це результат підготовки сайту, його верстання й контенту до роботи на різних пристроях з різною роздільною здатністю. При цьому у кожного сайту завжди є мінімальна ширина, після якої може з'явитись горизонтальна прокрутка, і максимальна ширина, після якої з'являються поля по краях. Тож питання в тому, яка саме максимальна ширина у вашого сайту. Якщо ви хочете, щоб вона сягала 4K, то вам справді можуть знадобитись зображення в 4K для фонів чи банерів. Але вони не повинні завантажуватись на менших роздільних здатностях — і особливо на смартфонах. Іншими словами, потрібна грамотна робота з адаптивністю контенту.
Не можна говорити, що зображення товару має мати якийсь конкретний, наперед визначений розмір у пікселях. Зображення не повинно бути більшим за той розмір, у якому воно максимально показується на сайті — а це не завжди найбільший розмір саме на десктопі. Наприклад, на планшеті кількість товарів у ряду каталогу часто зменшується порівняно з десктопом, і через це саме зображення товару може відображатись у більшому фізичному розмірі, ніж на широкому екрані. Усе залежить від конкретної верстки конкретної сторінки.
Так само не можна орієнтуватись на цифри ваги файлів. Про які саме файли тут узагалі йдеться? Про банери чи про фото товару? Очевидно, що вони матимуть різний розмір за своєю природою. Та навіть при однаковій роздільній здатності й однакових параметрах стиснення розмір готового файлу може сильно відрізнятись — залежно від складності самого зображення.
Ну і вишенька на торті — GZIP. GZIP призначений для стиснення текстових файлів. Їх він справді може стиснути в рази. А от зображенням він не дасть практично нічого, якщо це не текстовий формат на кшталт SVG.
Детальніше про роботу із зображеннями читайте в нашій статті "Який формат зображень краще для сайту: JPEG, PNG, WebP чи AVIF?".
Стиснення GZIP
Як ми вже розібрали раніше, GZIP — це технологія стиснення саме текстових файлів. Вона здатна зробити ці файли значно легшими, але жодним чином не зменшує їхню кількість — тобто ніяк не впливає на кількість запитів до сервера (хоча, як ми вже казали, актуальність самого показника кількості запитів давно втрачена). І GZIP не прив'язаний винятково до протоколу HTTP/1.1, хоча саме таке враження може скластися з формулювання в оригіналі — це технологія стиснення даних, яка так само працює і в HTTP/2, і в HTTP/3.
Оптимізуйте CSS і JavaScript
Майже завжди радять займатись мінімізацією файлів — тобто видаляти відступи, коментарі, переноси рядків. Технічно весь код можна записати в один рядок, і він так само працюватиме. І так, такий файл справді займатиме менше місця.
Для прикладу наведу одну з найпоширеніших бібліотек для сайтів — Bootstrap. У звичайному стані цей файл важить 281 КБ, а в мінімізованому — 233 КБ. Різниця складає 48 КБ, що не так уже й мало.
Бібліотека — це файл із великою кількістю готового коду, який полегшує впровадження певного функціоналу. У цьому випадку йдеться про бібліотеку для верстки.
І тут важливо розділяти дві різні категорії файлів: ті, з якими безпосередньо працює розробник, і бібліотеки (бібліотеки розробники зазвичай не редагують, або редагують мінімально).
Файли, з якими постійно працює розробник, не варто тримати в мінімізованому стані. З таким кодом дуже важко й неприємно працювати, а отже й сама робота обходиться дорожче. Коментарі в коді, як правило, дуже корисні — розробник залишає їх для себе на майбутнє чи для колег як пояснення логіки. Вони можуть суттєво спростити доопрацювання. Тож мінімізувати такі файли сенсу не має, на відміну від бібліотек, з якими напряму ніхто не працює.
Але тут варто пам'ятати ще одну річ — ми ж використовуємо GZIP, який виконує подібну оптимізацію «на льоту».
Так от: після стиснення той самий файл бібліотеки у звичайному стані важить 33,5 КБ, а в мінімізованому — 30,9 КБ. Різниця становить лише 2,6 КБ. І це на великій бібліотеці — на робочих файлах проєкту різниця буде взагалі непомітною.
Про підключення CSS і JS у різних місцях сторінки
Якщо не налаштовувати відкладене чи асинхронне завантаження, розташування файлів у коді саме по собі не впливає на загальну швидкість повного завантаження сторінки. Файли CSS, які відповідають за оформлення, можуть завантажитись, і сайт виглядатиме коректно, тоді як файли JS, які відповідають за функціональність, ще не встигнуть завантажитись. Це може призвести до ситуації, коли відвідувач намагається відкрити мобільне меню, а воно ще не працює. І тут постає питання: зрозуміє він, що треба просто почекати, чи вирішить, що на сайті баг, і піде?
Загалом із завантаженням скриптів варто бути обережними. Часто радять завантажувати їх асинхронно, але при цьому втрачається контроль над порядком завантаження — а іноді цей порядок критично важливий.
Найкраще, що можна порадити щодо цих файлів, — не допускати аномального розростання їхньої кількості. Якщо у вас від 2 до 10 файлів кожного типу, вони навряд чи створять якісь проблеми. А от якщо їх 30−60, то, найімовірніше, проблема вже не в самих файлах, а в тому, як загалом побудований сайт.
Оптимізація бази даних
Оптимізація бази даних — дуже важливий процес, і водночас доволі складний і варіативний, щоб описати його в кількох реченнях. Але те, про що йдеться в цьому уривку, дуже далеко від реальної оптимізації.
У базі даних зберігається контент сайту та його налаштування. Тож там зазвичай не буває непотрібної інформації, тестових даних чи копій, які постійно накопичуються і начебто вимагають регулярних чисток. А от спам — наприклад, у відгуках — цілком можливий і справді може накопичуватись.
Але саме розростання бази даних саме по собі не призводить до уповільнення сайту. Якщо у вас у базі багато товарів, це може вплинути на швидкість завантаження саме сторінок із товарами, але жодним чином не позначиться на швидкості інших сторінок, де товарів немає. І з проблемою «база переповнена товарами» видаленням не впораєшся — товари ж не спам, їх не приберете просто так. Тут потрібна вже реальна оптимізація структури бази даних та оптимізація програмного коду, який з нею працює.
Впровадження кешування
Браузерне кешування — дуже корисна річ, і тут можу тільки підтримати рекомендацію її використовувати.
Серверне кешування дійсно може суттєво скоротити час відповіді сервера, але тут є свої побічні ефекти. Детальніше про це читайте в нашій статті "Кешування сторінок сайту: підводні камені, про які часто мовчать".
Використання серверів Nginx і Apache для розміщення інформації
Ця рекомендація не має жодного сенсу.
Існує два популярні веб−сервери — Nginx і Apache. Якщо у вас є сайт, він працює на одному з них. Тобто це обов'язкова умова для роботи будь−якого сайту, а не опція для прискорення. Альтернативи, звісно, існують, але вони настільки рідкісні й специфічні, що випадково на них навряд чи натрапите. Немає жодних підстав казати, що один із цих серверів «швидший», а інший «потужніший» (хоча питання швидкості й потужності стосовно сайтів настільки тісно пов'язані, що фактично є синонімами). І, звісно, самі по собі ці веб−сервери не роблять нічого з того, що перелічено в оригінальному тексті.
Як бачите, навіть у топі пошукової видачі за темою швидкості сайтів матеріали рясніють помилками — від безневинних спрощень до тверджень, які суперечать самим основам того, як працює браузер чи сервер.
Щоб захистити себе від некомпетентних рекомендацій, варто хоч трохи розібратися в питанні самостійно. Коли зрозуміла загальна логіка, абсурдні твердження стають помітними одразу. Для цього радимо ознайомитись з нашими статтями на цю тему: