Комментарии 11
Точнее постановку костылей.
1. Идет запрос к серверу — покажи мне страницу page1.
2. Сервер что-то у себя там ищет, может быть обрабатывает какие то скрипты, формирует страницу. Все это занимает скажем 100мс. Через 100 мс шлет ответ — текст страницы.
То есть эти 100мс, бруазер стоит и ничего не делает. Хотя уже целых 100мс мог бы грузить какую то статику.
Так вот суть предложения в том, чтобы усовершентсвовать протокол таким образом, чтобы серверная часть, получив запрос на страницу, прежде чем приступать к ее генерации, сразу могла вернуть ответ который бы позволил браузеру загрузить какую нибудь статику.
Картинки, css, шрифты и так далее.
В некоторых случаях это действительно может дать очень серьезное ускорение в работе проекта.
И это нисколько не костыль, сколько оптимизация под реальные условия.
Суть в том, что этот механизм будет работать только при условии грамотного и вдумчивого использования. А так уже никто не делает. 95% сайтов делаются по принципу «тяп-ляп, react, и в production». Соответственно, все эти preload-ссылки будут генерироваться автоматически, и подгружать тонны мусора.
Это костыль, потому что подразумевает вдумчивую и ручную оптимизацию, которую никто делать не станет.
Так же, как !important — предназначался для очень специфичных случаев. Но в итоге, многие разработчики каждый раз добавляя что-то в стили, приписывают в конце !important, чтобы «наверняка работало». После чего поддерживать стили становится очень сложной задачей.
Теперь гении Javascript напишут какой-нибудь UnicornBundler, который будет автоматом генерировать бандл из preload ссылок на все используемые стили и скрипты из package.json. Пускай браузер грузит на каждый чих 2,500 дополнительных ссылок. Все станет еще быстрее!
Поэтому есть смысл не использовать веб-шрифты для обычных (не-дизайнерских) сайтов. Зачем они нужны? В мелком тексте все равно трудно отличить один шрифт от другого. Пользы от них ноль, а отображение страницы они замедляют.
Пример: раньше мануал PHP использовал стандартные шрифты. Потом перешел на кастомные — и теперь при открытии страницы из Гугла секунду-две приходится смотреть на страницу без текста. Ну дебилы же, чесслово. Я теперь больше времени трачу из-за них.
Причем если посмотреть инструменты разработчика, они там что-то кешировать пытаются. Когда можно просто использовать стандартный шрифт.
И еще косяк в CSS это проблема, что подключенный шрифт может не содержать все нужные символы (например, иностранные алфавиты) и нельзя указать фоллбек на стандартный шрифт. Ну кто это проектировал, наверно американец какой-то который кроме латинницы ничего не использует и проблемы в упор не видит. Впрочем, HTML/CSS он всегда был такой кривой и проблемный, сколько я помню.
> Особенно для шрифтов, но что угодно может стать критическим ресурсом, например, файл данных, необходимый для загрузки приложения JavaScript.
Ну так вставьте все данные в страницу, чтобы они сразу могли отображаться и не городите переусложенные яваскрипт-приложения.
Стремление городить костыли, конечно, поражает.
И с каких же это пор в css нельзя указывать фолбеки на стандартный шрифт? Вот совсем недавно видел:
.ff-slab {
font-family: 'Roboto Slab', serif;
}Я имел в виду фоллбек вида «если в этом шрифте нет иероглифа, взять его из другого шрифта, а не рисовать квадратик». Эта проблема по моему актуальна, так как большинство шрифтов содержат только ограниченный набор символов (иначе бы они весили десятки мегабайт), а отображать в идеале надо все символы.
На сайте для заголовков используется шрифт Roboto Slab, но в версии шрифта с сайта нет кириллицы, поэтому заголовки отображаются стандартным системным шрифтом.
Одна проблема с rel=preload: этот мета-тег не совместим с script type=module и nomodule. Чтобы разруливать эту ситуацию, надо читать user-agent сервером пререндера и соответствующим образом формировать html. Но тогда более логичным выглядит http2 push (ну или Early Hints). А если нет сервера пререндера, то приходится выбирать: либо доставка 90% аудитории ES2017 кода, либо preload. И первый выбор кажется намного вкуснее.
Буду использовать
Любая страница должна грузиться максимально быстро, а тяжёлый контент должен грузиться либо только по запросу пользователя, либо если основной контент уже загружен, и доступен пользователю, чтобы пользователю не пришлось ждать.
Ускорение сайтов с помощью «ранних подсказок»