К сожалению, JAMStack не снискал на просторах СНГ такой популярности.
Да и вопросики к нему есть в плане форм, личных кабинетов, поиска и тд. Нужно что-то из этого? Ищешь SaaS решение и интегрируешь его, а потом ещё n$/мес платишь за подписку. А оно может не работать из-за геолокации. Потом к этому всему ещё нужно какой-нибудь strapi прикрутить, чтоб заказчик мог редактировать контент.
Выходит, что заказчику проще не рисковать, а найти фрилансера/веб студию и сделать сайт на WordPress. Всё понятно, плагинов миллиард, разработчиков много, ценник приемлемый, менеджеры, сеошники, контентщики работать с админкой умеют.
А так согласен, SSG крутая штука, жаль не сильно популярная у нас
2к разрешение мобильных девайсов не то же самое, что ширина в CSS. Моё устройство, с которого я пишу комментарий, имеет разрешение 1080×2310, но в рамках @media его размер 360×770.
Что касается handheld и тд - эти значения из старой спеки Media Queries Level 3. В Level 4 они deprecated и ничему не сопоставляются.
Вот и мне так казалось. Но при этом я больше одного раза слышал упоминание jekyll в контексте Jamstack.
Да, потому что Jekyll это старожил среди генераторов и одно из самых популярных решений. Также часто можно услышать про gatsby в контексте Jamstack. Эти генераторы есть чуть ли не на любом языке и под любой шаблонизатор, полный список тут.
Забавно, конечно. Использование JS — ок. Использование встроенных DSL, как в Jekyll — ок. А использование других языков программирования — не ок?
Суть в том, что это преподносится как фронтенд-решение, поэтому другие языки не ок. При том под капотом генератор может быть написан на чём угодно. Суть же первой буквы в JavaScript и последней в Markup. Под Markup понимается как обычный HTML, так и другие форматы разметки, например markdown, шаблонизаторы, и да, XSLT тоже можно тоже к этому отнести
Основное преимущество - высокая скорость отдачи контента, а как следствие - хорошие показатели Web Vitals. Достигается за счёт того, что на сервере лежат готовые html-файлы, которые сразу отдаются пользователю по запросу. Нет расходов на поход в базу, обработку данных, построение view, обработку роутов и тд. Ну и размещение на CDN тоже часто позволяет скорость отдачи увеличить.
Другое преимущество - безопасность. Файлы лежат в виде обычных html на простейшем хостинге статики, там нечего взламывать, чем в случае с CMS по типу WordPress. А если используется Headless CMS, то безопасность уже гарантируется поставщиком этой CMS.
Для простых небольших проектов это ещё и дёшево. Хранить статику сейчас очень дёшево, а иногда и вообще бесплатно. Плюс есть куча сервисов с бесплатными тарифами, тот же Netlify даёт в бесплатном пакете все необходимое для блога - ci, интеграцию с гит-хостингами, безлимит по количеству сайтов, имеет интеграцию со многими популярными генераторами. Поэтому можно собрать сайт и платить только за домен.
Ну и ещё к преимуществам можно отнести то, что это frontend-based решение и оно позволяет фронтам не разбираться с бэкендом, абстрагируясь от этого.
JAMStack хорошо подходит для блогов, новостных сайтов, документации, wiki-ресурсов, для визиток и корпоративных сайтов. Хотя создают и eCommerce на нем.
Хотя, впрочем, один вопрос остается: разве jekyll или hygo — это то, чем фронтенд-разработчик пользуется в нормальной привычной жизни?
Скажем так, конкретно эти и некоторые другие генераторы не то, чем активно пользуются фронты. Но спасоб написания привычный - html-шаблоны с markdown, шаблонизатором (в случае Jekyll это liquid) и JavaScript. Говоря о шаблонизаторах, это привычная для фронтов штука и в целом они сильно друг на друга похожи (тот же liquid, nunjucks и twig почти близнецы).
Однако если jekyll штука специфическая, то можно взять Gatsby и писать на React со всеми сопутствующими вещами. И это уже ближе к тому, чем фронты обычно занимаются.
Jekyll вон вроде бы вообще на Ruby, и темплейтинг там свой собственный.
Даже если у вас будет какая-то своя программа, скажем, на Java, которая даёт возможность создавать шаблоны без написания Java-кода при помощи фронтенда, при этом умеет из этих шаблонов собрать статические html-ки, правильно настраивать роутинг, обрабатывать ресурсы и давать вспомогательный инструментарий для разработчика, то по сути это тоже будет статический генератор и такой сайт попадёт под понятие JAMStack.
Хотя более каноничным, что-ли, считается подход, когда генератор написан на js, сборка на js, шаблоны на html+js или шаблонизаторе. Тогда фронты максимально абстрагируются от других языков, их экосистем, пакетных менеджеров и необходимости что-то разворачивать.
Если откинуть детали, то JAMStack-сайт не отличается от простого статического сайта, по типу тех, что делали в 90е-00е. Идея JAMStack в том и состоит, чтобы заранее сгенерировать кучу .html файликов, положить их на любой хостинг и оттуда раздавать со всеми вытекающими плюсами и минусами.
JAMStack говорит: "давайте возьмём идею готовых статических страниц из прошлого, доработаем её, добавим привычные и хорошо знакомые фронтенд-разработчикам инструменты, сложные детали и логику спрячем за SaaS решениями (если нужны, можно и без них), создадим вокруг этого экосистему и дадим фронтенд-разработчикам".
Ключевая особенность в том, что сайт создаётся силами фронтенд-разработчика на привычном для него инструменте, будь то обычный html или react, или ещё что-то. Собирается это тоже любым привычным инструментом, будть то grunt, gulp, webpack, vite, либо же специализированными генераторами, вроде jekyll, hygo, eleventy. Данные для страниц тоже берутся привычным способом - запрос к API с получением json через fetch, XHR или какой-нибудь GraphQL. Деплоится это тоже привычным способом - git push, а дальше путем нажатий пары кнопок, авторизации через гитхаб и некоторой магии, это все оказывается, на амазоновском облаке, на CDNке или где-то ещё (смотря что выбрать).
То есть фронтенд-разработчик может сам сделать шаблоны, настроить получение и вывод данных, логику отображения. И все без привлечения бекенд-разработчика и вообще без разработки бекенда. Не надо ковыряться в php, лазить на хостинги, настраивать htaccess-ы, смотреть таблички в базе, переживать что админку взломают. Взял, написал на своих технологиях, сбилдил, залил - статический сайт готов. А все остальное дают сервисы.
Согласен, есть такой момент с объединением. Но если ваш ресурс на русском, можно сделать свой сабсет кириллицы, но ещё добавить в него цифры, знаки препинания и прочие подобные символы. А латиницу сделать другим сабсетом на случай англоязычных надписей, но без знаков препинания, цифр. Тогда если на странице нет латиницы, она не загрузится (при условии грамотного указания unicide-range). Ну а если есть, чтож, догрузится и она.
Но если у вас гарантировано на странице будет кириллица+знаки и латиница, тогда и делить смысла нет, это справедливо.
А вы, видимо, даже не задавались вопросом, ЗАЧЕМ сокращать блокировку основного потока. Т.е. даже не гуглили, потому что гугл как раз объясняет в первом же ответе, ссылкой на лайтхаус (бывший pagespeed).
Я знаю, зачем нужно сокращать время блокировки потока. Но это вы пишите что это (блокировка потока) нам (кому?) и нужно. Из вашего ответа я делаю вывод, что вам нужна блокировка, что вызывает у меня недоумение и вопрос "зачем".
будет, да. Но если только вы не сопливый стартапер из ООО "три студента", у вас в конторе есть дизайнер с арт-директором. И они вас за "системный шрифт" просто уволят за профнепригодность.
Так мы, кажется, говорим в вакууме о возможностях оптимизации работы со шрифтами, а не о конкретном сайте. И отказ от шрифта это один из способов. И вполне годится для личного блога или чего-то такого. Для случаев с брендбуком и дизайнерами есть другие решения, о которых я говорил.
Ну просто пример, из недавних. Если Times слишком мелкий, то вот этот - очень крупный. И страница без инлайнинга этого шрифта просто кровь-кишки-разваливается при его загрузке, при любом значении font-display
А где я про замену говорю? Сабсеттинг это разбиение большого файла шрифта, допустим с 400 глифами, на несколько файлов с меньшим количеством глифов и подключением его через свойство unicode-range. В итоге если на странице нет ни одного символа из сабсета, файл просто не будет загружаться. Возможно это то, что вам нужно.
Ну не знаю... Все пытаются избежать или сократить насколько возможно блокировку основного потока для более быстрого рендеринга страницы. У вас, видимо, свой путь, если вам блокировка нужна. Интересно ваше мнение, зачем она нужна.
Да, только он передаётся сжатым. А gzip/brottli от base64 от файла будет весить на 0,1% больше. Проверено
Попробую на досуге проверить. Однако даже от самых заядлых оптимизиторов, назовём их так, я таких советов не слышал и никогда в проде такое не встречал.
Нет, не единственный. Во-первых, указанное вами решение не работает, ну по крайней мере для не-английских сайтов. Во-вторых, описанное мной - единственное, которое работает.
Не "прыгает" шрифт если его нет. В том смысле, что нет деклараций. Тогда будет использоваться системный шрифт из системы. Причем доя кириллицы тоже. Об этом и речь - если отказаться от кастомных шрифтов, прыжков не будет. Если кастомный шрифт есть, он может не прыгать, если загрузится достаточно быстро.
Нет конечно. Вы, прежде чем переписывать методичку твиттора, хотя бы попробуйте заменить какой-нибудь Tactic Sans на системный шрифт.
Твиттер не читаю, тут мимо. Сказанное основывается на моих экспериментах, копании в сайтах и чтении пары публикаций от Adobe (думаю в шрифтах они разбираются лучше нас). Не знаю причём тут замена шрифта tactic sans и сабсеттинг (который подразумевает разделение шрифта на более мелкие сабсеты), о котором я писал в сообщении, которое вы цитируете.
Бесспорно можно инлайнить. Только вот base64 от файла со шрифтом будет весить в среднем на 20-30% больше, чем просто файл со шрифтом. 2-3 таких инлайна и размер файла CSS увеличивается, следовательно он дольше загружается и дополнительные (пусть и небольшие) накладные расходы на преобразование. А CSS ресурс блокирующий.
Единственный способ избежать "прыжков" шрифта - использовать system-ui и перечень web-safe шрифтов.
Далее если шрифт сабсетить по набору глифов, использовать unicode-range в сочетании с предзагрузкой, это тоже позволит избежать прыжков в большинстве случаев.
В HTML можно изменить приоритет загрузки и получить шрифт к моменту, когда парсер CSS его обнаружит. Можно ещё заинлайнить подключение в HTML, тогда он просто будет обнаружен чуть раньше.
Говоря про CSS, там можно лишь влиять на поведение браузера до загрузки шрифта (отображать ли стандартный шрифт, подождать немного или ничего не показывать до окончания загрузки).
Шрифты, конечно, можно загрузить асинхронно, но это уже требует js. Но так не делают, асинхронная загрузка шрифта приводит к перерисовкам (FOUT), а с этим как раз и пытаются бороться вышеуказанными способами в HTML/CSS.
Но ведь не одними новыми проектами едины. Есть куча старых проектов, которые просто работают, приносят владельцам деньги и привычны для пользователей. Они просто существуют и нуждаются в поддержке, доработке. При этом не сильно гонятся за стеком и не занимаются постоянным переписыванием с одной технологии на другую потому что модно. В той же Jira много jquery по сей день, как пример.
Кроме того, есть другой рынок - разработка небольших сайтов, лендингов и визиток для ИП, малого и среднего бизнеса. Этим занимаются агентства, веб-студии и фрилансеры. Там не нужен react с graphql, BFF и северным рендерингом на node. Там WordPress, Bitrix, плагинчики на jquery, чтобы быстрее все сделать и взять следующий проект. Просто потому что не те бюджеты и сроки у заказчиков, соответственно и обеспечивать толкового фронтендера хотя-бы junior+/middle- уровня, который будет делать реакты, тоже не получится.
Ну и если для кого-то jquery решает проблему бизнеса и приносит доход, то какая разница, главное это продукт
Про hgroup стоит лишь сказать, что его нет смысла использовать: он не работает так, как описано в спецификации из-за того, что ни в один из браузеров не внедрен структурный алгоритм (structure outline), поскольку с ним есть проблемы.
В статье про оптимизацию используется preloader и gif, что на мой взгляд как раз работает в обратную сторону.
Формат gif сам по себе очень тяжелый и вес одного такого прелоадера может доходить до мегабайт. Оптимальнее сделать svg, вставить его прямо в html и добавить простую анимацию через rotate(). Анимацию можно заинлайнить прямо в svg, а стили остального прелоадера прописать в <style>. В итоге мы избавляемся от двух запросов за ресурсами и уменьшаем размер самого прелоадера. Или же можно конвертировать gif в видео, вставить при помощи тега <video> с атрибутами muted, autoplay и loop.
Но вообще лучше обходиться вовсе без него, потому как прелоадер сильно влияет на показатель Cumulative Layout Shift. Да и многих пользователей прелоадер скорее раздражает.
Также в предзагрузке шрифта есть опечатка. Подключается woff2, а mime type стоит ttf.
Раньше сайт мог влезать в 2-3 экрана, сейчас нужно делать страницу в 10 экранов, ибо дизайнер так видит, а маркетолог так продаёт.
Раньше сверстал под десктоп, а сейчас кучу медиа-запросов делаешь чтобы везде всё адаптивненько было.
Раньше формы отправлялись нативным button или input с типом submit, а валидация происходила на сервере, сейчас же надо красиво на клиенте всё обработать и подсветить красненьким.
Раньше всё было статично и "деревянно", сейчас же табы, дропдауны, попапы, слайдеры, анимации, и прочий интерактив.
Не говоря уже про SPA, всякие дашборды и WEB-приложения, заменяющие полноценные десктоп-программы.
Есть всякие хаки на эту тему. Например вставлять фоновые картинки тегом и абсолютно позиционировать, добавляя aria-hidden. Или же на сервере проверять заголовок accept, вешать класс на body, и уже через каскад вешать тот или иной формат в зависимости от класса. Да, это все костыли, но тем не менее, пока поддержки image-set() нет, можно использовать
Семантические теги в принципе можно разделить на полезные и не очень. Полезные влияют на SEO, улучшают доступность и UX во вспомогательных технологиях. Бесполезные же (как тот же i, b и в принципе многие элементы семантики текста) либо вообще не оказывают никакого влияния, либо оно крайне незначительно
Про b действительно так написано. Но вот i далеко не курсив. Был курсивом до HTML5, а в нем был переработан и получил новую семантическую нагрузку. Теперь он означает термины, идеоматические фразы, транслитерацию, иностранные фразы или текст, который каким-то образом отличается по произношению от остального текста. И об этом написано в живом стандарте
К сожалению, JAMStack не снискал на просторах СНГ такой популярности.
Да и вопросики к нему есть в плане форм, личных кабинетов, поиска и тд. Нужно что-то из этого? Ищешь SaaS решение и интегрируешь его, а потом ещё n$/мес платишь за подписку. А оно может не работать из-за геолокации. Потом к этому всему ещё нужно какой-нибудь strapi прикрутить, чтоб заказчик мог редактировать контент.
Выходит, что заказчику проще не рисковать, а найти фрилансера/веб студию и сделать сайт на WordPress. Всё понятно, плагинов миллиард, разработчиков много, ценник приемлемый, менеджеры, сеошники, контентщики работать с админкой умеют.
А так согласен, SSG крутая штука, жаль не сильно популярная у нас
2к разрешение мобильных девайсов не то же самое, что ширина в CSS. Моё устройство, с которого я пишу комментарий, имеет разрешение 1080×2310, но в рамках
@mediaего размер 360×770.Что касается
handheldи тд - эти значения из старой спеки Media Queries Level 3. В Level 4 они deprecated и ничему не сопоставляются.Да, потому что Jekyll это старожил среди генераторов и одно из самых популярных решений. Также часто можно услышать про gatsby в контексте Jamstack. Эти генераторы есть чуть ли не на любом языке и под любой шаблонизатор, полный список тут.
Суть в том, что это преподносится как фронтенд-решение, поэтому другие языки не ок. При том под капотом генератор может быть написан на чём угодно. Суть же первой буквы в JavaScript и последней в Markup. Под Markup понимается как обычный HTML, так и другие форматы разметки, например markdown, шаблонизаторы, и да, XSLT тоже можно тоже к этому отнести
Так jekyll и является одним из вариантов создания сайта на JAMStack
Основное преимущество - высокая скорость отдачи контента, а как следствие - хорошие показатели Web Vitals. Достигается за счёт того, что на сервере лежат готовые html-файлы, которые сразу отдаются пользователю по запросу. Нет расходов на поход в базу, обработку данных, построение view, обработку роутов и тд. Ну и размещение на CDN тоже часто позволяет скорость отдачи увеличить.
Другое преимущество - безопасность. Файлы лежат в виде обычных html на простейшем хостинге статики, там нечего взламывать, чем в случае с CMS по типу WordPress. А если используется Headless CMS, то безопасность уже гарантируется поставщиком этой CMS.
Для простых небольших проектов это ещё и дёшево. Хранить статику сейчас очень дёшево, а иногда и вообще бесплатно. Плюс есть куча сервисов с бесплатными тарифами, тот же Netlify даёт в бесплатном пакете все необходимое для блога - ci, интеграцию с гит-хостингами, безлимит по количеству сайтов, имеет интеграцию со многими популярными генераторами. Поэтому можно собрать сайт и платить только за домен.
Ну и ещё к преимуществам можно отнести то, что это frontend-based решение и оно позволяет фронтам не разбираться с бэкендом, абстрагируясь от этого.
JAMStack хорошо подходит для блогов, новостных сайтов, документации, wiki-ресурсов, для визиток и корпоративных сайтов. Хотя создают и eCommerce на нем.
Скажем так, конкретно эти и некоторые другие генераторы не то, чем активно пользуются фронты. Но спасоб написания привычный - html-шаблоны с markdown, шаблонизатором (в случае Jekyll это liquid) и JavaScript. Говоря о шаблонизаторах, это привычная для фронтов штука и в целом они сильно друг на друга похожи (тот же liquid, nunjucks и twig почти близнецы).
Однако если jekyll штука специфическая, то можно взять Gatsby и писать на React со всеми сопутствующими вещами. И это уже ближе к тому, чем фронты обычно занимаются.
Даже если у вас будет какая-то своя программа, скажем, на Java, которая даёт возможность создавать шаблоны без написания Java-кода при помощи фронтенда, при этом умеет из этих шаблонов собрать статические html-ки, правильно настраивать роутинг, обрабатывать ресурсы и давать вспомогательный инструментарий для разработчика, то по сути это тоже будет статический генератор и такой сайт попадёт под понятие JAMStack.
Хотя более каноничным, что-ли, считается подход, когда генератор написан на js, сборка на js, шаблоны на html+js или шаблонизаторе. Тогда фронты максимально абстрагируются от других языков, их экосистем, пакетных менеджеров и необходимости что-то разворачивать.
Вклинюсь в дискуссию.
Если откинуть детали, то JAMStack-сайт не отличается от простого статического сайта, по типу тех, что делали в 90е-00е. Идея JAMStack в том и состоит, чтобы заранее сгенерировать кучу
.htmlфайликов, положить их на любой хостинг и оттуда раздавать со всеми вытекающими плюсами и минусами.JAMStack говорит: "давайте возьмём идею готовых статических страниц из прошлого, доработаем её, добавим привычные и хорошо знакомые фронтенд-разработчикам инструменты, сложные детали и логику спрячем за SaaS решениями (если нужны, можно и без них), создадим вокруг этого экосистему и дадим фронтенд-разработчикам".
Ключевая особенность в том, что сайт создаётся силами фронтенд-разработчика на привычном для него инструменте, будь то обычный html или react, или ещё что-то. Собирается это тоже любым привычным инструментом, будть то
grunt,gulp,webpack,vite, либо же специализированными генераторами, вродеjekyll,hygo,eleventy. Данные для страниц тоже берутся привычным способом - запрос к API с получением json черезfetch,XHRили какой-нибудьGraphQL. Деплоится это тоже привычным способом -git push, а дальше путем нажатий пары кнопок, авторизации через гитхаб и некоторой магии, это все оказывается, на амазоновском облаке, на CDNке или где-то ещё (смотря что выбрать).То есть фронтенд-разработчик может сам сделать шаблоны, настроить получение и вывод данных, логику отображения. И все без привлечения бекенд-разработчика и вообще без разработки бекенда. Не надо ковыряться в php, лазить на хостинги, настраивать htaccess-ы, смотреть таблички в базе, переживать что админку взломают. Взял, написал на своих технологиях, сбилдил, залил - статический сайт готов. А все остальное дают сервисы.
Согласен, есть такой момент с объединением. Но если ваш ресурс на русском, можно сделать свой сабсет кириллицы, но ещё добавить в него цифры, знаки препинания и прочие подобные символы. А латиницу сделать другим сабсетом на случай англоязычных надписей, но без знаков препинания, цифр. Тогда если на странице нет латиницы, она не загрузится (при условии грамотного указания unicide-range). Ну а если есть, чтож, догрузится и она.
Но если у вас гарантировано на странице будет кириллица+знаки и латиница, тогда и делить смысла нет, это справедливо.
Я знаю, зачем нужно сокращать время блокировки потока. Но это вы пишите что это (блокировка потока) нам (кому?) и нужно. Из вашего ответа я делаю вывод, что вам нужна блокировка, что вызывает у меня недоумение и вопрос "зачем".
Так мы, кажется, говорим в вакууме о возможностях оптимизации работы со шрифтами, а не о конкретном сайте. И отказ от шрифта это один из способов. И вполне годится для личного блога или чего-то такого. Для случаев с брендбуком и дизайнерами есть другие решения, о которых я говорил.
А где я про замену говорю? Сабсеттинг это разбиение большого файла шрифта, допустим с 400 глифами, на несколько файлов с меньшим количеством глифов и подключением его через свойство unicode-range. В итоге если на странице нет ни одного символа из сабсета, файл просто не будет загружаться. Возможно это то, что вам нужно.
Ну не знаю... Все пытаются избежать или сократить насколько возможно блокировку основного потока для более быстрого рендеринга страницы. У вас, видимо, свой путь, если вам блокировка нужна. Интересно ваше мнение, зачем она нужна.
Попробую на досуге проверить. Однако даже от самых заядлых оптимизиторов, назовём их так, я таких советов не слышал и никогда в проде такое не встречал.
Не "прыгает" шрифт если его нет. В том смысле, что нет деклараций. Тогда будет использоваться системный шрифт из системы. Причем доя кириллицы тоже. Об этом и речь - если отказаться от кастомных шрифтов, прыжков не будет. Если кастомный шрифт есть, он может не прыгать, если загрузится достаточно быстро.
Твиттер не читаю, тут мимо. Сказанное основывается на моих экспериментах, копании в сайтах и чтении пары публикаций от Adobe (думаю в шрифтах они разбираются лучше нас). Не знаю причём тут замена шрифта tactic sans и сабсеттинг (который подразумевает разделение шрифта на более мелкие сабсеты), о котором я писал в сообщении, которое вы цитируете.
Бесспорно можно инлайнить. Только вот base64 от файла со шрифтом будет весить в среднем на 20-30% больше, чем просто файл со шрифтом. 2-3 таких инлайна и размер файла CSS увеличивается, следовательно он дольше загружается и дополнительные (пусть и небольшие) накладные расходы на преобразование. А CSS ресурс блокирующий.
Единственный способ избежать "прыжков" шрифта - использовать system-ui и перечень web-safe шрифтов.
Далее если шрифт сабсетить по набору глифов, использовать unicode-range в сочетании с предзагрузкой, это тоже позволит избежать прыжков в большинстве случаев.
В HTML можно изменить приоритет загрузки и получить шрифт к моменту, когда парсер CSS его обнаружит. Можно ещё заинлайнить подключение в HTML, тогда он просто будет обнаружен чуть раньше.
Говоря про CSS, там можно лишь влиять на поведение браузера до загрузки шрифта (отображать ли стандартный шрифт, подождать немного или ничего не показывать до окончания загрузки).
Шрифты, конечно, можно загрузить асинхронно, но это уже требует js. Но так не делают, асинхронная загрузка шрифта приводит к перерисовкам (FOUT), а с этим как раз и пытаются бороться вышеуказанными способами в HTML/CSS.
В любой системе, будь то Windows, macos, и тд есть набор стандартных шрифтов, причём с щасечками, без засечек и моноширинный (как раз для кода).
Кроме того, шрифты грузятся синхронно, потому что они нужны для отрисовки страницы (браузер по ним считает размеры).
Но ведь не одними новыми проектами едины. Есть куча старых проектов, которые просто работают, приносят владельцам деньги и привычны для пользователей. Они просто существуют и нуждаются в поддержке, доработке. При этом не сильно гонятся за стеком и не занимаются постоянным переписыванием с одной технологии на другую потому что модно. В той же Jira много jquery по сей день, как пример.
Кроме того, есть другой рынок - разработка небольших сайтов, лендингов и визиток для ИП, малого и среднего бизнеса. Этим занимаются агентства, веб-студии и фрилансеры. Там не нужен react с graphql, BFF и северным рендерингом на node. Там WordPress, Bitrix, плагинчики на jquery, чтобы быстрее все сделать и взять следующий проект. Просто потому что не те бюджеты и сроки у заказчиков, соответственно и обеспечивать толкового фронтендера хотя-бы junior+/middle- уровня, который будет делать реакты, тоже не получится.
Ну и если для кого-то jquery решает проблему бизнеса и приносит доход, то какая разница, главное это продукт
Про
hgroupстоит лишь сказать, что его нет смысла использовать: он не работает так, как описано в спецификации из-за того, что ни в один из браузеров не внедрен структурный алгоритм (structure outline), поскольку с ним есть проблемы.В статье про оптимизацию используется preloader и gif, что на мой взгляд как раз работает в обратную сторону.
Формат gif сам по себе очень тяжелый и вес одного такого прелоадера может доходить до мегабайт. Оптимальнее сделать svg, вставить его прямо в html и добавить простую анимацию через rotate(). Анимацию можно заинлайнить прямо в svg, а стили остального прелоадера прописать в <style>. В итоге мы избавляемся от двух запросов за ресурсами и уменьшаем размер самого прелоадера. Или же можно конвертировать gif в видео, вставить при помощи тега <video> с атрибутами muted, autoplay и loop.
Но вообще лучше обходиться вовсе без него, потому как прелоадер сильно влияет на показатель Cumulative Layout Shift. Да и многих пользователей прелоадер скорее раздражает.
Также в предзагрузке шрифта есть опечатка. Подключается woff2, а mime type стоит ttf.
Ну на самом деле изменилось довольно много всего.
Раньше сайт мог влезать в 2-3 экрана, сейчас нужно делать страницу в 10 экранов, ибо дизайнер так видит, а маркетолог так продаёт.
Раньше сверстал под десктоп, а сейчас кучу медиа-запросов делаешь чтобы везде всё адаптивненько было.
Раньше формы отправлялись нативным button или input с типом submit, а валидация происходила на сервере, сейчас же надо красиво на клиенте всё обработать и подсветить красненьким.
Раньше всё было статично и "деревянно", сейчас же табы, дропдауны, попапы, слайдеры, анимации, и прочий интерактив.
Не говоря уже про SPA, всякие дашборды и WEB-приложения, заменяющие полноценные десктоп-программы.
Есть всякие хаки на эту тему. Например вставлять фоновые картинки тегом и абсолютно позиционировать, добавляя aria-hidden. Или же на сервере проверять заголовок accept, вешать класс на body, и уже через каскад вешать тот или иной формат в зависимости от класса. Да, это все костыли, но тем не менее, пока поддержки image-set() нет, можно использовать
Семантические теги в принципе можно разделить на полезные и не очень. Полезные влияют на SEO, улучшают доступность и UX во вспомогательных технологиях. Бесполезные же (как тот же i, b и в принципе многие элементы семантики текста) либо вообще не оказывают никакого влияния, либо оно крайне незначительно
Про b действительно так написано. Но вот i далеко не курсив. Был курсивом до HTML5, а в нем был переработан и получил новую семантическую нагрузку. Теперь он означает термины, идеоматические фразы, транслитерацию, иностранные фразы или текст, который каким-то образом отличается по произношению от остального текста. И об этом написано в живом стандарте