Розробник в більшості випадків під прискоренням завантаження сайту розуміє роботу по back-end. Однак відвідувачеві все одно за скільки мілісекунд відкривається сторінка у розробника, йому важливо як швидко відкривається сторінка у нього самого. А тут вже важливий цілий комплекс показників. Кваліфікований розробник повинен розглядати сайт не як шматок програмного коду, за який він відповідає, а як кінцевий комплексний продукт.
Без налагодження програмного коду. звичайно ж, не обійтися. Тут розробнику в допомогу приходить інструмент Монітор продуктивності. який дозволяє профілювати всі сторінки сайту на предмет коду, SQL запитів. Крім того, цей модуль дає рекомендації по тюнінгу серверного програмного забезпечення.
Наступний крок - це впровадження технології Композитний сайт.
Розташування сайтів на віддалених територіально серверах може серйозно вплинути на час отримання інформації користувачем. Особливо це актуально для проектів, що орієнтуються на локальні ринки. Перенесення хостингу в такому випадку може дати істотний приріст, в ряді випадків відзначалося прискорення до 1 секунди.
Після виконання робіт по back-end'у необхідно переходити до розгляду інших параметрів, які впливають на швидкість завантаження. У Bitrix Framework є інструмент - Швидкість сайту. Його завдання - полегшити розробнику роботу по оптимізації завантаження сторінки.
Примітка. Для роботи Швидкості сайту потрібна статистика. Після внесення якихось змін необхідно витримувати певний період для отримання статистично вірних даних. Тривалість періоду залежить від відвідуваності сайту.
У цього інструменту є діаграма по хітам, де можна подивитися кожен з етапів завантаження Navigation Timing.
На цьому графіку зеленим кольором показана робота back-end'а, а фіолетовим - робота front-end'а. Тобто виходить, що більшу частину часу в завантаженні сторінки браузер витрачає не на back-end, а на front-end.
Поліпшити роботу front-end можна зменшивши кількість завантажених ресурсів і їх обсяг.
Заходи по зменшенню числа завантажуваних ресурсів:
- Включивши об'єднання css і js скриптів. У браузерах є обмеження на кількість одночасних з'єднань з сервером. Як правило це 6, але може доходити до 13, як в IE. Тобто, якщо на сторінці 70 файлів, то браузер завантажить їх в кілька прийомів, а не одномоментно. Якщо об'єднати ці скрипти, то швидкість завантаження збільшиться.
- Включивши CDN. Однак до підключення CDN потрібно підходити уважно. Якщо ваш основний відвідувач локалізована на певній території, то CDN може виявитися сповільнює фактором, якщо найближчий сервер розташований далеко від користувачів.
- Використовуючи кешування ресурсів в браузері (Expires / Cache-Control: max-age, Last-Modified / E-tag). Потрібно віддавати заголовки для картинок, css і js-скрипта. Якщо немає заголовків останньої модифікації або заголовка Expires, то на кожен хіт браузер буде завантажувати всі ресурси повторно.
Якщо у вас є дата останньої модифікації, то це вже добре. У цьому випадку на других і наступних хітах браузер буде робити conditional get запит. Тобто питати: а чи не змінився цей ресурс ось з цієї дати? І завантажувати тільки змінені ресурси. Правда і в цьому випадку доводиться робити один додатковий запит.
Щоб уникнути цього запиту досить налаштувати в Apache або NGINX видачу заголовка Expires. Це, на жаль, часто забувають зробити.Заходи щодо зменшення обсягу даних при завантаженні:
Навіщо потрібно стискати дані?
Швидкості передачі даних зараз великі. Навіщо стискати дані, борючись за байти? Стиснути css - файл зменшується з 10 до 8 kb, стиснення картинки дає 3 kb. Що дає такий виграш?
Відповідь в протоколі TCP / IP і поняття Round Trip Time - час між відправленням запиту від клент сервера і отриманням зворотного відповіді. Коли браузер з'єднується з сервером, вони домовляються між собою про розмір вікна, в якому вони будуть обмінюватися даними. У кожного клієнта це вікно різний, більш того, воно може змінюватися в процесі передачі даних. Одне вікно передається за один Round Trip Time. Якщо вікно - 8 kb, а файл 10 kb, то потрібно два Round Trip Time, тобто в два рази більше часу.
Примітка. Це ж відноситься до Яндекс.Метрика, GoogleAnalitic і всі подібні зовнішні скрипти і інструменти. Незважаючи на те, що вони все зовнішні і повинні пізніше завантажуватися. Досить часто виходить що незважаючи на те, що ці скрипти вантажаться асинхронно, ці файли можуть завантажиться раніше рендеринга сторінки і, відповідно, як тільки цей ресурс завантажився, він починає виконуватися. Порада: завантажуйте все зовнішні інструменти (метрики, лічильники, кнопки Вконтакте, ФБ та інші) в BX.ready. тобто на факт того, що сторінка завантажилася.
сторонні інструменти
Для оптимізації front-end'a як чек-листа можна використовувати сторонні інструменти: