Как правильно располагать ресурсы для ускорения загрузки и рендеринга страницы?

Question

[transcend]

На странице HTML имеются следующие ресурсы
Подключаем в HEADER

1. Основной CSS
   
2. Основной JS
   
3. Google Analytics
   

Внутри кода body - в "середине" документа подключаем

1. Дополнительный CSS со спрайтом для элементов списка - подгружается картинка спрайта и позиционирование в элементах
   

В конце документа (перед закрытием body)

1. Java Script - код для выполнения внутри документа , т.е. не файл
   
2. Яндекс Метрику
   
3. Google Fonts
   
4. SVG иконки в формате text (пример ниже) - около 10 иконок
   

Пример SVG иконки

<svg width="0" height="0" class="hidden">
  <symbol aria-hidden="true" data-prefix="fab" data-icon="vk" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 576 512" id="ico-vk">
    <path d="M545 117.7c3.7-12.5 0-21.7-17.8-21.7h-58.9c-15 0-21.9 7.9-25.6 16.7 0 0-30 73.1-72.4 120.5-13.7 13.7-20 18.1-27.5 18.1-3.7 0-9.4-4.4-9.4-16.9V117.7c0-15-4.2-21.7-16.6-21.7h-92.6c-9.4 0-15 7-15 13.5 0 14.2 21.2 17.5 23.4 57.5v86.8c0 19-3.4 22.5-10.9 22.5-20 0-68.6-73.4-97.4-157.4-5.8-16.3-11.5-22.9-26.6-22.9H38.8c-16.8 0-20.2 7.9-20.2 16.7 0 15.6 20 93.1 93.1 195.5C160.4 378.1 229 416 291.4 416c37.5 0 42.1-8.4 42.1-22.9 0-66.8-3.4-73.1 15.4-73.1 8.7 0 23.7 4.4 58.7 38.1 40 40 46.6 57.9 69 57.9h58.9c16.8 0 25.3-8.4 20.4-25-11.2-34.9-86.9-106.7-90.3-111.5-8.7-11.2-6.2-16.2 0-26.2.1-.1 72-101.3 79.4-135.6z"></path>
  </symbol>

Беспокоит, что ресурсы в середине документа и код SVG иконок в конце как-то влияют на фактическую скорость загрузки и рендеринга. Т.е. важные элементы загружаются чуть позже и из-за этого задерживается отображение.
Вопрос
Как влияет на скорость рендеринга такое подключение ресурсов и как правильно их расположить для ускорения?

Comments

[Сергей delphinpro]

Зачем js в шапке страницы? Ему для выполнения всё равно обычно нужно дожидаться полного построения DOM -> самое место в конце страницы.

Answer 1

[strelok011]

Аналитику в конец. Она не должна влиять на скорость подгрузки значимых элементов и блокировать страницу для пользователя.
SVG как раз лучше в начало, при этом можно поварьировать подход - ссылку на svg-спрайт, либо прямо инлайном запилить в html и вызывать в нужное место просто по id. Если у вас 10 ссылок на декоративные элементы - это плохой подход. На старых http серверах каждый запрос является высоконагруженной операцией для сервера.
Основной js - тоже в конец документа, в самый низ либо подключать асинхронно. Инициализация на документ онлоад.
Суть такого подхода - чем раньше пользователь увидит контент, тем спокойнее он будет и какой-нить гугл спидрейнч вам покажет влияние на первое отображение контента пользователю.
На истину не претендую, рекомендую всё же такой подход и проверку внесенных изменений у гугла.

Comments

[0x131315]

Дополню
Подход со ссылками работает значительно лучше, если сервер корректно работает с кешем или используется CDN.
В этом случае повторного обращения по ссылкам просто не происходит - эффективнее некуда.
Что касается мелких спрайтов - если дошли до такого уровня оптимизаций, их сшивают в карты спрайтов.

[transcend]

Да. Мелкие спрайты объединены в один файл. Просто подключение идет внутри body, а не header

SVG находится инлайн в body - просто в самом конце документа. При этом иконки, которые находятся в этих SVG - используются в самом начале.

Хорошее замечание по поводу основного JS - т.к. по сути там содержится код, обрабатывающий элементы после события onload, т.е. и так необходимо дождаться загрузки.

[transcend]

По сути - получаем, что в начале идут HTML -> элементы стилей CSS -> SVG
Далее подгружаем JS, обрабатывающий эти элементы
После шрифты
В самом конце - аналитику

[Дмитрий]

transcend, не стоит верить всей фигне, что пишут в интернете

>Аналитику в конец.
спорное решение. Асинхронно загруженный скрипт не будет мешать загрузке страницы, но сможет сработать быстрее, чем он же, но добавленный в конец

>SVG как раз лучше в начало
не обязательно
зависит от места, где показан svg на странице

>ссылку на svg-спрайт, либо прямо инлайном запилить в html
не обязательно
добавление ассетов инлайн в страницу увеличивает размер страницы -> боль у мобильных пользователей с плохим каналом

>Если у вас 10 ссылок на декоративные элементы - это плохой подход. На старых http серверах
может стоит вначале выяснить, что у него за сервер? с большой долей вероятности он работает по http/2 или даже что-то новее
для такого типа правильнее делать полностью наоборот - каждый ассет отдельная ссылка

правильный алгоритм для 90% сайтов будет:
инлайним критикал css
все, что не нужно для рендеринга above the fold - откладываем загрузку
но приоритезируем загрузку картинок для above the fold контента (loading=eager)
картинки раздаем в правильном разрешении, в пожатом виде, в подходящем формате

конкретно по вашему сайту
имеет смысл раздавать гугло шрифты с своего сервера, или с CDN, который лежит на вашем домене
так будет выигрыш в ~200 мс для каждого первого запроса к новому домену

дальше смотреть, на что жалуется гугл и тупо выполнять рекомендации