Следующее, это касается и загрузки страницы, и Early Hints - это нюансы работы сети. Даже с HTTP/2 и мультиплексированием запросов, канал пользователя ограничен, и чем больше ресурсов мы запрашиваем, тем сильнее они конкурируют между собой.

Поэтому не стоит загружать сразу все, делать preconnect к десятку доменов, preload всех скриптов и стилей одновременно, надо выбирать приоритеты.
Для разных приложений могут быть совсем специфичные приоритеты, но допустим у нас обычный SSR и советы тоже будут типовые.

Самое важное для отрисовки - это CSS (блокирующий ресурс) и шрифты. Есть много гайдов по оптимизации, тут лишь коротко отмечу несколько полезных вещей:
- инлайн небольших стилей в HTML разметку
- теоретически critical CSS (ни разу не встречал серьезных кейсов использования)
- не использовать веб шрифты или хотя бы выбрать оптимальный font-display
- для предотвращения CLS использовать новые крутые свойства size-adjust и прочие для того что бы fallback шрифт был максимально похож размером на нужный вам - https://screenspan.net/fallback

Следующее - это LCP изображение (если оно изображение, а не текст).
Стоит предусмотреть механизм, который будет автоматически добавлять preload тег с нужным изображением на страницу.
При использовании srcset - обратите внимание на нюансы из этого гайда - https://www.stefanjudis.com/today-i-learned/how-to-preload-responsive-images-with-imagesizes-and-imagesrcset/, самый важный - нельзя добавлять src атрибут для прелоад тега, иначе будет двойная загрузка, кажется в Safari.

Когда наши CSS файлы загружены, хотя бы один из них - можно начинать грузить JS. Такое можно провернуть например через onLoad обработчик для link тега со стилями, tramvai добавляет preload теги для скриптов таким образом.
Но даже если мы хотим пораньше получить интерактивное приложение, при использовании SSR пользователь уже получить какой-то полезный контент, и не стоит блокировать рендеринг приложения нашим джаваскриптом - и всегда использовать атрибут defer.
Да, что-то может сильно задержать событие DOM interactive и соответственно выполнение скриптов, но атрибут async мне не нравится, так как скрипт будет выполнен по завершении не блокирующей загрузки, а выполнение JS это блокирующая операция, и могут быть конфликты к примеру с загрузкой стилей, или доступом к еще не обработанным DOM элементам.

Различную аналитику надо стараться загружать и выполнять настолько поздно, насколько это возможно.
Также очень круто выглядит Partytown, умеющий выполнять скрипты в воркере с полным доступом к DOM.

Последнее что вспомнил - это водопад загрузки скриптов и стилей для конкретной страницы.
Если вы заботитесь о пользователях и используете разделение кода по роутам и тяжелым компонентам, важно загружать ресурсы нужные именно для этой страницы параллельно.
Мета-фреймворки решают эту задачу из коробки, и при отрисовке страницы на сервере, и при SPA-переходах.
Но классические SPA-приложения, исключительно с клиентским рендерингом, всегда будут страдать от этой проблемы, так как на одной общей index.html точке входа в приложение мы не можем сразу добавить ресурсы для всех роутов приложения.
SSG заглушек для каждой страницы будет более предпочтительным вариантом, хоть у него и есть свои ограничения.

Расскажите про оптимизации флоу загрузки ресурсов на ваших приложениях, какие-то интересные подходы и лайфхаки, детали о которых я забыл рассказать?