Комментарии 39
Похоже, с этой технологией Интернет превратится в аналог телевидения. Для мартышек.
Когда ОНИ уже нажрутся?
Хотя для банков, например, или для государственных порталов такое решение было бы к месту.
Но и только.
А чем банки лучше, чем другие сайты? Вот, например, крупный кипрский банк. Зачем мне ютуб и гугланалитикс при работе с банком?
Я к тому, что в банк-клиентах такая штука тоже не нужна. На картинке выше красное — это список ресурсов, которые пытается подгрузить банк-клиент, и которые я не имею намерения загружать (заблокировано).
Зачем мне ютуб и гугланалитикс при работе с банком?
Эм, так аналитика и не для вас (пользователя), а для разработчиков сайта. Претензии к fonts.googleapis.com у вас нет? Банк же тоже может сам шрифты хостать, а не использовать сторонние сервисы.
Я рад, что аналитка для разработчиков сайта. Почему мой браузер на мои деньги должен обеспечивать их аналитикой? Я, как правомерный пользователь своего ПО не имею желания отправлять что-либо со своего компьютера на домены гугла без явного моего разрешения.
Ваш браузер на ваши деньги? Вы за него заплатили что ли? Не знал, что есть платные браузеры.
И получается вы против сбором разработчиком любой информации, которая поможет сделать сайт лучше? Например собирать информацию о JS ошибках или замерять скорость рендеринга тех или иных участков сайта?
Я пользуюсь браузером на основании свободной лицензии mozilla public license. Я против использования моего оборудования и моего трафика (оплачиваемого мной) для сбора информации, на сбор которой с использованием моих ресурсов я согласия не давал. Согласие даётся посредством opt-in разрешения на определенные типы запросов. Разрешения нет — значит, я своего согласия не давал. Все просто, правда?
А вы давали согласие хабру на хранение вашего комментария? Вы его написали на своей клавиатуре, а хабр хранит и получает деньги за счёт рекламы от пользователей, которые его читают.
Например собирать информацию о JS ошибкахПравильно, зачем брать язык проверяющий на ошибки, когда можно прикрутить гугл-аналитику?
И скрипты внутри тега script и стили внутри тега style и картинки и любые другие ресурсы в виде схемы data.
Только вот этим не спешат пользоваться.
Как минимум для разработки/дебага гораздо удобнее, когда ресурсы разделены по файлам. Я работаю в рекламе и у нас к сожалению до сих пор много inline скриптов, так они не могут кешироваться и дебажить их — одна головная боль.
Как бандлы помогают или препятствуют блокировке рекламы?
Не знаю. Но сравнение с пдф тут некорректно. Баннерная реклама не загружается, как часть самой страницу сайта, а загружается как дополнительные ресурсы, что и позволяет блокировать адблокерам. Одна из главных причин, почему реклама не рендерится сразу со страницей — это то, что это ломает таргетирование. Так что бандлы не приносят ничего существенно нового: server-side рекламу можно сделать и сегодня, но у этого больше минусов, чем плюсов для рекламных компаний.
Проблемы возникнут. Server-side rendering для рекламы обсуждался (и обсуждается) в гугле давно. У него есть плюсы:
- частичный обход адблокеров
- страница будет загружаться быстрее (т.к. не надо рекламный JS на стороне пользователя выполнять)
И минусы
- потеря куков и таргетирования
- сложность интеграции для владельцев сайтов (считай со всем зоопарком фреймворков и языков надо интегрироваться)
- отсутствие гарантии того, что реклама не будет изменена во время рендеринга
И минусы перевешивают. Я не вижу как бандлы решают какие-то из этих минусов. Может только последний, если бандлы будут подписываться ключом каким, который браузер будет проверять потом.
Не бандлы, а server-side rendering. Реклама в гугле запрашивается с доменов doubleclick.net и на нём рекламные куки пользователя сидят. Если мы перейдём на server-side то невозможно эти куки передать.
Как возможно передать? Пользователь открывает mysite.com, запрос ушёл на mysite.com сервер. Этому серверу нужно сделать запрос к серверам гугла, чтобы получить рекламу. Как при этом можно передать doubleclick.net куку в запросе?
Самый банальный вариант матчинга — сгенерировать для посетителя id, привязанный к сайту (сохранить в локальных куках или даже привязать к логину) и один раз загрузить картинку с домена doubleclick.net передав в url этот свой id посетителя.
И дальше при server-server запросах, передавать этот свой id посетителя, а doubleclick.net будет понимать, что это за пользователь.
Есть и менее тривиальные варианты.
Кроме того, крупный сайт может хостить счетчики на своем домене (например, facebook) и ему вообще в этом случае не нужен будет матчинг на этапе показа рекламы.
Это для рекламной сети такая технология будет не подходящей (встраивать не удобно), а для крупного сайта, самостоятельно откручивающего рекламу, проблем нет.
Что сломается, так это интеграция со сторонними рекламными системами — ее будет реализовывать сложно (либо это будут сторонние скрипты/фреймы внутри блока от самого сайта, что сделает геморрой с серверным рендерингом лишенным смысла). Но не всем сайтам это нужно.
В первом случае можно блокировать, например, хосты с рекламой.
Во втором случае можно будет «лОжить» такие сайты в качестве протеста(ха), ведь наверняка компоновка будет кушать процессорное время.
Скорее всего оно будет компоноваться заранее, на этапе сборки сайта, а вам будет приходить уже готовый запакованный архив (что-то вроде MHTML, только хуже). Повлиять на содержимое пакета у вас не будет возможности — скорее всего он будет подписываться или какое-нибудь DRM в него воткнут.
Чем принципиально отличаются сценарии
- "для каждого пользователя генерировать свой уникальный бандл с переименованными ассетами"
- "генерировать свой уникальный мегажирный html с проинлайненными туда ассетами"
- "генерировать уникальное зеркало сайта под каждую сессию, с переименованием урлов ассетов "
Только то, что первые два сценария — это fire-n-forget, а для второго нужно немножко магии в трансляторе урлов?
И что мешает злому серверу отдавать криптомайнер под видом jquery или ещё какой-нибудь либы? Да он тупо склеит либу с вредоносной добавкой, вот и всё.
Как Web Bundles навредят блокировщикам контента, инструментам для безопасности и открытому вебу