В интернете легко можно найти много статей на тему клиентской оптимизации, и ещё больше сайтов, разработчики которых уделили мало внимания этой теме. Хотя это отличный способ ускорить загрузку страниц своего сайта. Из основных рекомендаций выделим следующие:
Уменьшение количества запросов (особенно тех которые указаны в head страницы)
Использование gzip
Это, конечно, не всё, но именно эти рекомендации легче всего реализовать, и они принесут наиболее ощутимый эффект.
Для анализа откроем примеры сайтов на CMS Bitrix. Я взял 10 сайтов с 1-й страницы и с помощью Firebug оценил их оптимизированность (главные страницы) по следующим параметрам:
Общее число запросов, число запросов css-файлов, число запросов js-файлов.
Использование сжатия там, где это возможно.
И что же выяснилось? Запросы:
Из 10 сайтов только 3 имели число css-файлов меньше 5-ти Из 10 сайтов только 3 имели число js-файлов меньше 5-ти Остальные имели количество css-файлов от 7 до 19-ти, количество js-файлов от 6 до 55-ти (!) и большинство этих файлов подключались в <head> страницы, то есть блокировали отображение страницы до завершения загрузки.
Сжатие
Только 4 сайта применяют gzip-сжатие при отдаче html, css, js.
Итак, вроде бы основы, однако, разработчики часто при них забывают.
Казалось бы, причём здесь Bitrix? Но у него есть одна особенность - страницы часто формируются из компонентов, каждый из них подключает файл style.css. Это удобно - включил компонент, стили подключились, отключил - они не грузятся. Обычный сайт содержит несколько компонентов на странице - каждый добавляет свои стили. Однако состав этих компонентов меняется редко, и в этом случае файлы целесообразно объединять. Именно этим пренебрегли 7 из 10 сайтов и подключали много css-файлов размерами 500-600 байт, а это не позволяет эффективно использовать соединение с сервером
Подведём итоги. Для ускорения сайта "лёгким" путём достаточно сделать следующее:
Если состав компонентов на странице постоянный, их стили нужно объединить в 1 файл. Для главной можно сделать следующее - все стили компонентов, которые есть на главной и других страницах, переносим в главный файл стилей template_styles.css. Стили компонентов, которые включены только на главной, объединяем в 1 файл. Итого на главной странице будут подключены всего 2 css-файла.
Обязательно договориться с хостерами о включении gzip-сжатия. Nginx обычно собирается с модулями, реализующими это и включить сжатие - дело быстрое и беспроблемное.
Решить эти 2 вопроса можно за несколько часов, однако польза будет большой и увеличение скорости загрузки может стать заметным даже на глаз!
К сожалению, вы делаете выводы "постфактум". Мы не знаем ни нюансов разработки проекта, ни каким был проект на момент сдачи, а что потом сделали сами заказчики или появилось за несколько лет развития.
Пожалуй, только отсутствие nginx перед apache является явной проблемой. Однако, многие системные администраторы просто не хотят слышать доводы о производительности и проект приходится сдавать "под ответственность заказчика"
А когда именно должно наступить это самое "потом"? Над многими крупными сайтами работа ведётся годами.
И есть ещё один момент, достойный, как мне кажется, упоминания. Когда ты правишь стилевой файл компоненты, тебе надо прокликать те страницы, на которых эта компонента подключается, чтобы проверить, не сломалось ли чего. Когда ты правишь общий стилевой файл, тебе с той же целью надо бы прокликать весь сайт. Во всех более-менее популярных браузерах, ага.
На простых сайтах -- когда компонент мало, а все стили ещё сидят в "оперативной памяти" разработчика/верстальщика -- это легко. На топовых сайтах -- когда вёрстку аутсорсили полтора года назад, а поддержкой занимаются совсем не те люди и совсем не с той квалификацией -- такой гемор никому и нафиг не упал.
Всегда приятно видеть в YSlow буковки "А" во всех строчках, но не всегда возможно. Проблема с CSS и JS в битриксе - это проблема компромиса между модульностью и клиентской оптимизацией. Модульность, гайдлайны битрикса и удобство сопровождения за отдельные файлы на каждый компонент и даже шаблон компонента. В общем случае решить эту проблему могут разработчики битрикса, предоставив инструмент для сборки и кеширования стилей и скриптов. Задача, правда, не самая простая и стопроцентного решения тоже не имеющая.
Я же, например, большую часть стилей компонентов выношу в template_styles.css. Это касается стилей компонентов вызывающихся на большинстве страниц, меню например. Нет никакого смысла выносить стили меню отдельно, на другом сайте они не пригодятся. А если компонент вызывается на одной странице или в одном разделе, то его стили будут в отдельных файлах. Это увеличит время загрузки, но только для этих страниц, а сопровождать код будет гораздо проще. Для меня это приемлемый компромис.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».