Уже нашел проблему в sitemap.xml , там оказывается был указан другой домен 😭
Ну, к примеру, Клаудфлара анализирует html и все прелоады запихивает в хинты.... но пока beta
Короче, напридумывали реально хороших технологий, но за годы так и не довели до ума. А еще кричат на каждом углу о оптимизации - но толку, если отсылки на большинство методов так и не заработали даже на 50%. Хрен там по итогу: самая лучшая оптимизация это еще дедовский html со встроенной css , изображениями в base64 и системными шрифтами.
В nginx скорее всего если 103 пойдет в массы допилят модуль подключаемый, как с Brotli получилось.
а какая тогда будет альтернатива?
зы. по тестам этот хваленый прелоад так и не начал правильно работать: хоть в заголовках отправь, хоть в html - единственное, что срабатывает это preconnect, а загрузка всё равно начинается только после 100% загрузки основного html, а не в процессе парсинга, как стандарт требует. только на картинках в говнобложиках всё красиво.
Там, в теме, уже ответили - вполне быстрый Cloudflare.
А вообще про сотого юзера - не забывайте в каких еб*нях он может находиться: там что не делай, а тормоза будут. Даже сервисы проверки типа Webpagetest иногда печальное, выбивающееся из статистики, время показывают - согласитесь, у них каналы тоже не резиновые и иногда "затыки" бывают.
Абсолютно глупая затея. Вебпуш нужен только для "сиюминутных" данных, которые относятся только к конкретной странице и только сейчас.
Делал эксперименты с пушем лого и css - всё проталкивается, но время загрузки очень сильно возростает, а также до конца не проработан механизм кеширования в браузерах пуш-контента. Плюс при каждом новом просмотре вебсервер проталкивает заново то, что уже протолкнуто в предыдущем просмотре (можно в сессиях хранить информацию о том, что протолкнуто - но это уже вторая глупая затея).
Всё в сравнении :) Крутите на здоровье, будет только лучше!
Как минимум так:
ssl_session_cache shared:SSL:20m; #он вообще по дефолту в nginx "мягко" отключен ssl_session_timeout 60m; #по дефолту стоит 5 минут ssl_buffer_size 1400; #по дефолту стоит 16к, но в мунуале же написано " С целью минимизации времени получения начала ответа (Time To First Byte) может быть полезно использовать меньшие значения, например: 4к"
