Defront — про фронтенд-разработку и не только
12.8K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Крис Закариас написал занимательный пост "A Conspiracy To Kill IE6" про то, как Youtube начал движение против IE6.

IE6 очень плохо поддерживал стандарты. Ещё в нём были очень неприятные баги. Например, если разработчики забывали указать у тега <img> атрибут src, тогда изображение превращалось в некое подобие <iframe> — начиналась загрузка корня сайта. На корневой странице это приводило к бесконечному циклу. В результате либо падал браузер, либо возникал синий экран смерти.

В то время аудитория IE6 составляла 18%, поэтому менеджеры не хотели бросать его поддержку. Но разработчики очень сильно устали от багов в IE6, поэтому тайком от руководства добавили на главную страницу youtube баннер, который говорил о том, что в IE6 сайт скоро будет недоступен и который предлагал установить современные браузеры. Это послужило триггером для других команд в Google поставить подобный баннер. Затем примеру youtube последовали и другие сайты, не связанные с Google. В итоге это привело к очень сильному снижению доли пользователей, использующих IE6, что позволило избавиться от его поддержки.

Зачинщики этой подрывной деятельности готовились к самому худшему. Они думали, что их уволят, но всё обошлось. Ребята из pr-отдела даже пожаловались, что они пропустили такой прекрасный инфоповод.

#ie6 #history #google

http://blog.chriszacharias.com/a-conspiracy-to-kill-ie6
Уже несколько недель лежала в закладках статья про то, как инженеры Google внедрили на страницу поиска сервис воркеры — "Bringing service workers to Google Search".

Сервис воркеры используются для того, чтобы кешировать результаты ответа на запрос в течение небольшого количества времени. Ещё они используются для offline-режима, в котором пользователь может ввести запрос и получить ответ как только появится соединение. Но наиболее интересным мне показался кейс с анализом запросов за бандлами js-кода. Код, работающий в сервис воркере, определяет состав бандла, который должен быть загружен с сервера. После этапа анализа создаётся бандл из локально закешированных модулей. Это позволяет увеличить отзывчивость сайта и уменьшить объём потребляемого трафика у клиента.

В статье есть ещё много информации о том, с каким сложностями столкнулась команда при добавлении сервис воркеров, и как они с ними справились. Статью точно стоит прочитать, если вы думаете о том, как внедрить сервис воркеры в свой проект.

#serviceworker #performance #google

https://web.dev/google-search-sw/
Барри Поллард — автор книги “HTTP/2 in Action” и редактор web-альманаха — написал большую статью про плюсы и минусы использования шрифтов Google Fonts — "Should you self-host Google Fonts?"

При работе над web-альманахом Барри занимался оптимизацией сайта. Большая проблема была с Google Fonts (fonts.googleapis.com). При его использовании блокировался рендеринг страницы; в экспериментах с веб-альманахом задержка была 3 секунды. Для ускорения отображение контента, было решено перенести все шрифты на основной домен. Но не всё так просто. Google Fonts делает много всего полезного, для того чтобы уменьшить объём загружаемых шрифтов, например, отдаёт шрифты без хинтинга для браузеров на macOS, автоматически использует font subsetting и т.п. Поэтому при отказе от Google Fonts нужно понимать, какие потенциальные плюсы будут потеряны.

Статья большая. Очень рекомендую почитать, если используете Google Fonts.

#fonts #performance #google

https://www.tunetheweb.com/blog/should-you-self-host-google-fonts/
Три дня назад команда Google Chrome объявила о том, что собирается заморозить текущий User Agent к сентябрю 2020 года.

User Agent (UA) — хороший источник информации о пользователях, что плохо для приватности. Его заморозка сделает невозможным пассивный сбор данных о пользователях третьими сторонами. Ещё UA-строки запутаны настолько, что нередко становятся источниками проблем совместимости сайтов, из-за чего браузеры вынуждены в некоторых случаях представляться другими браузерами.

UA будет унифицирован и заморожен, чтобы не сломать существующий код, который его использует. В качестве замены UA гуглеры предлагают новую фичу — User Agent Client Hints (UA-CH). Её использование будет гарантировать, что сервер получит только ту информацию, которая ему нужна (платформа, операционная система, браузер и т.п.). Это также уменьшит вероятность ошибок, которые ведут к проблемам с совместимостью. Работать UA-CH будет поверх HTTPS, что вынудит третьи стороны использовать активный сбор данных, который в свою очередь может быть проанализирован и заблокирован браузером. На данный момент не решён вопрос неизбежной задержки ответа при использовании UA-CH, что критично для сервисов, которые должны отвечать быстро, например, fonts.google.com.

Разработчики других браузеров также проявили интерес к заморозке UA: в Safari уже проводятся эксперименты, в Firefox хорошо относятся к инициативе с заморозкой, но пока наблюдают за обстановкой.

#web #security #google

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-2JIRNMWJ7s/yHe4tQNLCgAJ
С 2018 года поиск Google начал использовать для ранжирования сайтов метрики производительности. В этом году для оценки производительности будут добавлены новые метрики. Алексей Махметхажиев рассказал о грядущем обновлении в статье "Новый Google PageSpeed Insights на движке Lighthouse 6 (beta): проверьте, какие показатели будут у вашего сайта".

Будут добавлены TBT (Total Blocking Time) — время в течении которого пользователь не может взаимодействовать с сайтом после его отображения, например, из-за парсинга большого объёма js-кода. LCP (Largest Contentful Paint) — время до отрисовки самого большого фрагмента контента на странице. CLS (Cumulative Layout Shift) — метрика, показывающая насколько сильно происходит сдвиг контента при загрузке сайта.

Очень рекомендую посмотерть статью и проверить метрики производительности ваших сайтов.

#seo #performance #google

https://habr.com/ru/post/493230/
Инженеры из Google пару недель назад представили инициативу, помогающую разработчикам создавать более производительные сайты — "Web Vitals".

Тема производительности веба очень большая. На ней можно построить карьеру, помогая другим с оптимизацией сайтов. Обычно такие специалисты или агентства, предоставляющие подобные услуги, стоят дорого. Для поддержки разработчиков, у которых нет ресурсов для полного погружения в тему производительности, Google представил новую инициативу Web Vitals. Web Vitals — это набор метрик и их показателей, которые помогают выявить проблемы производительности, ухудшающие пользовательский опыт.

Web Vitals включает в себя подмножество Core Web Vitals — набор метрик, на которые разработчики должны обращать внимание в первую очередь. Туда входят:
— Largest Contentful Paint (LCP) говорит о времени загрузки основного контента на странице. LCP считается хорошим, если он происходит в первые 2.5 секунд после начала загрузки.
— First Input Delay (FID) измеряет интерактивность. Для хорошего ux страницы должны обеспечить FID в пределах 100мс.
— Cumulative Layout Shift (CLS) измеряет визуальную стабильность. Для хорошего ux страницы должны обеспечить CLS в пределах 0.1.

В течение ближайших месяцев будут обновлены Lighthouse, Chrome DevTools, PageSpeed Insights, Search Console’s Speed Report, в них будут добавлены функции, помогающие в улучшении Core Web Vitals. Для понимания того, как обстоят дела с метриками сейчас, можно использовать библиотеку web-vitals или Web Vitals Chrome Extension.

#performance #announcement #google

https://web.dev/vitals/
Google объявил о том, что показатели Web Vitals будут влиять на ранжирование сайтов в поиске — "Evaluating page experience for a better web".

Google учитывает сотни сигналов, которые влияют на ранжирование, например, адаптированность страниц под мобильные устройства, поддержку https, удобный доступ к контенту и т.п. К этим сигналам будет добавлен Web Vitals. То есть среди сайтов с примерно одинаковым контентом и сигналами предпочтение будет отдаваться тем, которые работают быстрее. Также будет изменён алгоритм попадания контента новостных сайтов в "Top Stories" — теперь необязательно, чтобы сайт предоставлял AMP-версию страниц, достаточно, чтобы он работал быстро.

Алгоритм ранжирования будет обновлён не ранее 2021 года. За шесть месяцев до обновления будет ещё один анонс. У владельцев сайтов есть много времени, чтобы улучшить показатели Web Vitals.

#seo #performance #google

https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html
Мальте Юбэл из Google рассказал про историю возникновения и развития проекта Accelerated Mobile Pages — "Looking back at five years of AMP".

Проект появился в 2015 году как результат обсуждения с издателями проблем распространения контента. На тот момент большие сайты очень сильно уступали в скорости нативным приложениям. Google представил свое видение для решения этих проблем — проект AMP. Несмотря на очень хорошие показатели вовлечённости рядовых пользователей AMP столкнулся с критикой. При просмотре AMP-страниц url оригинального источника был недоступен, в top-stories выдачи google продвигался только AMP-контент. Для решения первой проблемы были привлечены разработчики браузеров, которые сделали так, чтобы при шаринге AMP-страниц копировался оригинальный URL. Позже была представлена возможность распространения AMP со сторонних доменов. Вторая проблема будет решена благодаря внедрению в поиск сигналов о скорости страниц. Обещают, что хорошо работающие страницы будут попадать в top-stories без проблем.

Интересная статья. В неё стоит заглянуть, если разрабатываете контент-проект или если интересуетесь историей web.

#history #google

https://blog.amp.dev/2020/06/19/looking-back/
Недавно Google обновил планы по переходу на mobile-first поиск — "Prepare for mobile-first indexing (with a little extra time)".

Количество пользователей интернета, использующих смартфоны, давно превысило количество пользователей десктопных платформ. Именно поэтому Google продвигает разные инициативы, улучшающие опыт работы с мобильным вебом. В том числе было запланировано включение mobile-first индексирования с сентября 2020 года, но из-за пандемии дата была перенесена на конец марта 2021 года.

Mobile-first индексирование означает, что поисковик будет использовать мобильные версии страниц для ранжирования. В статье есть рекомендации, что проверить и исправить, чтобы сайт не упал в результатах поисковой выдачи.

#seo #google #announcement

https://webmasters.googleblog.com/2020/07/prepare-for-mobile-first-indexing-with.html
В блоге Google был опубликован апдейт про грядущие изменения в ранжировании результатов поиска — "Timing for bringing page experience to Google Search".

Пару месяцев назад Google объявил о том, что метрики производительности будут учитываться в ранжировании. Сегодня было опубликовано уточнение, что это произойдёт в мае 2021 года. Владельцам сайтов рекомендуется оптимизировать работу сайта с учётом метрик Web Vitals. Сайты с хорошим пользовательским опытом будут выделятся особой пометкой в результатах поиска. Также с мая 2021 года в новостную выдачу будут попадать не только AMP-сайты, но и обычные сайты, которые работают быстро.

В общем, появился очень хороший повод, чтобы заняться оптимизацией производительности.

#google #seo #performance

https://webmasters.googleblog.com/2020/11/timing-for-page-experience.html
Дженс Оливер Маейерт написал небольшой пост о том, почему нужно забыть о AMP (Accelerated Mobile Pages) — "Ignore AMP".

В 2015 году Google предложил использовать AMP — технологию для ускорения доставки страниц. Намерение было благое, но сообщество выступило против этой инициативы с резкой критикой, в первую очередь из-за того, что AMP должен был распространяться с домена Google. По прошествии пяти лет AMP не получил большого распространения, более того Google начал продвигать другую инициативу с похожей целью — Web Vitals.

Дженс пишет о том, что не нужно добавлять в свои проекты поддержку AMP из-за нескольких причин: это нестандартизированная технология, она требует дополнительные ресурсы на поддержку, увеличивая затраты на разработку в несколько раз, она медленно умирает.

Советую заглянуть в статью, если задумывались о внедрении AMP в свой проект.

#google #web

https://meiert.com/en/blog/ignore-amp/
Когда были представлены метрики Web Vitals ребята из Google упомянули, что они будут учитываться при ранжировании результатов поиска. Вчера была опубликована статья, рассказывающая о том, когда это произойдёт — "More time, tools, and details on the page experience update".

Новый фактор ранжирования, учитывающий производительность, будет выкатываться постепенно, начиная с середины июня этого года до конца августа. Google напоминает, что это один из многих факторов, поэтому значительного изменения выдачи ожидать не стоит. Для упрощения поиска проблемных страниц в Google Search Console появятся новые отчёты со статусом страниц, учитывающих их производительность.

Также в этой статье было сделано несколько смежных анонсов. С середины июня сайтам не обязательно распространять свой контент в виде AMP, чтобы попасть в раздел "Top Stories" (новости), учитываться будет только скорость загрузки страниц. Значки AMP-страниц будут удалены из результатов поиска. Signed Exchanges (SXG) можно будет подключить к любым страницам. Благодаря SXG сайты могут делегировать распространение контента другому сайту, сохраняя URL оригинального сайта (поддержка SXG есть только в Chromium).

#performance #seo #google

https://developers.google.com/search/blog/2021/04/more-details-page-experience
Вчера в блоге Google появилась новость о том, что Google Docs переходит на движок рендеринга, работающий поверх canvas, — "Google Docs will now use canvas based rendering: this may impact some Chrome extensions".

После публикации в сети появились обсуждения насколько это оправдано. Своими мыслями поделился один из авторов оригинального Google Docs. Он говорит о том, что HTML-движки хороши для рендеринга обычных сайтов, но им не хватает фич для реализации полноценных WISWYG-редакторов. И о том, что кастомный движок рендеринга выигрывает по скорости у HTML-движков благодаря ограниченному набору функций.

У многих возникли вопросы по поводу доступности. Я немного потестил тестовый документ из статьи, и с доступностью там более менее всё ок. Озвучивание текста включается с помощью хоткея cmd+option+z — появится div с aria-live вне области просмотра с текстом документа текущей страницы. При перемещении по документу озвучивается текущая строка.

Обновление Google Docs будет раскатываться постепенно в течение двух ближайших месяцев. После обновления браузерные расширения, работающие с HTML-разметкой приложения, перестанут работать.

#architecture #announcement #google #a11y

https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
https://news.ycombinator.com/item?id=27129858 (обсуждение на Hacker News)
Прекращение поддержки IE11 в Google Search

Разработчики Google Search сообщили о прекращении поддержки Internet Explorer 11. Прекращение поддержки означает перевод пользователей IE11 в специальную версию поисковика, которая обслуживает неактуальные браузеры. Также в декабре 2020 года была прекращена поддержка IE11 в Gmail и Google Docs.

Если вы до сих пор исправляете ошибки в Internet Explorer, появился хороший повод, чтобы обдумать с вашими менеджерами целесообразность его поддержки.

#announcement #google #ie

https://9to5google.com/2021/10/01/google-search-internet-explorer-11/