⬆️⬆️⬆️ начало поста

❗️ При выборе CDN обязательно проверяйте регионы присутствия, если вы подключите CloudFlare или любой другой иностранный сервис к сайту, у которого посетители только из одной страны, то прироста за счет сети не будет, так как в каждой стране присутствует максимум 1-2 сервера, и разницы будет не видно. Если конечно вы не планируете использовать автоматическую оптимизацию от сервиса. Про это поговорим в отдельном посте. Выбирайте CDN с максимальным присутствие в вашей стране, чтобы было покрыто максимальное число городов и регионов, где находятся ваши клиенты. Если информации о покрытии нет на сайте, то ее следует запросить перед покупкой.

Основные ошибки при подключении CDN - использовать отдельный домен для статики. Я почти в каждом посте повторяю, что установка соединения - самая ресурсоемкая операция, поэтому проксировать нужно весь домен. Если не выполнить это правило, то сайт может не просто не ускориться, а даже замедлиться.

У всех CDN есть правила настройки кэширования, тогда вы сможете управлять какой контент стоит кэшировать и на сколько. Управлять кэшем CDN проще всего через HTTP-заголовки, которые передает ваш сервер и указывать для динамики запрет кэширования, а для статики полный кэш навсегда. Если есть возможность настройки в самом кабинете CDN, то смотрите, какие оптимизации делает CDN, и для начала не включайте никакие - замерьте скорость. Возможно, внутренние оптимизации CDN помогут еще ускорить ваш сайт и отказаться от рутины в ускорении.

Например сервис W.tools (внимание, реф-ссылка) может выполнять базовые оптимизации, сжимать изображения, конвертировать в webp, использовать 0-RTT и другие современные фишки, которые можно настроить на стороне сервера.

⚠️ Не стоит сразу бежать и платить, именно за этот или любой другой сервис вам он может не подойти, обязательно все взвешивайте и просчитывайте, и кроме этого общайтесь с поддержкой. У многих сервисов есть тестовый период, если нет, то никто не мешает спросить в поддержке, многие сервисы очень часто идут на встречу.

💬 Был ли у вас опыт использования CDN? Расскажите, какой сервис используете, и каких результатов добились?

update: Снова какая-то проблема с комментариями. Можете писать и задавать вопросы в предыдущем посте.

❗️ На прошлой неделе делал технический аудит сайту, который очень долго загружался. Знаете в чем оказалась причина? В пикселе ретарегета, заблокированного на территории РФ. Просто убрали подключение сервиса, которым кстати никто не пользовался сразу после блокировки, но с сайта конечно не убрали.

Проблема оказалась в том, что на сайта стояла заглушка при загрузке (про них, кстати, будет отдельный пост - то еще зло для производительности), которая пропадала на событие load у window. Никогда так не делайте. Особенно, если подключается сторонний синхронный код, работоспособность которого вы не можете гарантировать.

Некоторые провайдеры не режут соединение и событие error не срабатывает, а ресурсы с заблокированных доменов грузятся бесконечно, пока не сработает timeout в браузере. Здесь мы также бессильны, если только не писать свой worker для того, чтобы разрывать соединение, или возвращать заглушку, если загрузка не произошла за первые секунды.

Проверьте прямо сейчас консоль вашего сайта, возможно там куча ошибок о безопасном соединении, которые возникают, если провайдер просто рвет соединение с заблокированным хостом. Если есть - задумайтесь нужны ли вам эти сервисы и если нужны, подключайте их в зависимости от географии пользователя.

⚠️ Еще одна причина проверить сторонний код - это сторонние сервисы, которыми вы не пользуетесь, и которые могут быть заброшенными, а как следствие после истечения домена злоумышленник может перекупить его и загрузить на ваш сайт по старой ссылке вредоносный код. Поверьте, это происходит регулярно.

💬 А вы убираете код с сайта после блокировки его домена в вашей стране?

❗️ В прошлом посте я обещал рассказать, почему не стоит использовать заглушки до события onload. Все просто, первая отрисовка будет быстрее, а вот LCP-элемент появится гораздо медленнее.

Допустим, LCP-элементом является картинка на первом экране, и кроме нее грузятся еще и javascript файлы, и другие изображения и шрифты. LCP-элемент по факту грузится под такой заглушкой, и даже если он загрузится быстро, то пользователь его не увидит до момента, пока заглушка не исчезнет. Хуже может быть только если скрытие этой заглушки происходит с анимацией, допустим 500 миллисекунд. Таким образом, вы отложите появление LCP-элемента еще и на время анимации.

Чаще всего за такой заглушкой скрывают подгрузку стилей или SPA-приложения, но нужно не скрывать, а работать над визуальной стабильностью, лучше выделить critical-css, чтобы картинка не прыгала во время подгрузки, и необходимость в заглушке отпадет.

Но как же быть в SPA-приложении? Там вместо стандартной заглушки с крутилкой и надписью "подождите", лучше использовать skeleton loader, когда заглушка имитирует контент, который появится на странице уже после окончательной подгрузки. Проблему #LCP это не решит, но решит проблему смещения.

⚠️ Правила:
1. Никогда не используйте заглушку контента.
2. Не используйте анимацию, если решили, что первое правило не для вас.
3. Никогда не нарушайте первое правило.

💬 А вы используете заглушки при загрузке?

❗️ Сегодня я расскажу в чем проблема библиотек слайдеров на javascript. В целом я не против слайдеров и каруселей - их можно сделать так, чтобы они минимально влияли на быстродействие сайта. Однако готовые библиотеки, например slick и owl, сильно влияют на #LCP, #CLS и #TBT. Сегодня я расскажу в чем основная ошибка этих библиотек, и как избежать этих ошибок, разрабатывая свое решение.

1. Стилизация слайдера происходит через классы, которые добавляются только при инициализации. В связи с этим до инициализации страница выглядит совсем по другому, или часть элементов вообще скрыта, зависит от библиотеки и настроек. Это влияет на LCP, если слайдер скрыт, и на CLS, если не заданы размеры. Слайдер изначально развернут, и потом схлопывается до конечных размеров.

2. Слайдер при инициализации вносит изменения в DOM, добавляя классы и элементы, меняя родительские и дочерние элементы. Происходит буквально переверстка страницы, а как следствие ее перерисовка. Это влияет в первую очередь на TBT.

3. При карусели с бесконечной прокруткой, слайдер добавляет клоны предыдущих и следующих элементов, чтобы обеспечить анимацию. Это вызывает лишние перерисовки и раздувает DOM, если внутри содержится сложная верстка.

⚠️ Как сделать свой слайдер без всех этих ошибок? Используйте CSS. Делайте так, чтобы даже с выключенным JS слайдер можно было скроллить при помощи встроенного скролла и свойства scroll-snap-type. Все элементы слайдера формируйте в верстке или на backend, и в js прописывайте только взаимодействие. Например, клики по стрелкам или точкам под слайдером. JS не должен менять структуру DOM без явного взаимодействия с пользователем. Только после клика или свайпа можно добавлять класс, или следующий элемент для плавных анимаций. Внешний вид слайдера не должен отличаться при выключении JS.

Когда-нибудь я напишу пример на чистом JS, чтобы поделиться с вами.

💬 Пишите коммент, и ставьте лайк, если нужен пример хорошего слайдера, или присылайте свое решение.

🎉 Друзья, спасибо вам, нас уже больше 2000 человек, кто интересуется темой производительности сайтов и web-приложений. Всего полтора месяца назад я открыл этот канал для публичного доступа, и вот нас уже больше двух тысяч. Но это только начало, впереди куча идей и постов, которые будут также полезны, или даже полезнее, чем то, что уже опубликовано.

📹 Хочу сделать видео-разбор ваших проектов в прямом эфире, вы бы отправили свой проект на разбор? Или NDA, все дела?

💬 И очень хочу обратной связи по темам постов, про что вы хотите публикации, а может быть и целую новую рубрику?

❗️ Все, кто столкнулся с проблемой производительности и начал ее изучать рано или поздно сталкивается с тем, что число прослушивателей событий влияет на быстродействие всего приложения, особенно это касается scroll. Браузер и так его оптимизирует, не отрисовывая контент за пределами экрана, поэтому дополнительные операции и вычисления на это событие очень заметны на медленных устройствах. Все наверное сталкивались, когда скроллишь контент, а там белый экран и спустя время, которое может доходить до 3-5 секунд контент отрисовывается.

В контентных проектах последнее время очень распространен индикатор скролла, чтобы пользователь визуально мог видеть сколько прочитано и сколько осталось прочитать, чтобы оценить свое время. Очень удобно. Но для того, чтобы сделать такой индикатор обычно используют javascript и каждое событие scroll производятся вычисления положения и некоторые математические операции.

Сегодня я предлагаю #nojs способ для реализации подобного функционала. Способ придумал не я, а нашел у пользователя chokcoco. Я адаптировал, протестировал быстродействие и могу 100% рекомендовать данное решение для приложений, так как все вычисления делает браузер, перерисовки не происходит, все работает на нативном свойстве background.

✅ Ссылка на Codepen

💬 Пишите свое мнение по поводу этого решения. И накидайте реакций для поднятия настроения ☺️

❗️ Немного философии. Знаете ли вы, что весь интернет в среднем ускорится, если со всех сайтов убрать поддержку старых браузеров?

Если отказаться от такой поддежки, то объемы кода сократятся, стандарты начнут развиваться быстрее, вся сфера станет лучше. Даже сборку c ES6 на ES5 можно не делать, так как современные браузеры вполне это поддерживают. Очевидно, что поддерживать браузеры в рамках 2-3 лет нужно, но не более. До сих пор люди заботятся о поддержке интернет эксплорера, хотя даже сам Miсrosoft открестился от него.

Отправка устаревшего кода в браузер означает, что эффективную операцию, которую может выполнить современный браузер, и под выполнение которой он оптимизирован на уровне ядра, переписывают старым кодом, что чаще всего увеличивает сложность алгоритмов. Кроме того, что кода становится гораздо больше, он становится менее эффективным, не всегда, но чаще всего это именно так.

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

⚠️ Если вас просят поддерживать сильно старые браузеры, лучше убедить клиента не делать этого, указав на стоимость, и возможности современных браузеров. Максимум можно поставить заглушку со ссылкой на современные версии браузеров. Заказчик может часто ссылаться на то, что в статистике много пользователей с IE11, но чаще всего это оказываются просто боты, которые так представляются.

💬 Напишите свои истории про поддержку старых браузеров, и накидайте реакций, если согласны с тезисом поста.

❗️ Как думаете, какой пейджспид будет у сайта, если его показатель #ttfb равен 5 секунд? Сегодня мы постараемся ответить и экспериментально подтвердить, какое влияние на общий PageSpeed Score оказывает время ответа сервера.

Для начала есть сайт fe-nix.ru который имеет зеленую зону в PageSpeed. Это статика, сделанная 10 лет назад, поэтому с ответом сервера все в порядке. Вот замеры этой страницы. Теперь сделаем полную копию этой страницы, но отроем его через php, с задержкой в 5 секунд. По адресу fe-nix.ru/delay/5/ находится версия этого сайта с задержкой ответа сервера. Вот замеры этой страницы. Как видите, разница небольшая, и отличаются два замера только значением показателя #SpeedIndex, который отличается примерно на время задержки в ответе сервера + погрешность замера.

Теперь переходим в калькулятор значения PageSpeed, и смотрим какое влияние оказывает показатель Speed Index на общую оценку - видим всего лишь 10%. Значит если у нас будет максимальный ответ сервера, мы потеряем всего 10 баллов, но пользоваться сайтом при этом будет почти невозможно. Попробуйте походить по ссылкам.

Специалисты, которые занимаются ускорением сайтов, на ttfb обращают очень мало внимания, из-за небольшого веса этого показателя в оценке PageSpeed. Попробуйте походить по медленному сайту, и скажите, комфортно ли вам пользоваться таким сайтов? Мне - нет, поэтому над ttfb нужно также работать, как и над фронтендом.

💬 А вы обращаете внимание на показатель ttfb? Дайте огня, если считаете, что ttfb важен.

❗️ Сегодня короткий пост, но достаточно важный в теме быстродействия. Если ваш сайт не работает без JS, значит его точно можно сделать быстрее: как минимум улучшить #INP и #TBT. Помните, когда я писал про слайдеры я советовал проверять работу сайта без JS. Так вот, это касается всего сайта.

Частая ошибка - это переназначение стандартных элементов. Когда кнопка выполняет функции ссылки, а ссылка кнопки, или обычный div работает как кнопка, или ссылка. JavaScript позволяет это делать с любым элементом: отменить стандартное поведение при помощи preventDefault, и назначить свое. Не все понимают, в чем проблема, пока не отключат JavaScript и не попробуют выполнить какое-то действие на сайте.

⚠️ Я не призываю отказываться от JavaScript на сайте, просто не нужно менять поведение стандартных элементов, если у них есть аналоги. Если хотите перейти на другую страницу, не нужно писать свою реализацию перехода по ссылка на javascript, хотя это и выглядит элементарно. Если нужна ссылка - используйте ссылку. Если нужно отправить данные при клике на кнопку - не нужно писать огромный обработчик, это можно сделать на обычной форме с минимальным написанием кода на JS. Если проектируете свои компоненты, поддержки которых в браузере нет, то сделайте это на наиболее подходящих элементах.

💬 Я знаю, есть примеры, когда без переопределения не обойтись, можете написать о таких в комментарии. Но в большинстве случаев, стоит использовать элементы по прямому назначению.

❗️ Очень часто поступают вопросы про jQuery - можно ли использовать, и как эта библиотека влияет на скорость. Действительно, если вопрос производительности стоит остро, то нужно максимально оптимизировать все, что можно на сайте, в том числе понять, как влияет jQuery, и нужен ли он вообще. Давайте для начала поищем тесты быстродействия jQuery в сравнении с обычным JS.

В 2013 году на хабре вышла статья со сравнением производительности JS-библиотек. По всем результатам jQuery оказался самым медленным. Но это уже старая статья, с того времени вышла куча обновлений. Можно провести тестирование прямо в своем браузере. Переходим по ссылке, нажимаем RUN и ждем результат. Native JS окажется всегда быстрее, и в некоторых случаях разница доходит до 1000 процентов.

Еще одним аргументом в пользу jQuery может стать простота написания кода на нем, но это уже далеко не так. Если не поддерживать старые браузеры, как я советовал ранее, то получится совсем немного больше кода, чем на jQuery, однако если учитывать 89кб - вес самой библиотеки, то разница всегда будет в пользу чистого JS.

⚠️ Если стоит выбор подключать ли jQuery, чтобы сделать ajax запрос, или выполнить простые операции с DOM, то ответом должен быть НЕТ, так как обычный fetch может заменить его даже с бОльшим комфортом, а операции с DOM c появлением querySelector стали много проще, чем раньше.

💬 А вы используете jQuery в своих проектах?

❗️ Все знают, или по крайней мере слышали, что такое mobile-first верстка, и что нужно начинать верстку именно с мобильной версии. А вот на вопрос "Почему" так ответить могут далеко не все. На самом деле это влияет и на быстродействие сайта, как вы уже догадались, иначе я бы про это не писал )

Давайте разберемся, как браузер обрабатывает CSS-код. Сначала происходит парсинг всех свойств, а потом применяет их по порядку соблюдая приоритеты к элементам DOM. Если мы используем не mobile first верстку, то сначала будут применены стили из десктопа ко всем элементам, и затем эти стили будут переопределены мобильными стилями из media запросов. На десктопе будет меньше действий для стилизации, чем на мобильном устройстве, хотя по скорости эти устройства с точностью наоборот Десктоп почти всегда быстрее мобильного устройства.

В мобильной верстке все наоборот, сначала применяются стили для мобильной версии, а для десктопной версии стили уже не применятся, так как не проходят по условию. Значит меньше перерисовки и меньше затрат времени на это. А значит более быстрое приложение.

Кстати, не все знают, что можно даже не грузить стили для десктопа на мобильной версии, просто указав media запрос в свойстве media у тега <link>

<link rel="stylesheet" href="desktop.css" media="screen and (min-width: 980px)">

Если укажете такой код, то этот файл стилей не будет загружен, пока media-запрос не станет истинным, тоесть при ширине окна менее 980 пикселей файл не будет загружен.

⚠️ Современный тренд уже заставляет даже дизайнеров делать mobile first дизайн - так легче верстать и продумывать интерфейс так, чтобы не было ничего лишнего, и интерфейс было легко верстать и пользоваться им.

💬 Я надеюсь, что вы используете только mobile first верстку и не знаете как верстать иначе? - пишите в комменты.

👍 Ставьте лайк, если верстаете, начиная с мобильной версии, посмотрим, сколько нас )

❗️ Вчера мы говорили про mobile first верстку, и я рассказывал, что переопределения десктопных стилей мобильными - это плохо для быстродействия. Сегодня я расскажу про переопределение стилей вообще, не только в мобильной версии.

Частая ситуация, когда на проекте подключается стили от bootstrap, затем контент стилизуется и меняется так как задумал дизайнер темы, и после этого еще одни стили перебивают какой-то или дочерней темой или внесением правок в существующую. Итого некоторые элементы могут иметь очень много переопределений.

Совсем недавно я работал с проектом, где стили занимали 4 мб, и при этом неиспользумых почти небыло! У каждого DOM элемента было по несколько десятков переопределений. Представьте объем вычислений для перерисовки, которые выполняет браузер, при добавлении класса к такому элементу.

Чем больше объем стилей и чем больше элементов в DOM, тем дольше происходит первичная отрисовка и каждая перерисовка, которая может инициализироваться при любой манипуляции с DOM. Но при этом переопределение - это не баг а фишка, которая позволяет писать меньше кода.

⚠️ Лучшим выходом является не использовать готовую сетку, типа бутстрап, если будут переписаны свойства у большинства селекторов. Используйте свою сетку в таком случае. При верстке используйте стандарт БЭМ, благодаря нему можно выполнять минимальное число переопределений. Можно сверстать даже так, чтобы модификаторы не выполняли ни одного переопределения. Вычищайте стили, у элементов, если вы видите слишком много переопределений. Можно даже в тестах написать проверку для таких ситуаций.

Я один раз задался целью сверстать страницу без единого переопределения, это возможно, но при этом появляется дублирование кода, что также не очень хорошо, поэтому во всем нужно искать баланс. Не все переопределения - это зло, но если их у элемента больше 5, то это точно повод переверстать этот участок кода.

💬 А вы проверяете верстку на количество переопредлений - напишите об этом

👍 Ставьте лайк, если после прочтения проверили свой последний проект )

❗️ Для того, чтобы сделать пометку в браузере пользователя, например о том, что он согласился с тем, что на сайте используются Cookie часто ставят cookie. Странно, не правда ли? Сегодня расскажу почему это плохо, и чем лучше заменить.

Начнем с того, что каждая кука отправляется на сервер с каждым запросом. В нашем примере пусть это будет "cookies-popup-close=1; " и в каждый запрос на сервер, даже при загрузке картинки будет отправлена эта самая кука. Казалось бы, всего 22 символа, но при 50 запросах на странице это уже 1 килобайт информации, если глубина просмотра сайта в среднем 3 страницы на посетителя и суточной посещаемости в 5000 человек это уже 16 мб ненужной информации которую получил сервер и обработал. А если посещаемость больше? А если кука не одна? Посчитайте сами, сколько лишней информации обрабатывает ваш сервер ежемесячно.

Для очень грубых посчетов можно использовать такую формулу:

document.cookie.length * performance.getEntries().filter(e => e?.name.indexOf('http') === 0 && location.host === new URL(e?.name).host).length

Выполните этот код в консоли браузера на своем сайте прямо сейчас. На сайте одного из клиентов вышло примерно 170 кб cookies на каждую страницу. Это конечно приблизительно, данные сжимаются, и часть этих данных нужна, но 99% случаев это лишняя информация которая передается с каждым запросом.

Раньше выносили статику на отдельный поддомен, куки на него не распространялись и не передавались, но это +1 соединение, а как мы помним соединение самая ресурсоёмкая операция.

⚠️ Как предлагаю делать я: используйте localStorage для данных, которые устанавливаются и считываются только в JS. Если данные используются на backend, то тогда запрещайте к ним доступ из JS. Еще увеличите безопасность.

localStorage.setItem('cookies-close','1');
localStorage.getItem('cookies-close');

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

💬 А как вы относитесь к Cookies? Используете localStorage?

👍 Лайк, если было полезно

Привет, сегодня покажу пример бесконечной бегущей строки на чистом css без использования JS. Совсем недавно анализировал сайт, где было две бегущих строки в разные стороны с логотипами партнеров и сделана она была на JS при помощи GSAP - это достаточно мощная библиотека, и позволяет делать сложные анимации просто и быстро, но как мы с вами знаем, ничто не сравнится по скорости с нативным функционалом браузера. Поэтому я покажу реализацию этого функционала вообще без использования JS. Но в отличии от сайта, где я увидел логотипы, здесь они будут останавливаются при наведении.

✅ Ссылка на codepen

💬 Пишите, используете ли вы подобные элементы на сайте.

👍 Лайк, если полезно. 🔥 Огонь если хотите больше постов с примерами кода.

❗️ В 101 версии Google Chrome появилась новая возможность управлять приоритетами, причем более понятная, чем раньше. Представьте, что у любого загружаемого ресурса: картинки, стилей скриптов, или даже iframe, можно указать приоритет загрузки и тем самым более гибко управлять всем процессом загрузки. Даже в preload можно управлять пориоритетами. Интересно?

Имя этому свойству fetchpriority. Пока поддержка крайне мала, и надеяться только на него нельзя, но это уже большой шаг в сторону нативного управления приоритетами. Для того, чтобы использовать его, просто добавляете у нужного html-элемента fetchpriority="low|high|auto" и загрузка ресурсов будет выстроена исходя из этих приоритетов. Поддерка пока небольшая, ждем обновления браузеров у пользователей.

<img src="photo.avif" fetchpriority="low" alt="не очень важная картинка">
<img src="lcp-element.avif" fetchpriority="high" alt="картинка, которая является LCP-элементом">

В этом случае первой будет загружена картинка, которая является LCP-элементом.

⚠️ Самое главное - не ставить всем ресурсам маскимальный приоритет, это не ускорит загрузку.

💬 Пишите в комменты, слышали вы про этот способ управления приоритетом раньше, и будете ли использовать его в своем проекте?

👍 Лайк, если было полезно.

👋 Всем привет!

Телеграм бот прислал статистику канала, и мне стало так стыдно, что ничего не писал последние месяцы. Спасибо, что верили в меня и канал, спасибо что не отписались. Вы крутые, а я не могу выкроить полчаса на пост. Но это все конечно опрадания. Скорее это какой-то страх исписаться. И привет, моему синдрому самозванца.

🙈 Минус 500 человек, но огромное спасибо всем, кто остался. Обещаю уже в январе выпустить два бомбезных поста.

🎄 Ну и по традиции: год был сложный, будет еще сложнее, не разбегайтесь далеко.

🎉 С Наступающим 2023 годом! Берегите себя!

⚡️ Сегодня ночью Lighthouse был обновлен до 10 версии.

‼️ Важные изменения:

1. Time To Interactive (TTI) больше не учитывается при общей оценке производительности. В восьмой версии его влияние уже было снижено до 10%, а теперь он и вовсе не участвует в формировании оценки. Показатель все равно рассчитывается и можно его получить в json отчете.

2. Влияние Cumulative Layout Shift (CLS) усилено c 15% до 25%. Именно он получил те самые 10% от TTI.

3. Добавлен новый аудит bfcache, это проверка как браузер обрабатывает навигацию вперед/назад, такие страницы должны быть показаны моментально. Но этот аудит не будет отображаться в Google PageSpeed Insights. Доступ к нему можно получить через JSON.

Также был переработан механизм сборки, изменены названия аудитов в JSON, некоторые аудиты вообще удалены. Подробнее можно ознакомиться на Github проекта и в нашем любимом калькуляторе общей оценки.

⚠️ Из идентификации User-Agent убрали "Chrome-Lighthouse", теперь не получится по этому параметру скрывать часть контента или отдавать облегченную версию.

💬 Давайте обсудим в комментариях.
Что вы думаете о текущих изменениях?
Обращали ли вы последнее время внимание на TTI?
Не считаете ли завышенным влияние CLS?

🔥 Дайте огня за оперативность.

⚡️ Хорошая новость для всех, кто заботится о скорости работы своего сайта, и для всех, кто не может отказаться от счетчика Яндекс-Метрики, но проблемы с производительностью возникают именно в нем. Код подключаемого бандла теперь opensource.

Что это значит? По ссылке доступен исходных код и правила для сборки кода бандла Яндекс-Метрики. Даже просто отключив поддержку очень старых браузеров и разместив его у себя, мы получим улучшение быстродействия. Дерзайте, я тоже проведу эксперименты со своей стороны.

Подробнее в статье на хабре, там описано как работает код, что можно менять, и как отключить ненужные функции.

⚠️ Обратите внимание, запросы отправляются к яндексу, поэтому еще одно соединение никуда не денется. Чтобы от него избавиться на клиенте, рекомендую использовать проксирование, о котором я писал ранее.

💬 Что думаете по этому поводу? Будете ли использовать собсвтенную сборку или останетесь на стандартном бандле, подключаемом с серверов Яндекса?

👍 Палец вверх, если вы уже подключаете свою версию метрики в основной бандл.

👋 Многие из вас просили меня сделать слайдер, который не будет менять DOM и вызывать перерисовку при инициализации. Я и сам давно обещал вам такой слайдер, очень давно, даже стыдно, но все никак не мог добраться до него. Поэтому я решил попросить помощи у (внезапно) Bing, который работает на GPT-4, и… получилось нечто невероятное!

Благодаря множеству уточнений и итераций, Bing написал за меня почти весь код, который работает как мне хотелось и выглядит вполне прилично. Это не готовая библиотека, конечно, но для одного слайдера на странице вполне подходит, и его можно адаптировать под свои нужды. Я намеренно не стал приводить стилистику кода к единому формату, чтобы можно было видеть еще и результат работы нейросети.

Я лишь немного подправил оформление точек под слайдером, общий layout, прописал url для картинок и добавил заголовок и футер. Все остальное - заслуга нейросети. Я уже пробовал ранее использовать Bing и ChatGPT для написания кода, но такого успеха еще не было. Я потратил 10 минут, писал только запросы с телефона, при этом сам не писал код, а говорил что и как улучшить. Почти как в повседневной жизни, где я консультирую команды и даю рекомендации по улучшению быстродействия сайтов.

В итоге мы имеем слайдер, который полностью соответствует моим требованиям, не меняет DOM и не вызывает перерисовку при инициализации, и даже частично работает без JS. Это ли не чудо? )

✅ Ссылка на код слайдера.

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

🔥 Зажгите огонь для Bing, или 👍 палец вверх за мои запросы и уточнения )
💬 Напишите в комментариях, что вы думаете об этом слайдере и о Bing конечно же.