«Про що ви думаєте, коли чуєте “реанімація”? – запитує Андрій Сидоренко, Lead Magento Developer у NIX. – Напевно, уявляєте сцену з медичного серіалу, у якій команда лікарів рятує життя. Розробники, звичайно, не медики. Але їхнє завдання – дбати про “здоров’я” вебресурсів». Щодня команда Андрія має справу з «реанімацією» сайтів на платформі Magento.
У партнерському матеріалі експерт NIX розповідає, які проблеми можуть виникати із сайтами, що розроблені на цій платформі, та як оптимізувати сторінку, якщо щось іде не так.
Які проблеми можуть чекати сайт на Magento
Magento є відомою ecommerce-системою з відкритим вихідним кодом. Сайти на цій платформі зазвичай створюються для великих інтернет-магазинів з величезним асортиментом. На сьогодні на базі Magento існує вже понад 100 тис. сайтів.
Відкрита структура платформи та різноманітність модулів дозволяють розробникам реалізувати дуже різні бізнес-концепції. А ще вона добре підходить для SEO та налаштування для просування в результатах пошуку Google.
Проте не все так добре. Адже пошуковик оцінює дуже багато параметрів, зокрема, швидкість роботи сайту й кількість помилок на ньому. І якщо із цим є проблеми, Google може знизити позицію в пошуковій видачі, а це призведе до зменшення трафіку та кількості покупців.
Найчастіше клієнти жаліються, що знизилися чи зовсім зупинилися продажі. Звичайно, проблема може бути в товарі і його ціні, але перевірити треба все. Адже покупців від замовлення відвертають також технічні негаразди: повільне завантаження сторінок або, наприклад, помилка з кошиком.
«Щоб зануритися у проблеми сайту, ми використовуємо певний чекліст для аналізу та коригування проблем», – пояснює Андрій Сидоренко.
Як оптимізувати сайт на Magento
- Аналіз інфраструктури
Спочатку треба вивчити інфраструктуру сайту: оточення, у якому виконується код, та відповідність налаштувань доступним ресурсам. Іноді сторінка потребує більше ресурсів, ніж має. Наприклад, якщо дуже багато відвідувачів одночасно звертаються до сайту, він може стати недоступним для одного з них або взагалі для всіх. У таких випадках треба розібратися, як допомогти: оптимізувати налаштування чи просто збільшити оперативну пам’ять.
Якщо негаразди саме на рівні інфраструктури, їх слід усунути перед переходом до наступного етапу. Без правильного налаштування операційної системи і програм, що підтримують роботу сайту, базові проблеми не вирішити. Адже саме ОС є фундаментом, без якого неможлива коректна робота сайту. А якщо операційна система втратила актуальність або не підлягає оновленню, тоді необхідно переходити на нову платформу. Тим більше іноді простіше налагодити все з нуля на новому обладнанні або іншому сервісі.
Окрім цього, при роботі з магазином на платформі Magento треба звертати увагу на обраний хостинг, сервер і вебсервер. Також дуже важливо переконатися в наявності сертифіката SSL. Він необхідний для HTTPS-з’єднання, отримати його можна безплатно, і в сучасному інтернеті без нього не обійтися. Це важливо не тільки з огляду на безпеку, яку гарантує такий сертифікат. Не менш значущим є те, що Google може зменшувати видимість ресурсу без SSL або давати йому мінімальний рейтинг.
Встановити такий сертифікат дуже просто. Проте необхідно правильно його налаштувати. Деякі зовнішні служби, наприклад платіжні системи, можуть скаржитися на його налаштування. Тож після підімкнення SSL можна використати спеціальні інструменти для оцінювання налаштування сертифіката. Шукайте їх за цим посиланням.
- Перевірка взаємодії із зовнішніми сервісами
Наступний крок – проаналізувати, як сайт працює з різними сторонніми сервісами. Наприклад, сторінки часто використовують мапу Google, щоб показати місце магазину або точки видачі товарів.
Але кілька років тому Google почав вимагати обов’язкове використання API-ключа для мапи. Це може викликати певні проблеми: мапа просто не відображається через відсутність ключа.
- Оцінювання трафіку сайту
Далі необхідно визначити поточну активність на сайті, тобто дізнатися кількість відвідувачів та оформлених замовлень на день. Тут допоможе Google Analytics, де зібрана вся необхідна статистика.
Ці дані допоможуть зрозуміти поточне навантаження і спрогнозувати майбутнє з огляду на заплановані заходи власників магазину. Наприклад, під час глобального розпродажу трафік може значно збільшуватися, слід бути до цього готовими.
- Аналіз TTFB
TTFB, скорочення від time to first byte, – це інтервал від запиту до отримання першої порції даних від сервера. Якщо говорити простою мовою, це час між кліком на лінк і моментом, коли починає завантажуватися сторінка. Це вже є найпершим навантаженням на сайт. Тому потрібно оцінити, наскільки добре налаштований сервер і з якою швидкістю він відповідає на запити. Якщо час відповіді на ключові сторінки є занадто тривалим, потрібно розібратися у причинах.
В актуальних версіях Magento TTFB може досягати однієї секунди, а в попередніх редакціях платформи – чи не вдвічі більше. Проте мова йде про сторінки поза межами кешу. А ось із правильним кешуванням час завантаження скорочується до 200–300 мілісекунд, що може тимчасово розв’язати проблеми затримки у відповідь на запит до сторінки.
- Впровадження кешу
Оптимізація будь-якого сайту фактично неможлива без кешування. А концепція Magento в цілому побудована на використанні кешу. Платформа застосовує максимальне кешування, завдяки чому сайти на Magento завантажуються так швидко.
Загалом кешуються сторінки, де вміст рідко оновлюється. Це можуть бути, наприклад, головна сторінка, каталог, продукти або контакти. При першому завантаженні сторінки вона генерується з нуля, оскільки її ще немає в кеші. При цьому в Magento створюється спочатку верхня частина сторінки з головним меню, далі основний контент і лише потім нижня частина за межами першого екрана, яку користувач не бачить, поки не почне скролити сторінку. У стандартних умовах на це витрачається 1–2 секунди. Але якщо сама сторінка надалі не змінюється, то не варто при наступних запитах її постійно генерувати з нуля – можна просто закинути її в кеш і моментально видавати готовий результат у відповідь на новий запит.
У деяких сайтів кешування може бути повністю відключеним. Наприклад, попередній розробник міг не розібратися із цим механізмом і просто деактивував його. У такому випадку треба проаналізувати зміни, внесені розробником, виправити їх, увімкнути кешування та на завершення протестувати результат.
Також можна зустріти застарілі доповнення, які сповільнюють сайт. Через помилки в коді або погану організацію запитів до бази даних при збільшенні трафіку можуть виникати проблеми. Наприклад, у Nix був проєкт, де для створення сторінки генерувалося кілька тисяч запитів до бази даних – замість потрібних 100–200. Тож довелося переписати частину коду, аби сайт став дійсно таким швидким, яким має бути.
- Виявлення помилок на сайті
Це чи не головне завдання: знайти всі помилки, визначити причини й усунути їх. Задля цього насамперед треба зайти до директорії var/report і файлу exception.log, де зберігаються помилки. Щоправда, в останньому файлі логи регулярно оновлюються, тому їхній вміст змінюється. А ось у папці report можуть бути старі помилки, забуті попередніми розробниками, що робить їх особливо цінними для аналізу. І там за кожним типом помилки іноді можуть бути десятки, а то й сотні файлів. Задля спрощення та якості роботи варто класифікувати помилки за типами, визначити найкритичніші та ранжувати інші за рівнем впливу на роботу сайту. Виправлення однієї помилки може автоматично розв’язати низку інших, пов’язаних з нею проблем.
Але важливо пам’ятати, що у процесі коригування можна випадково стикнутися з функціоналом, про існування якого ви й не підозрювали. Тому до того, як усувати проблему, з’ясуйте причину її виникнення. Можливо, треба виправити не те, що здається на перший погляд. Іноді баг є лише проявом іншої проблеми, і вирішувати її треба десь в іншому місці. Буває, що конкретна помилка рятувала від катастрофічного сценарію на кшталт падіння сервера. Тобто це була не помилка, як здалося, а захисний захід.
Звісно, зустрічаються й украй незвичайні проблеми. Одного разу команда Nix отримала для реанімації сайт, де головна сторінка завантажувалася лише за вказівки мовного параметра в URL. Після його додавання сайт функціонував нормально. Лишається загадкою, як користувачі потрапляли на сторінки, що їх цікавлять, якщо відразу стикалися з такою глобальною помилкою.
- Покращення роботи зі статичним контентом
У Magento 2 є багато статичного контенту. Це стилі сайту
CSS, скрипти для браузераJavaScript та HTML-документи, які використовуються в цих скриптах. І вся ця статика рознесена по окремих файлах. Тому без спеціального налаштування сайт працює дуже повільно, адже може завантажувати кожен файл окремо і створювати таким чином надмірне навантаження на сервер. Для розуміння масштабу проблеми: при відвідинах сторінки оформлення замовлення ви можете завантажити до 500 файлів JavaScript.
Аби покращити ситуацію, Magento пропонує об’єднати JavaScript у так звані бандли, набори. Тоді замість сотень окремих файлів браузер завантажить лише кілька упакованих. Проте є недолік: необхідно завантажувати всі JavaScript-скрипти щоразу. У такому випадку потрібно налаштувати кешування на боці клієнта, завдяки чому можна завантажувати ці файли лише один раз. І тоді вони просто братимуться з кешу браузера. Хоча існує й інший, просунутіший метод – Advanced Bundling. Детальніше про нього – за цим посиланням.
Але налаштувати браузерне кешування не так просто. Припустімо, ми впровадили новий функціонал і змінили для цього CSS- та JS-файли. А тому нововведення буде доступним лише тим, хто знову завантажить увесь статичний контент. Але ж у тих, хто вже зберігає файли в кеші браузера, оновлення відбудеться лише після зміни URL-адреси самих файлів. Саме для цього в Magento існує механізм підпису статичного контенту. До його адреси додається рядок Unix Timestamp, який оновлюється з кожним деплоєм. Тоді браузер просто перезавантажує останню версію CSS і JS, що забезпечує актуальність контенту.
- Контроль інтеграцій із зовнішніми сервісами
Для кінцевого користувача всі дії фактично завершуються після оплати. Але для бізнеса основні процеси тут лише розпочинаються. Адже треба обробити замовлення та передати покупцю. І тут на допомогу власникам сайтів на Magento приходить безліч сторонніх сервісів, які автоматизують подальше виконання замовлення. Наприклад, передача даних на склад для пакування та до поштових служб для доставлення товару клієнтові.
Але тут чекає чимало проблем. Зовнішні сервіси інколи прив’язані до IP конкретного сервера. При переїзді сайту на інший сервер його IP, звичайно, змінюється. Але разом із тим доступ до сервісів, які беруть участь у процесі оформлення замовлень, може бути втрачений. А тому і замовлення будуть просто втрачені. Тож розробники мають заздалегідь перевірити роботу всіх потрібних систем.
Сайти з великим асортиментом часто покладаються на сторонні системи обліку товарів, тому що іноді вони надходять з різних джерел. І важливо гарантувати, що будь-які дії на сайті не порушать ці взаємозв’язки. Адже інакше ви можете стикнутися, наприклад, з ризиком продажу відсутнього товару. Тому треба одразу зібрати якомога більше інформації про всі інтеграції. Проте готової документації за ними зазвичай мало. Тож, скоріше за все, вам доведеться звертатися до попередніх розробників або довго збирати інформацію у власників сайту, аналізувати логи та код тощо. На основі всього ви зможете створити власну документацію, яка буде корисною і вам, і власникам сайту.
- Безперервний моніторинг сайту
Трекінг помилок допоможе швидко реагувати на них і пояснювати власнику сайта, з чим пов’язані ті чи інші нові негаразди. Тільки так ви зможете заощаджувати власні сили та час.
Краще використовувати різні інструменти моніторингу. Адже універсальних немає. Одні фокусуються на роботі сервера, використанні оперативної пам’яті чи навантаженні диска, а інші – на продуктивності самого вебсайту. Тож тільки поєднання різних інструментів дає повне уявлення про роботу сайту.
Невіддільною частиною комплексної системи моніторингу мають стати нотифікації. Але треба зазначити: листи – це не ідеальне рішення, бо вони можуть загубитися чи залишитися поза увагою. Тому краще налаштувати чат-боти, повідомлення з яких будуть помітнішими. Це дозволить вам оперативніше реагувати на проблеми, що виникають.
У Nix для контролю за інфраструктурою використовують Zabbix та Influxdb. А для відстеження роботи сайтів – Tideways і New Relic. Усі вони дають можливість моніторити сайт у реальному часі і збирати важливі метрики. А ще ці інструменти вміють надавати рекомендації. Наприклад, New Relic може дати зворотний зв’язок про те, чи задоволені користувачі вашим сайтом.
- Поінформованість власників сайтів
Спроби самостійної реанімації сайту нерідко закінчуються катастрофічними наслідками для його роботи, тому що непрофесійні дії навіть у дрібницях можуть спричинити глобальні проблеми. Для успішної роботи сайту на Magento необхідні знання принципів розробки, архітектури вебсайту та інфраструктури серверів. Тож завжди краще звернутися до профі, які зможуть вести проєкт правильним шляхом.
Ці думки дуже важливо донести до замовників. Розробники мають не просто розв’язати проблему, а й показати клієнту її причини та можливі наслідки. Не бійтеся розповідати, що саме ви зробили. Це дасть змогу людині без ваших компетенцій зрозуміти складність і важкість задач.
Зрештою, успішна співпраця між розробниками і клієнтами ґрунтується на довірі, взаєморозумінні і прагненні до спільного розвитку.
Це партнерський матеріал. Інформацію для цього матеріалу надав партнер.
Редакція відповідає за відповідність стилістики редакційним стандартам.
Замовити матеріал про вас у форматі PR-статті ви можете тут.