Комментарии 92

Оказывается чего только не придумают. А я то думал что в обучении SCORM формат (зазипованный сайт открывающийся в айфрейме) это дно. А тут вон ещё сильнее закрутили.

Google решил убить Cloudflare?)

Но на самом деле мне кажется, что это задачка нереальная, потому что отвалится вся система кеширования (картинок, js, css). Такой рост объема данных «интернет» просто не переварит.

Если я заблуждаюсь — поправьте меня пожалуйста.

Кэширование не отвалится, потому что обращение к ресурсу в бандле выполняется на более низком уровне, подменяя запрос по сети.


Но Гугл активно пропихивает AMP и тут бандлы ему очень пригодятся. А в дальней переспективе, вполне возможно, планирует вырастить из AMP конкурента Cloudflare.

WebBundles на сколько я понял загружает весь сайт целиком за раз как один файл. AMP же вроде наоборот откладывает загрузку ресурсов страницы(изображений например) до момента когда они понадобятся.

Ну, если запрос полетит уже из самого бандла — все вроде становится на свои места. То есть можно будет уменьшить его размер оставив статику на cdn, а потом с AMP по мере надобности дотягивать непрозрачно для пользователя.
Да, CDN это не убьет, но переконфигурить все придется основательно. Плюс часть функций вроде файрволла станут бесполезны, наверное. Ведь пользователь уже не сможет рандомно обшаривать локации на сайте.
А будет ли рост? Для получения твита в 100 символов надо загрузить несколько мегабайт мусора с сайта. Если отдавать это просто картинкой, то трафик даже снизится. Посмотрите на ту же opera mobile — она примерно так и работает.
Конечно будет.

Сейчас cloudflare и браузер можешь закешировать вот такие запросы:
dr.habracdn.net/habr-web/js/chunk-vendors.c83286b7.js

Сервер Хабра отдает один раз.
Сервер CDN кеширует статику.
Браузер скачивает этот js chunk 1 раз.

Следующая версия будет скачиваться, когда выкатится новое обновление этой страницы. Ну допустим раз в день. Если я зашел и прочитал 5 статей, то я скачал один раз, а не 5.

А еще сервер хабра отдал 1 раз, CDN закешировал и отдал пользователям 1 млн раз.
А если пихать это все в архив, то пользователи скачают 3-5 млн раз этот JS chunk.
И этот объем придется отдавать серверу.

Поэтому я не очень понимаю, как вообще это все можно провернуть.
Тысячи и миллионы сайтов рассчитаны на то, чтобы кешировать статику и делают это на разных уровнях: сервер, nginx, CDN, браузер, etc.

Как отказаться от этого кеширования в вебе — я не понимаю.
Я только что проверил на этой странице:

При повторной загрузке страницы загружает
116kB из 6.9MB
Это 1,5%

Для новой статьи (которую я еще не читал) загрузилось со всеми картинками 800kB из 6.8MB
Это 11%

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

Ну и возвращаясь к опере мобайл, она показывала снижение трафика в несколько раз даже при посещении одного и того же сайта.
НЛО прилетело и опубликовало эту надпись здесь
Не мог, для chm отдельная смотрелка была, да и назначение у формата иное (хотя при желании можно было хоть сайт целиком запихнуть).
Очень даже мог, и не только сhm, но и новый формат справки (забыл используемые там расширения). Вбиваете адрес «mk:@MSITStore:<путь к файлу chm>::<путь к html внутри chm>» и вперёд. А по протоколу res он и в PE-файлах мог контент смотреть: «res://<путь к exe/dll/whatever>/<путь к html внутри файла>».
Так, кажется, не мог. Но другие браузеры-то и на локале так не могут

У меня в библиотеке хранится учебник по Эсперанто в .chm формате. Это удобно исключительно для offline-просмотра. В живом интернете я бы эту мерзозть видеть не хотел

НЛО прилетело и опубликовало эту надпись здесь
на *.chm электронные книжки верстали с навигацией и картинками) удобно было на компе читать… эх…

Теперь то же самое можно сделать с EPUB 3, даже видео внедрить можно. Но найти подходящую читалку для файлов EPUB 3, способную отображать все возможности формата – на некоторых ОС, вроде Linux и Android, весьма затруднительно. У Apple и под Windows читалки нужные есть, под свободные ОС найти полнофункциональную читалку не реально. А Web Bunles — это выход, можно книжки паковать в файлы. К примеру, книжки собранные с помощью mkdocs...

Еще хуже то, что этому движку сейчас нет внятных альтернатив, потому что даже Microsoft уже как два года «пристрелили и закопали» свою стюардессу EdgeHTML, перейдя на Chromium.

Резво автор похоронил Mozilla с их Gecko.
Вроде у мазилы основной донатер как раз гугль. Поэтому, видать, у них сейчас сокращение штата и вообще туманное будущее (тут были статьи на эту тему около месяца назад вроде).
У них свободный код, так что даже полная остановка Mozilla не помешает легально пересобирать и патчить его отдельным энузиастам и компаниям, в отличии от presto
Веб развивается, сложно будет поддерживать новые стандарты энтузиастам, чтобы хотя бы выглядело все приемлемо. Для этого нужен постоянный штат разрабов
В случае presto, насколько мне известно, проблематично даже открыть сайт из-за новых алгоритмов шифрования, не говоря уже о правильности вёрстки.
И будет зоопарк сборок, типа ЗверьДВД. Где-то будет работать нужное расширение или встроенная фича, а где-то нет. И держи на компе стопицот разных вариантов разных сборок под разные задачи…
Зверь — сборка собственнической программы, выполненная людьми с неопределённой компетентностью. В случае свободного кода, никто не мешает применить сразу несколько патчей и собрать программу со всеми. Подобный подход весьма распространён, например aur.archlinux.org/packages/ungoogled-chromium-ozone это chromium(основа) с несколькими патчами, а именно ungoogled для избавления привязки к гуглу, ozone — для работы под wayland, vaapi — для аппаратного декодирования видео и так далее.
Стоп-стоп. Я сейчас с точки зрения юзера говорю, а не прогера (а я и правда не прогер). И как мне во всём этом зоопарке разбираться?
С точки зрения пользователя вы приходите на форум или куда-то ещё либо с вопросом(при просмотре видео загружен процессор) либо просто читаете рекомендации. Возможно вам дадут описание, что какое слово означает, либо просто скажут — ставьте вот это. После этого, вы с помощью одной команды, либо через графический установщик ставите то что вам нужно.

В то же время, есть отдельные люди, какие пишут патчи, и отдельные люди, какие собирают программы, хотя иногда это одни и те же люди. Они сами между собой будут решать, что и как сделать, вам же погружаться в их работу, для того чтобы понять что они делают не обязательно.
К сожалению, они и сами с похоронами успешно справляются.
Ну и по большому счету, 2-3% у всех лисоподобных — это на уровне статистической погрешности

Ну есть ещё поисковики, которые даже контент, генерируемый JS, толком не умеют индексировать. А тут нате вам ещё один новый стандарт.

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

Так а в чем ускорение? Http2 и так сделал бесполезным бандлирование и огромные картинки, которые надо разрезать на клиенте

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

Примерно в этом же концепте шел, например, cloudflare — он перешифровывает весь трафик, добираясь до реальных данных и, анализируя их, выявляет атаки. Хоть мне и не нравится такой подход у cloudflare, но, признаю — он дает больше простора для выявления атак.

Cloudflare ещё и даёт кучу плюшек кроме защиты. Это CDN с кешированием статики на эдж серверах, экспорт логов (только в энтерпрайзе, к сожалению), возможность писать свои лямбды на js, которые будут исполняться максимально близко к клиенту.

В вашем примере сейчас хотя бы вообще можно отрезать этот js и любоваться на голый html. Ну и баннеры, к примеру, поодкусывать. А с бандлами прилетит нечто, внутрь чего не залезешь никак. Либо доверься и терпи, либо проходи не задерживайся.
Google решили переизобрести mht и chm и распространить его на весь интернет? Пока не очень понятно, как это будет генерироваться на стороне сервера.
Впрочем, если учесть, что нынешние сайты — это зачастую статичный фронтенд к API и вся логика тянется в браузер пользователя — возможно логика в этом есть.

Есть ещё Data: URL который позволяет встраивать изображения и другие бинарные данные в HTML.

Связь WebBundle с борьбой с адблокерами очень натянута. Да, для рекламы удобно использовать WebBundle, т.к. реклама — это html + js/css/img ресурсы. Но WebBundle не позволяет прятать url — сам бандл всё равно будет загружаться с рекламных доменов, которые можно блокировать так же, как они блокируются сейчас. К тому же перед тем, как реклама загрузится — сначала нужно загрузить рекламный скрипт на самой странице, который опять же блокируется блокером.

Так можно же на бэке склеить всё вместе с рекламой в один бандл и отдать в браузер уже готовое.
Но тогда отвалится весь ретаргетинг, который опирается на куки на стороне клиента.

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

Как я понял идею, реклама и ее ресурсы будут идти вместе с html с домена владельца ресурса.

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

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

Что значит, текущие? Серверная вставка реклама появилась раньше подгрузки сторонних скриптов. Потому основной частью такой рекламы блокировщики умели работать еще в ранние годы жизни (нормально научились с появлением браузерных расширений и firefox).

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

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

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

Опасения насчёт бандлов можно применить к любому приложению — судя по описанию, бандл — это примерно как приложение расчитанное для работы в ОС которой является браузер.

Да нормальная история с бандлами, их и так многие сайты используют, объединяя множество css и js, да и картинки, которые являются частью сайта (внутри css).
Учитывая, что веб-приложение уже можно представить себе как почти пустой html, в котором подключаются бандл стилей и js (а то и просто js, который стили содержит в себе), то отказаться от лишнего html файла звучит вполне здраво.

Про блокировщики рекламы явно идиотизм написан. Видимо те, кто по каким-то причинам противится бандлам, видят в этом отличный способ создать хейт на ровном месте — заявить что Гугл это делает, чтобы помешать блокировщикам рекламы.
Все, инициативу начнут разрывать не разбираясь как там оно на самом деле влияет на возможности блокировщиков (подсказка — скорее никак).

я написал свой адблок, который работает не по ссылкам а по месту на странице, тоесть я нахожу место в иерархии сайта и не даю ему отображаться — веб бандл это никак не спасёт… другое дело что как они звонят
заставят всех программистов заниматься этой чепухой

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

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

>заставят всех программистов заниматься этой чепухой

создадут «удобный» фреймворк, прохайпают его и вуаля ) веб-программисты в большинстве уже давно «скатились» до generate, slightly edit, publish

опыт Гугл-сайтов их ничему не научил? что все делали-делали на нём а потом его закрыли. если делать то надо на том что гарантированно будет поддерживаться хотябы какое-то вменяемое время

Познавательно спасибо! но вот блок «На правах рекламы» в такой статье смотрится как-то кощунственно…
Я думаю логика Гугла в этом такая:
— медленно и незаметно подсадить на бандлы весь интернет (под пения о безопасности и скорости загрузки)
— начать кешировать бандлы на своих серверах, не давая владельцу сайта встраивать (или обновлять) рекламу, а може встраивать свою рекламу (или замещать чужую)
— придумать тарифные планы для желающих управлять ситуацией
Думаю у Гуле только и мечтают, чтобы весь интернет будет хостился у них.
С развитием скоростей интернета, можно наверно на WebGL всё рисовать и через сокет с БЕ работать, типа терминала для веба. Радует только то что пока на нём не так просто писать и кеширование всё ещё востребовано, но вот у меня дома интернет уже 500мб/с и я даже в игрушки через nvidia geforce now играю, а раз можно игрушки играть то следующий уровень веба это из браузера сделать клиент который показывает картинку при этом сам ничего не делает, вот тогда веб действительно станет 3.0/4.0, не будет больше никаких исходников странички вообще, вроде всем плюс не будет кучу памяти жрать, а на страничке можно как в бесплатных игрушках на телефоне пихать рекламу на любое действие
Значительная часть пользователей сидит в Интернете с мобильных устройств через 3G/4G. А там никакие 500 Мб/с невозможны в принципе. Да даже 50 невозможны. Я и на счёт честных 5Мб/с сильно сомневаюсь — в реальных условиях оно тоже вряд ли достижимо.
Плюс лимит на трафик. Все так называемые «безлимитные» тарифы на самом деле переходят в режим «позавидуй dial-up'у» уже после пары десятков выкачанных Гб, и далеко не везде и не у всех операторов есть возможность хотя бы докупить гигабайты — только менять тариф целиком.
И это ещё в городах-миллионниках. Что же происходит в менее крупных населённых пунктах, даже представить страшно.
А еще вечером скорость падает, причём даже в обжитых кварталах с многоквартирными домами. Что там в частном секторе в это время происходит, я даже представлять не хочу.
А мне вот пока не понятно, чем это отличается от мобильных приложений? :-)
Это же тот же подход, что и для apk, разве нет? Видимо просто так удобно архитекторам, на диаграмме просто скопипастили с части под названием «Мобильные приложения» в часть «Веб-сайты» :-).
Главное что бы потом не пришлось эти «приложения» подписывать у гугла.
Браузер на 100% их, поисковик на 100% их, что захотят, то воротят. Не выполняешь требования гугла — идёшь нафик. Уже сейчас выдача гугла часто стерильна до невозможного. Печально всё это…
Браузер на 100% их, поисковик на 100% их, что захотят, то воротят.
Вы забыли, что ещё и рекламный бизнес тоже того… их.
Уже сейчас выдача гугла часто стерильна до невозможного.
«Гуглонет»
Да веб-сайты и так же все подписываются. Сертификаты-то регулярно получают и обновляют, без HTTPS сегодня никуда.
Да ничем. Автор же явно написал:

>по принципу «все или ничего» (например, как уже работают PDF или SWF)

Вот SWF это и есть (был) ровно такой ресурс. И прямо скажем, для разработчика это как раз было удобно. Потому что когда вы упаковали все свои ресурсы в один файл — вы точно знаете, что они будут доступны приложению, все сразу и всегда. Ну и apk в общем примерно из той же оперы — только SWF устанавливать не нужно.
Кто-нибудь может пояснить, чем это принципиально отличается от WebAssembly?
Практически всем.

WASM — скомпилированный байт-код, выполняемый виртуальной машиной. На текущем уровне развития не имеет возможности напрямую взаимодействовать с DOM и Web APIs, поэтому работа идет по принципу «дернули функцию — получили результат».
Да, можно упороться, навернуть JS-прослойку, и из WASM-кода рисовать все что угодно в Canvas и передавать все user input событий в код WASM, и таким образом запустить все что угодно (даже целую операционную систему) внутри браузера, а при желании еще и все ресурсы запихать в один файл… Но в таком случае от «Web» тут по сути дела останется одно только название, в том смысле, что это будет уже не «сайт» в классическом понимании, а именно что отдельное приложение.

А WebBundle — это классические HTML+CSS+JS, только склеенные в один файл во имя оптимизаций. А для рендеринга всего этого и интерактивности используются самые обычные стандартные механизмы браузера.
Я вот только не пойму, а чем это будет быстрее? Ну т.е. новый стандарт(да и старый, но с ограничениями) http2 делает упор на параллелизм — все ресурсы скачиваются параллельно, и html файл, как правило, самый первый скачивается и отображается, давая пользователю возможность посмотреть контент. Но если мы сожмем(в статье ведь написано про упаковку, как в pdf), то для того, чтобы распаковать весь этот архив, необходимо будет скачать весь файл, со всей js рекламой и картинками. Так в чем скорость?

Да, некоторые склеивают js код для оптимизации, но ведь, насколько я знаю, делается это потому, что у http1.1 ограничение на передачу одновременно 8 файлов, т.е. мы скачиваем html,css, и один склееный js-bundle вместо десятков отдельных файлов. При этом, если мы его не получим, или получим с задержкой, то особо критично это не будет(конечно, если это сделать грамотно)

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

То ли лыжи не едут, то ли я чего-то не понимаю, то ли это какая-то невнятная истерия. При чем тут вообще блокировщики рекламы? Это ж по сути упаковка PWA в один файл, и вне PWA никакого интереса не представляет.

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


Что-то из серии "покупая у нас Кока-колу вы получаете в подарок чизбургер, который мы кладём вам прямо в неё. Нет, вы не можете отказаться. Приятного аппетита!"

Чем гуглу не нравится chm, который изобрели еще до того как родился самый старый сотрудник гугла? Что за пафос изобретения новых велосипедов?
Тем, что проприетарный. Например, он недокументирован, и все данные об этом формате получены исключительно путём реверсинжениринга. Ну и почти наверняка там какие-нибудь патентно-лицензионные ограничения.
Вы и сейчас, совершенно спокойно можете грузить ассеты в бандлах с зашитой в них рекламой. Новые бандлы, в этом отношении, ничего не меняют ВООБЩЕ. Аналогично с безопасностью. Ну ерунда же полная, откуда столько плюсов у статьи? Просто сейчас модно ругать Гугл?
Ну ладно ещё для SPA, а как это должно работать для сайтов, у которых больше 3-х страниц? Например интернет-магазинов или новостных порталов? Под каждую из 100500 страниц компилировать отдельный бандл?
Интернет-магазин или новостной портал тоже может быть сделан как SPA. Полагаю, Гугл именно за это и топит.
Не вижу никакой проблемы вообще, данный подход можно было использовать и другими способами, например через вебсокеты передавай что угодно. А блокировщики не только по урл-ам работают, но и по элементам странички, так что сильно не измениться, пока не рисуют всё страничку через WebGl всё довольно легко блокируется.
Но если Google станет продвигать WebBundles как повсеместный инструмент, для веба могут настать крайне мрачные времена, и вот почему.

Если до этой фразы встречаются обычные неточности, то начиная с этой фразы автор несет лютый бред. Но ему это без разницы, т.к. ему главное воткнуть рекламу, а качество материала его не интересует.
  • Бандлы не отменяют HTML, JS, CSS и прочие ресурсы, совершенно неожиданно.
  • Более того, бандлы не отменяют URL адреса, но само предложение автор либо не осилил прочитать, либо даже не собирался (ибо зачем?).
  • Бандлы не отменяют выпиливание рекламы по контенту.
  • Бандлы есть только в хроме, но Google Chrome != Chromium, и уж тем более не равен FF.

В Chromium тоже есть, специально проверил.
Но вообще бандлы никому не мешают — наоборот, дают больше возможностей разработчикам в плане создания оффлайновых приложений. Если скрипты локально сохранённой странички запускаются с сильно урезанными правами (вы к примеру даже не можете сделать getImageData для локально сохранённых картинок — это только в онлайне работает), то для бандла таких ограничений нет. И вы можете создать полноценное оффлайновое приложение, которое можно просто копировать с девайса на девайс без помощи сети.
В Chromium тоже есть, специально проверил.

Т.е. первоисточником является сам Chromium, а не Google Chrome. Еще лучше. Хоть и инициатором был гугл.
Но вообще бандлы никому не мешают

Так и я за это. Взяли нормальную эксперементальную технологию, выставили вселенским злом, повесили это зло на гугла. Хотя единственное, на что эта технология нацелена: уменьшить количество запросов к серверу/CDN.
Про оффлайн тоже согласен, может быть полезно.
единственное, на что эта технология нацелена: уменьшить количество запросов к серверу/CDN.

Ещё неизвестно, уменьшится ли реально число запросов. Потому что для этого нужно чтобы пользователь много раз заходил на один и тот же абсолютно статичный сайт — потому что если сайт меняется, то придётся перекачивать весь бандл. Может это и меньше запросов, чем тянуть отдельно HTML и отдельно CSS, но зато запросы сами "толще", а значит живут дольше, и ещё неизвестно, что для CDN будет хуже.

А с чего вы взяли, что вся страница целиком должно отдаваться одним пакетом?
Web bundles provide a way to bundle up groups of HTTP responses, with the URLs and request URLs that produced them, to transmit or store them together. They can include multiple top-level resources with one identified as the default by a primaryUrl metadata, provide random access to their component exchanges, and efficiently store 8-bit resources.

Суть как раз в объединении статичного контента в готовый пакет. Т.е. вместо пачки JS-CSS-Картинок, с отдельным запросом на каждый файл, оно позволяет скачать один пакет со статичным контентом. Вместо десятка запросов пойдет всего один, и это хорошо как для CDN, так и для сервера. Для динамики бандлы само собой не годятся, но это и не их задача.
фраза с древнего баша «я скачал сайт» заиграла новыми красками

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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

22 мая 2014 г.

Местоположение

Россия

Сайт

vdsina.ru

Численность

11–30 человек

Дата регистрации

24 сентября 2019