Подивіться на графік нижче. Це залежність рівня конверсії від швидкості завантаження сторінок в великому ІМ (Walmart.com). По ній чітко видно, що межа 1-2 секунди, це та межа, при якому ви будете попереду планети всієї, а як тільки час завантаження зашкалить за 3 секунди, ви перетворюєтеся в сумну сіру масу.
Згідно онлайн опитуваннями факти такі:
Як правило, швидкість роботи залежить від обраної системи управління і від «наворотів» сайту », кількості товарів і програміста, який реалізує функціонал.
Знаєте, як зазвичай в веб студіях народжується пункт у переліку достоїнств, що «Сайт повністю оптимізований для SEO»? Дуже просто! Просто беруть і додають цей пункт в перелік переваг CMS, на основі якої створюється сайт. Ще б пак, адже це стверджують творці CMS.
Так ось. Страшна правда полягає в тому, що в реальності розробники жахливо рідко обтяжують себе тим, щоб дійсно оптимізувати швидкість.
Давайте я трохи відкрию завісу страшної таємниці і зрозумілою мовою розповім, що має відбуватися за технічної оптимізації сайту або при його розробці, щоб була досягнута максимальна швидкість.
1) Програміст оптимізує БД
У ній не повинно бути зайвих таблиць і у всій системі не повинно бути складних багатоповерхових запитів до бази.
За замовчуванням, при створенні таблиці, вибирається тип досить універсальний. Це означає, що під кожне значення резервується певна кількість ресурсів. При цьому, кількість ресурсів, які потрібні, скажімо, для зберігання значень властивостей в таблиці для тексту в 256 знаків, для цифри з високою точністю, для цілого числа або ж для маркера так / ні, буде дуже сильно відрізнятися. Точніше, в десятки разів. На швидкості це позначається дуже сильно.
Наведу конкретний приклад. Якось до мене потрапив в руки інтернет-магазин, у товарів якого було 45 різних властивостей: матеріал, країна виробництва, оптові і роздрібні ціни, вага, розміри, кількості на різних складах, наявність спеціальних атрибутів і купа інших ... Під всі ці властивості за замовчуванням резервувалася рядок в 256 текстових символів. Час завантаження сторінки, яке по купі параметрів (по фільтру), висмикують потрібні товари, становило близько 20 секунд. Товарів було більш 50тисяч, властивостей багато, код жахливий. В результаті час завантаження було таке, що користуватися сайтом було не можна.
Після оптимізації однієї ресурсів однієї тільки БД, час завантаження впало до 11-12 секунд. В два рази!
Цим зазвичай ніхто не заморочується. А треба.
2) Програміст повинен ламати голову, щоб використовувати функції та програмні рішення, які виконуються швидше за все і не вантажать сервер.
Різні оператори або програмні рішення будуть по-різному вантажити сервер. У випадку з цим жахливим прикладом часто замість того, щоб відразу витягнути потрібні дані з бази одним запитом, спочатку витягують що треба і не треба, а потім оброблялися в масивах. Це сильно збільшувало час обробки і займало величезні непотрібні ресурси пам'яті.
Оптимізація цих процесів в нашому прикладі скоротила час завантаження сторінки до 3 секунд
3) Програміст повинен ламати голову, що з «нібито» потрібних динамічно оброблюваних речей можна прибрати в статику і не чіпати.
У прикладі з цим нещасним сайтом, фільтр в залежності від обраних значень, вважав за іншими параметрами кількість товарів, які виведуться, якщо вибрати той чи інший варіант за властивостями. Коли значень властивостей трохи - це не страшно. Але що робити, якщо їх кілька сотень? Можливо, іноді варто знехтувати динамічним розрахунком тільки за цим параметром, якщо це дає помітний виграш в швидкості. Коли ми прибрали динамічний розрахунок по параметру купи брендів, то час завантаження сторінки скоротилося до 1.2-1.3 секунд.
4) Програміст повинен кешувати все, що можливо.
Кешування - це запис результатів виконання скриптів в статичні файли, з яких віддається інформація без необхідності повторно виконати скрипт.
Ті сторінки, які завантажувалися за 1.2-1.3 секунди, при повторному зверненні до них, видавалися частково з кешу і швидкість формування сторінок становила 0.3-0.6с.
А це, за відсутності на сайті важкої графіки, вже давало повне час завантаження у клієнта в межах 1 секунди, що було дуже хорошим результатом.
Чи варто говорити, що різниця в конверсії, не змусила себе чекати?
Так ось. Хороші програмісти - це рідкість. І якщо ви знайдете таких, які самі дбають за те, щоб сайт працював якомога швидше, тримайтеся за них. Це буде означати дуже хорошу інвестицію в проект.
Те, що розробників і програмістів, які боряться за кожні 10мс завантаження не так багато, це одночасно прокляття і величезний позитив.
Позитив у тому, що якщо ви все-таки виконайте грамотну технічну оптимізацію або ж створите сайт, який буде працювати з максимальною швидкістю, ви отримуєте величезну перевагу перед своїми конкурентами.
Вдалого пошуку ))