Comments 94
Оказывается чего только не придумают. А я то думал что в обучении SCORM формат (зазипованный сайт открывающийся в айфрейме) это дно. А тут вон ещё сильнее закрутили.
Google решил убить Cloudflare?)
Но на самом деле мне кажется, что это задачка нереальная, потому что отвалится вся система кеширования (картинок, js, css). Такой рост объема данных «интернет» просто не переварит.
Если я заблуждаюсь — поправьте меня пожалуйста.
Но на самом деле мне кажется, что это задачка нереальная, потому что отвалится вся система кеширования (картинок, js, css). Такой рост объема данных «интернет» просто не переварит.
Если я заблуждаюсь — поправьте меня пожалуйста.
Кэширование не отвалится, потому что обращение к ресурсу в бандле выполняется на более низком уровне, подменяя запрос по сети.
Но Гугл активно пропихивает AMP и тут бандлы ему очень пригодятся. А в дальней переспективе, вполне возможно, планирует вырастить из AMP конкурента Cloudflare.
WebBundles на сколько я понял загружает весь сайт целиком за раз как один файл. AMP же вроде наоборот откладывает загрузку ресурсов страницы(изображений например) до момента когда они понадобятся.
Ну, если запрос полетит уже из самого бандла — все вроде становится на свои места. То есть можно будет уменьшить его размер оставив статику на cdn, а потом с AMP по мере надобности дотягивать непрозрачно для пользователя.
Да, CDN это не убьет, но переконфигурить все придется основательно. Плюс часть функций вроде файрволла станут бесполезны, наверное. Ведь пользователь уже не сможет рандомно обшаривать локации на сайте.
Да, 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.
Как отказаться от этого кеширования в вебе — я не понимаю.
Сейчас 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% — это кеш.
При повторной загрузке страницы загружает
116kB из 6.9MB
Это 1,5%
Для новой статьи (которую я еще не читал) загрузилось со всеми картинками 800kB из 6.8MB
Это 11%
Оставшиеся 89% — это кеш.
Это всё имеет смысл только для ресурсов, которые вы посещаете регулярно, так что они не вываливаются из кэша вашего браузера. Не знаю как вы, а я, помимо хабра и ещё двух своих ежедневных сайтов, захожу из поиска ещё на несколько десятков сайтов, так что мой браузер вынужден качать горы мусора ради нескольких капель ценной информации. Так что нет, я не думаю, что в глобальном масштабе потребление трафика возрастёт.
Ну и возвращаясь к опере мобайл, она показывала снижение трафика в несколько раз даже при посещении одного и того же сайта.
Ну и возвращаясь к опере мобайл, она показывала снижение трафика в несколько раз даже при посещении одного и того же сайта.
UFO just landed and posted this here
там еще mhtml был вроде
Не мог, для chm отдельная смотрелка была, да и назначение у формата иное (хотя при желании можно было хоть сайт целиком запихнуть).
Очень даже мог, и не только сhm, но и новый формат справки (забыл используемые там расширения). Вбиваете адрес «mk:@MSITStore:<путь к файлу chm>::<путь к html внутри chm>» и вперёд. А по протоколу res он и в PE-файлах мог контент смотреть: «res://<путь к exe/dll/whatever>/<путь к html внутри файла>».
У меня в библиотеке хранится учебник по Эсперанто в .chm формате. Это удобно исключительно для offline-просмотра. В живом интернете я бы эту мерзозть видеть не хотел
UFO just landed and posted this here
Еще хуже то, что этому движку сейчас нет внятных альтернатив, потому что даже Microsoft уже как два года «пристрелили и закопали» свою стюардессу EdgeHTML, перейдя на Chromium.
Резво автор похоронил Mozilla с их Gecko.
Вроде у мазилы основной донатер как раз гугль. Поэтому, видать, у них сейчас сокращение штата и вообще туманное будущее (тут были статьи на эту тему около месяца назад вроде).
У них свободный код, так что даже полная остановка Mozilla не помешает легально пересобирать и патчить его отдельным энузиастам и компаниям, в отличии от presto
Веб развивается, сложно будет поддерживать новые стандарты энтузиастам, чтобы хотя бы выглядело все приемлемо. Для этого нужен постоянный штат разрабов
И будет зоопарк сборок, типа ЗверьДВД. Где-то будет работать нужное расширение или встроенная фича, а где-то нет. И держи на компе стопицот разных вариантов разных сборок под разные задачи…
Зверь — сборка собственнической программы, выполненная людьми с неопределённой компетентностью. В случае свободного кода, никто не мешает применить сразу несколько патчей и собрать программу со всеми. Подобный подход весьма распространён, например aur.archlinux.org/packages/ungoogled-chromium-ozone это chromium(основа) с несколькими патчами, а именно ungoogled для избавления привязки к гуглу, ozone — для работы под wayland, vaapi — для аппаратного декодирования видео и так далее.
Стоп-стоп. Я сейчас с точки зрения юзера говорю, а не прогера (а я и правда не прогер). И как мне во всём этом зоопарке разбираться?
С точки зрения пользователя вы приходите на форум или куда-то ещё либо с вопросом(при просмотре видео загружен процессор) либо просто читаете рекомендации. Возможно вам дадут описание, что какое слово означает, либо просто скажут — ставьте вот это. После этого, вы с помощью одной команды, либо через графический установщик ставите то что вам нужно.
В то же время, есть отдельные люди, какие пишут патчи, и отдельные люди, какие собирают программы, хотя иногда это одни и те же люди. Они сами между собой будут решать, что и как сделать, вам же погружаться в их работу, для того чтобы понять что они делают не обязательно.
В то же время, есть отдельные люди, какие пишут патчи, и отдельные люди, какие собирают программы, хотя иногда это одни и те же люди. Они сами между собой будут решать, что и как сделать, вам же погружаться в их работу, для того чтобы понять что они делают не обязательно.
К сожалению, они и сами с похоронами успешно справляются.
Ну и по большому счету, 2-3% у всех лисоподобных — это на уровне статистической погрешности
Ну и по большому счету, 2-3% у всех лисоподобных — это на уровне статистической погрешности
Ну есть ещё поисковики, которые даже контент, генерируемый JS, толком не умеют индексировать. А тут нате вам ещё один новый стандарт.
UFO just landed and posted this here
Я что-то не понимаю, а чем принципиально существующий подход безопаснее? По-моему у веб-мастеров нет никаких ограничений по тому, чтобы надергать куски js с других сайтов, склеить их со своими, минифицировать — и получится примерно такой же бандл «все-или-ничего».
Мне кажется у этой идеи есть потенциал в ускорении передачи данных от веб-сервера браузеру.
Мне кажется у этой идеи есть потенциал в ускорении передачи данных от веб-сервера браузеру.
Так а в чем ускорение? Http2 и так сделал бесполезным бандлирование и огромные картинки, которые надо разрезать на клиенте
Да, это одна проблема. Ее пытаются решить и со стороны веб-серверов — в стандартах http. Но, думаю, что решать на уровне приложения гораздо удобнее и шире по потенциальным функциям, чем на условно сеансовом и транспортном.
Примерно в этом же концепте шел, например, cloudflare — он перешифровывает весь трафик, добираясь до реальных данных и, анализируя их, выявляет атаки. Хоть мне и не нравится такой подход у cloudflare, но, признаю — он дает больше простора для выявления атак.
Примерно в этом же концепте шел, например, cloudflare — он перешифровывает весь трафик, добираясь до реальных данных и, анализируя их, выявляет атаки. Хоть мне и не нравится такой подход у cloudflare, но, признаю — он дает больше простора для выявления атак.
В вашем примере сейчас хотя бы вообще можно отрезать этот js и любоваться на голый html. Ну и баннеры, к примеру, поодкусывать. А с бандлами прилетит нечто, внутрь чего не залезешь никак. Либо доверься и терпи, либо проходи не задерживайся.
Google решили переизобрести mht и chm и распространить его на весь интернет? Пока не очень понятно, как это будет генерироваться на стороне сервера.
Впрочем, если учесть, что нынешние сайты — это зачастую статичный фронтенд к API и вся логика тянется в браузер пользователя — возможно логика в этом есть.
Впрочем, если учесть, что нынешние сайты — это зачастую статичный фронтенд к API и вся логика тянется в браузер пользователя — возможно логика в этом есть.
Есть ещё Data: URL который позволяет встраивать изображения и другие бинарные данные в HTML.
epub туда же…
Они сделали PoC бандлер на go.
Связь WebBundle с борьбой с адблокерами очень натянута. Да, для рекламы удобно использовать WebBundle, т.к. реклама — это html + js/css/img ресурсы. Но WebBundle не позволяет прятать url — сам бандл всё равно будет загружаться с рекламных доменов, которые можно блокировать так же, как они блокируются сейчас. К тому же перед тем, как реклама загрузится — сначала нужно загрузить рекламный скрипт на самой странице, который опять же блокируется блокером.
Так можно же на бэке склеить всё вместе с рекламой в один бандл и отдать в браузер уже готовое.
Но тогда отвалится весь ретаргетинг, который опирается на куки на стороне клиента.
Да, можно. Я об этом тоже упомянул тут. Но подход, который вы описываете не требует бандлов. Это можно сделать и сегодня. С бандлами легче, да, но это уже возможно.
Как я понял идею, реклама и ее ресурсы будут идти вместе с html с домена владельца ресурса.
Да, аукцион будет хуже работать в таком случае, потому что меньше контекстных данных, но все же профит все равно больше, чем при полной блокировке.
Да, аукцион будет хуже работать в таком случае, потому что меньше контекстных данных, но все же профит все равно больше, чем при полной блокировке.
Текущие технологии тоже позволяют это делать и без бандлов. Да, это кривее, чем с бандлами, но вполне реально. Как вы отметили — потери на аукционе могут быть слишком велики, по сравнению с потерями от адблокеров, чтобы это реализовывать.
К тому же перед тем, как реклама загрузится — сначала нужно загрузить рекламный скрипт на самой странице, который опять же блокируется блокером.На страницу можно воткнуть загрузчик, показывающий квадрат Малевича до загрузки самой рекламы.
Google Chrome, даже обвешанный банерорезками, отправляет себе на родину кучу аналитики. Там страдают больше маркетологи сайтов, на которых пользователи не пожелали смотреть рекламу. Гугл остаётся при своих.
Опасения насчёт бандлов можно применить к любому приложению — судя по описанию, бандл — это примерно как приложение расчитанное для работы в ОС которой является браузер.
Да нормальная история с бандлами, их и так многие сайты используют, объединяя множество css и js, да и картинки, которые являются частью сайта (внутри css).
Учитывая, что веб-приложение уже можно представить себе как почти пустой html, в котором подключаются бандл стилей и js (а то и просто js, который стили содержит в себе), то отказаться от лишнего html файла звучит вполне здраво.
Про блокировщики рекламы явно идиотизм написан. Видимо те, кто по каким-то причинам противится бандлам, видят в этом отличный способ создать хейт на ровном месте — заявить что Гугл это делает, чтобы помешать блокировщикам рекламы.
Все, инициативу начнут разрывать не разбираясь как там оно на самом деле влияет на возможности блокировщиков (подсказка — скорее никак).
Учитывая, что веб-приложение уже можно представить себе как почти пустой html, в котором подключаются бандл стилей и js (а то и просто js, который стили содержит в себе), то отказаться от лишнего html файла звучит вполне здраво.
Про блокировщики рекламы явно идиотизм написан. Видимо те, кто по каким-то причинам противится бандлам, видят в этом отличный способ создать хейт на ровном месте — заявить что Гугл это делает, чтобы помешать блокировщикам рекламы.
Все, инициативу начнут разрывать не разбираясь как там оно на самом деле влияет на возможности блокировщиков (подсказка — скорее никак).
я написал свой адблок, который работает не по ссылкам а по месту на странице, тоесть я нахожу место в иерархии сайта и не даю ему отображаться — веб бандл это никак не спасёт… другое дело что как они звонят
заставят всех программистов заниматься этой чепухой
А оригинальный Адблок точно так не умеет? Там вроде с самого запуска такая функциональность есть, пару лет назад ее дополнительно расширили тем, что не поддерживается в стандартных css селекторах.
>заставят всех программистов заниматься этой чепухой
создадут «удобный» фреймворк, прохайпают его и вуаля ) веб-программисты в большинстве уже давно «скатились» до generate, slightly edit, publish
создадут «удобный» фреймворк, прохайпают его и вуаля ) веб-программисты в большинстве уже давно «скатились» до generate, slightly edit, publish
Познавательно спасибо! но вот блок «На правах рекламы» в такой статье смотрится как-то кощунственно…
Я думаю логика Гугла в этом такая:
— медленно и незаметно подсадить на бандлы весь интернет (под пения о безопасности и скорости загрузки)
— начать кешировать бандлы на своих серверах, не давая владельцу сайта встраивать (или обновлять) рекламу, а може встраивать свою рекламу (или замещать чужую)
— придумать тарифные планы для желающих управлять ситуацией
Думаю у Гуле только и мечтают, чтобы весь интернет будет хостился у них.
— медленно и незаметно подсадить на бандлы весь интернет (под пения о безопасности и скорости загрузки)
— начать кешировать бандлы на своих серверах, не давая владельцу сайта встраивать (или обновлять) рекламу, а може встраивать свою рекламу (или замещать чужую)
— придумать тарифные планы для желающих управлять ситуацией
Думаю у Гуле только и мечтают, чтобы весь интернет будет хостился у них.
«Сайты на флеше» 2.0.
«Это другое»
С развитием скоростей интернета, можно наверно на WebGL всё рисовать и через сокет с БЕ работать, типа терминала для веба. Радует только то что пока на нём не так просто писать и кеширование всё ещё востребовано, но вот у меня дома интернет уже 500мб/с и я даже в игрушки через nvidia geforce now играю, а раз можно игрушки играть то следующий уровень веба это из браузера сделать клиент который показывает картинку при этом сам ничего не делает, вот тогда веб действительно станет 3.0/4.0, не будет больше никаких исходников странички вообще, вроде всем плюс не будет кучу памяти жрать, а на страничке можно как в бесплатных игрушках на телефоне пихать рекламу на любое действие
Значительная часть пользователей сидит в Интернете с мобильных устройств через 3G/4G. А там никакие 500 Мб/с невозможны в принципе. Да даже 50 невозможны. Я и на счёт честных 5Мб/с сильно сомневаюсь — в реальных условиях оно тоже вряд ли достижимо.
Плюс лимит на трафик. Все так называемые «безлимитные» тарифы на самом деле переходят в режим «позавидуй dial-up'у» уже после пары десятков выкачанных Гб, и далеко не везде и не у всех операторов есть возможность хотя бы докупить гигабайты — только менять тариф целиком.
И это ещё в городах-миллионниках. Что же происходит в менее крупных населённых пунктах, даже представить страшно.
Плюс лимит на трафик. Все так называемые «безлимитные» тарифы на самом деле переходят в режим «позавидуй dial-up'у» уже после пары десятков выкачанных Гб, и далеко не везде и не у всех операторов есть возможность хотя бы докупить гигабайты — только менять тариф целиком.
И это ещё в городах-миллионниках. Что же происходит в менее крупных населённых пунктах, даже представить страшно.
А мне вот пока не понятно, чем это отличается от мобильных приложений? :-)
Это же тот же подход, что и для apk, разве нет? Видимо просто так удобно архитекторам, на диаграмме просто скопипастили с части под названием «Мобильные приложения» в часть «Веб-сайты» :-).
Это же тот же подход, что и для apk, разве нет? Видимо просто так удобно архитекторам, на диаграмме просто скопипастили с части под названием «Мобильные приложения» в часть «Веб-сайты» :-).
Главное что бы потом не пришлось эти «приложения» подписывать у гугла.
Да ничем. Автор же явно написал:
>по принципу «все или ничего» (например, как уже работают PDF или SWF)
Вот SWF это и есть (был) ровно такой ресурс. И прямо скажем, для разработчика это как раз было удобно. Потому что когда вы упаковали все свои ресурсы в один файл — вы точно знаете, что они будут доступны приложению, все сразу и всегда. Ну и apk в общем примерно из той же оперы — только SWF устанавливать не нужно.
>по принципу «все или ничего» (например, как уже работают PDF или SWF)
Вот SWF это и есть (был) ровно такой ресурс. И прямо скажем, для разработчика это как раз было удобно. Потому что когда вы упаковали все свои ресурсы в один файл — вы точно знаете, что они будут доступны приложению, все сразу и всегда. Ну и apk в общем примерно из той же оперы — только SWF устанавливать не нужно.
Кто-нибудь может пояснить, чем это принципиально отличается от WebAssembly?
UFO just landed and posted this here
Я вот только не пойму, а чем это будет быстрее? Ну т.е. новый стандарт(да и старый, но с ограничениями) http2 делает упор на параллелизм — все ресурсы скачиваются параллельно, и html файл, как правило, самый первый скачивается и отображается, давая пользователю возможность посмотреть контент. Но если мы сожмем(в статье ведь написано про упаковку, как в pdf), то для того, чтобы распаковать весь этот архив, необходимо будет скачать весь файл, со всей js рекламой и картинками. Так в чем скорость?
Да, некоторые склеивают js код для оптимизации, но ведь, насколько я знаю, делается это потому, что у http1.1 ограничение на передачу одновременно 8 файлов, т.е. мы скачиваем html,css, и один склееный js-bundle вместо десятков отдельных файлов. При этом, если мы его не получим, или получим с задержкой, то особо критично это не будет(конечно, если это сделать грамотно)
Да, некоторые склеивают js код для оптимизации, но ведь, насколько я знаю, делается это потому, что у http1.1 ограничение на передачу одновременно 8 файлов, т.е. мы скачиваем html,css, и один склееный js-bundle вместо десятков отдельных файлов. При этом, если мы его не получим, или получим с задержкой, то особо критично это не будет(конечно, если это сделать грамотно)
У IE был MHTML, у Мозиллы — архив на основе jar, никто не паниковал, вроде :)
То ли лыжи не едут, то ли я чего-то не понимаю, то ли это какая-то невнятная истерия. При чем тут вообще блокировщики рекламы? Это ж по сути упаковка PWA в один файл, и вне PWA никакого интереса не представляет.
Вместо того, чтобы оптимизировать траффик и не грузить файлы, которые не используются на конкретной странице, они предлегают грузить всё подряд бандлом.
Что-то из серии "покупая у нас Кока-колу вы получаете в подарок чизбургер, который мы кладём вам прямо в неё. Нет, вы не можете отказаться. Приятного аппетита!"
Чем гуглу не нравится chm, который изобрели еще до того как родился самый старый сотрудник гугла? Что за пафос изобретения новых велосипедов?
Вы и сейчас, совершенно спокойно можете грузить ассеты в бандлах с зашитой в них рекламой. Новые бандлы, в этом отношении, ничего не меняют ВООБЩЕ. Аналогично с безопасностью. Ну ерунда же полная, откуда столько плюсов у статьи? Просто сейчас модно ругать Гугл?
Ну ладно ещё для SPA, а как это должно работать для сайтов, у которых больше 3-х страниц? Например интернет-магазинов или новостных порталов? Под каждую из 100500 страниц компилировать отдельный бандл?
Не вижу никакой проблемы вообще, данный подход можно было использовать и другими способами, например через вебсокеты передавай что угодно. А блокировщики не только по урл-ам работают, но и по элементам странички, так что сильно не измениться, пока не рисуют всё страничку через WebGl всё довольно легко блокируется.
Но если Google станет продвигать WebBundles как повсеместный инструмент, для веба могут настать крайне мрачные времена, и вот почему.
Если до этой фразы встречаются обычные неточности, то начиная с этой фразы автор несет лютый бред. Но ему это без разницы, т.к. ему главное воткнуть рекламу, а качество материала его не интересует.
- Бандлы не отменяют HTML, JS, CSS и прочие ресурсы, совершенно неожиданно.
- Более того, бандлы не отменяют URL адреса, но само предложение автор либо не осилил прочитать, либо даже не собирался (ибо зачем?).
- Бандлы не отменяют выпиливание рекламы по контенту.
- Бандлы есть только в хроме, но Google Chrome != Chromium, и уж тем более не равен FF.
В Chromium тоже есть, специально проверил.
Но вообще бандлы никому не мешают — наоборот, дают больше возможностей разработчикам в плане создания оффлайновых приложений. Если скрипты локально сохранённой странички запускаются с сильно урезанными правами (вы к примеру даже не можете сделать getImageData для локально сохранённых картинок — это только в онлайне работает), то для бандла таких ограничений нет. И вы можете создать полноценное оффлайновое приложение, которое можно просто копировать с девайса на девайс без помощи сети.
Но вообще бандлы никому не мешают — наоборот, дают больше возможностей разработчикам в плане создания оффлайновых приложений. Если скрипты локально сохранённой странички запускаются с сильно урезанными правами (вы к примеру даже не можете сделать getImageData для локально сохранённых картинок — это только в онлайне работает), то для бандла таких ограничений нет. И вы можете создать полноценное оффлайновое приложение, которое можно просто копировать с девайса на девайс без помощи сети.
В Chromium тоже есть, специально проверил.
Т.е. первоисточником является сам Chromium, а не Google Chrome. Еще лучше. Хоть и инициатором был гугл.
Но вообще бандлы никому не мешают
Так и я за это. Взяли нормальную эксперементальную технологию, выставили вселенским злом, повесили это зло на гугла. Хотя единственное, на что эта технология нацелена: уменьшить количество запросов к серверу/CDN.
Про оффлайн тоже согласен, может быть полезно.
единственное, на что эта технология нацелена: уменьшить количество запросов к серверу/CDN.
Ещё неизвестно, уменьшится ли реально число запросов. Потому что для этого нужно чтобы пользователь много раз заходил на один и тот же абсолютно статичный сайт — потому что если сайт меняется, то придётся перекачивать весь бандл. Может это и меньше запросов, чем тянуть отдельно HTML и отдельно CSS, но зато запросы сами "толще", а значит живут дольше, и ещё неизвестно, что для CDN будет хуже.
А с чего вы взяли, что вся страница целиком должно отдаваться одним пакетом?
Суть как раз в объединении статичного контента в готовый пакет. Т.е. вместо пачки JS-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, так и для сервера. Для динамики бандлы само собой не годятся, но это и не их задача.
фраза с древнего баша «я скачал сайт» заиграла новыми красками
По сути то остается тот же html + js из которого по прежнему можно будет удалять куски даже по тем же сигнатурам как уже очень давно делают антивирусы из файлов. А вот реальная польза на лицо как по мне, сейчас большинство сайтов настолько разбухли что они при мобильном интернете не открываются вообще, есть еще и такие что по 5 минут открываются при нормальном интернете на декстопе потому что грузят по 100 ресурсов в параллель общем размеров в 150 мегабайт, стоит только представить сколько идет загрузка 150 мегабайт при 5 мегабитах на adsl и все становится вообще печально.
И разработчики в большинстве своем не заморачиваються по этому поводу у них то свой собственный сайт из офиса наверняка быстро работает, а пользователи как правило страдают. И давайте будем честными сайты которые действительно заботятся о скорости загрузки и размере ресурсов единицы, в большинстве своем это раздутые склепанные на коленке с отвратительной оптимизацией.
И я вижу еще как поле для размышлений защита веб мастеров от недобросовестных заказчиков, ведь бандл != исходники да и скопировать сайт станет сложней, но это очень скользкая дорожка и все может обернутся очень плохо для всего интернета.
И разработчики в большинстве своем не заморачиваються по этому поводу у них то свой собственный сайт из офиса наверняка быстро работает, а пользователи как правило страдают. И давайте будем честными сайты которые действительно заботятся о скорости загрузки и размере ресурсов единицы, в большинстве своем это раздутые склепанные на коленке с отвратительной оптимизацией.
И я вижу еще как поле для размышлений защита веб мастеров от недобросовестных заказчиков, ведь бандл != исходники да и скопировать сайт станет сложней, но это очень скользкая дорожка и все может обернутся очень плохо для всего интернета.
Sign up to leave a comment.
Google продвигает новый стандарт WebBundles — потенциально опасную для веба технологию «упаковки» веб-сайтов