Разработчик в большинстве случаев под ускорением загрузки сайта понимает работу по back-end. Однако посетителю всё равно за сколько миллисекунд открывается страница у разработчика, ему важно как быстро открывается страница у него самого. А тут уже важен целый комплекс показателей. Квалифицированный разработчик должен рассматривать сайт не как кусок программного кода, за который он отвечает, а как конечный комплексный продукт.

Back-End

Без отладки программного кода, конечно же, не обойтись. Здесь разработчику в помощь приходит инструмент Монитор производительности, который позволяет профилировать все страницы сайта на предмет кода, SQL запросов. Кроме того, этот модуль даёт рекомендации по тюнингу серверного ПО.

Далее необходимо заняться кешированием компонентов.

Следующий шаг - это внедрение технологии Композитный сайт.

Расположение сайтов на удалённых территориально серверах может серьёзно повлиять на время получения информации пользователем. Особенно это актуально для проектов, ориентирующихся на локальные рынки. Перенос хостинга в таком случае может дать существенный прирост, в ряде случаев отмечалось ускорение до 1 секунды.

Front-End

После выполнения работ по 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. Это, к сожалению, часто забывают сделать.
• Все картинки для шаблона должны быть в спрайтах. А для мелких картинок лучше вообще использовать Base64.

Меры по уменьшению объёма загружаемых данных:

• GZIP-сжатие. Рекомендуется использовать серверное сжатие. Если оно не доступно, то можно использовать модуль Компрессия. Однако с этим модулем надо быть осторожным, его сжатие поддерживается не всеми хостерами.
• Минификация CSS и Javascript. Это - вырезание пробелов, переводов строк, уменьшение локальных переменных и оптимизация кода (для js).
• Сжатие картинок специальными утилитами.

Дополнительные меры

• Вынос ресурсов на разные домены, который позволяет обойти ограничение на 6 подключений.
• Порядок подключения ресурсов на странице: CSS вверху, Javascript – внизу. Оба они блокируют рендеринг страницы до завершения собственной загрузки. Но если css мы не можем убрать в низ страницы: без него она просто не отобразится, то Javascript - вполне убрать вниз или же грузить асинхронно.
  Примечание: Это же относится к Яндекс.Метрике, GoogleAnalitics и все подобные внешние скрипты и инструменты. Несмотря на то, что они все внешние и должны попозже загружаться. Достаточно часто получается что несмотря на то, что эти скрипты грузятся асинхронно, эти файлы могут загрузится раньше рендеринга страницы и, соответственно, как только этот ресурс загрузился, он начинает выполняться. Совет: грузите все внешние инструменты (метрики, счётчики, кнопки Вконтакте и прочие) в BX.ready, то есть на факт того, что страница загрузилась.

Сторонние инструменты

Для оптимизации front-end'a в качестве чек-листа можно использовать сторонние инструменты:

• Google PageSpeed Insights
• Audits в Chrome Developers Tools
• YSlow