Привет!

Хочется подвести какой-то полезный итог всей истории по preconnect и по загрузке ресурсов в целом.

Лучшее что мы можем сделать - это вообще не использовать CDN.
А точнее, сделать так что бы CDN был на домене нашего приложения - например такую инфраструктуру предлагает Vercel.
Отказываться от преимуществ CDN не хочется и не нужно)
Тогда все основные ресурсы приложения можно раздавать с того же доменного имени, при использовании HTTP/2 будет создан только один TCP сокет при запросе самого HTML документа, и никаких дополнительных накладных расходов на установку соединения в тот момент, когда браузер перейдет к скачиванию CSS и прочих ресурсов.

Это большие изменения инфраструктуры, и компромиссом будет иметь максимум один домен для CDN, но тут мы можем столкнуться с проблемой разных значений атрибута crossorign - и все-равно получим лишнее TCP соединение, установка которого может отложить загрузку наших критичных скриптов или например LCP изображения.

crossorign="anonymous" - действительно важный атрибут для скриптов со сторонних доменов, если мы хотим качественный мониторинг ошибок.
И раз мы вынуждены использовать его для скриптов и шрифтов, кажется что лучше всего так же по умолчанию добавлять его и для стилей и для изображений.
Также, не забывать и про preload теги, если атрибут crossorign не совпадает, то предзагруженный контент не будет переиспользован.

Но допустим мы не контролируем в приложении отрисовку изображений или добавление части ресурсов.
Для решения этой проблемы может помочь <link rel="preconnect" href="https://example.com" /> для CDN, которому также будет важен crossorign - это зависит от вашего водопада критичных запросов за ресурсами, какой preconnect стоит использовать.

Еще больше ускорить загрузку помогут Early Hints - если вы рендерите приложение на сервере, и делаете запросы в сторонние API, блокирующие рендер, отдать все необходимые preconnect и preload теги в самом начале обработки запроса - в теории бесценно.
На практике, есть нюансы, и для нас пока главный инфраструктурный - 103 код ответа не уходит из нашего k8s кластера (research in progress).
Хотя по документации Envoy балансер (используется в k8s) поддерживает 103 код, хоть и с ограничением - отдает только первый, но по спецификации можно отдать сколько угодно 103 ответов до 200 финального.
В другой инфраструктуре балансер вообще не смог распарсить и проксировать Early Hints и не отдавал страничку, хорошо что мы с нее переезжаем и не надо копать в эту сторону.