Для начала давайте определимся, какую задачу нужно решить. Либо получить максимальную оценку в PageSpeed / GtMetrix, либо ускорить первую загрузку страницы для пользователей. Поверьте, это разные вещи.
Для первой цели просто выполняйте все возможные рекомендации инструмента проверки. Большинство из них фронтендеры решают средствами систем сборки (gulp, grunt, webpack). Т.е. из исходных dev-файлов собирается production-проект со всеми минификациями и оптимизациями. Можно обойтись и без них, используя онлайн-сервисы.
Далее напишу о том, что действительно влияет на скорость загрузки для конечного пользователя в порядке уменьшения значимости:
огромные изображенияНе нужно грузить изображение в 1Мб, если на странице будет картинка 200x200. Для этого подготовливаются миниатюры нужных размеров.
Для уменьшения объема проводят оптимизацию (
optipng,
tinyjpg) и
используют srcset.
блокирующий jsБраузер перед рендером разбирает полученный html-код. При этом проверяется синтаксис js-скриптов на валидность, и пока он не пройдет - страница не готова для показа. Поэтому необязательные скрипты нужно загружать асинхронно. Почитайте
это и
это.
не используется lazy-loadПредставьте, что есть лонгрид с 1000 изображений, картой и кучей видео. Если все это браузер должен показать пользователю при первой загрузке страницы, представляете как долго она будет грузиться? Решение простое - использовать отложенную загрузку элементов, которые не попадают в текущую область видимости. Например
так. Для jquery
полно нужных плагинов. Вам обязательно нужно это сделать для яндекс-карты и большинства изображений.
Вот удачный
пример.
кол-во параллельных запросов с одного доменаНапример для chrome это
6 запросов, т.е. 7-й начнет выполняться только тогда, когда вернется ответ от одного из шести первых...
Здесь пользуются рядом приемов:
спрайты для изображений (всякие стрелочки, иконки меню, почему они у вас все разными файлами?), объединение всего js-кода в один файл, css-кода в один файл, а также разносят внешние данные по поддоменам, например images.example.com для изображений, static.example.com для всей статики и т.п.
генерация динамики на сервереЭто относится к высоконагруженным проектам. Например когда для формирования страницы нужно брать много данных из базы, что-то с ними делать на ходу, потом идти на какой-нибудь сервис за данными и т.д. Очевидно, что генерация страницы будет долгой, причем для каждого пользователя. Решение - использовать промежуточные кеши, профилировать серверный код и т.д.
Есть и ряд других оптимизаций, которые
мало влияют на реальную скорость загрузки для пользователей, но влияют на показатель оценки в PageSpeed / GtMetrix. Например это минификация js / css / html. Или перенос всяких inline-стилей в таблицы стилей.
Важно думать не только о первом показе страницы, но и о повторных. Нет смысла заново отдавать ему то, что браузер может кешировать. Поэтому статику отдаем с правильными заголовками (expires, etag) и в сжатом виде (gzip). Делается это средствами вебсервера. С этим у вас все в порядке.
Подробнее про клиентскую оптимизацию
тут. О чем-то я намеренно умолчал, но сервисы все это учитывают и дают свои рекомендации. Следуйте им, и да пребудет с вами Сила.
