Комментарии 43
в свое время один сайт вдруг начал открывать страницы по пол-минуты. оказалось, на нем был код рекламной метрики, адрес которой был заблокирован на системе. и страница упорно пыталась с него что-то скачать, пока не отваливалась по тайм-ауту.
Проблема остро встала после блокировки русских сайтов в Украине, так как много сайтов пользуется виджетами вк и аналитикой яндекса. Фригейт неплохо справлялся с этим но как недавно стало понятно что он может слить что-угодно пришлось отказатся от него.
Ниразу не удивился увидев ГА в топе. В 2013 году, у гугла был сбой, длительность 5 минут. Глобальный интернет трафик упал на 43%. Объяснения излишни.
По результатам проверки какие вычислительные ресурсы необходимы для использования веба в 2020? Сколько тактов процессора и памяти тратится на типовую страницу и какой её средний загружаемый объём данных.
Может, когда-то мы снова будем жить в мире, где веб-страницы весят килобайты и грузятся мгновенно, где нет никакой телеметрии и слишком хитрой рекламы.
Пусть это прозвучит наивно, но я мечтаю: вот бы появился и стал популярным какой-нибудь браузер, который грузил бы только тело страницы и полезный контент, а все эти рекламно-следящие штуки не только не подгружал, но и ДДОСил адреса, откуда оно лезет, чтоб всё оно в итоге от мощного ДДОСа рушилось и не работало вообще, а рекламодатели учились бы умещать свою рекламу в обычный статичный кликабельный jpeg не более 240*320 пикселей. При этом чтобы язык разметки был бы всеобщим и статичным (а не так, что двухлетний браузер не может открыть половину новых сайтов).
Пусть это прозвучит наивно, но я мечтаю: вот бы появился и стал популярным какой-нибудь браузер, который грузил бы только тело страницы и полезный контент, а все эти рекламно-следящие штуки не только не подгружал, но и ДДОСил адреса, откуда оно лезет, чтоб всё оно в итоге от мощного ДДОСа рушилось и не работало вообще, а рекламодатели учились бы умещать свою рекламу в обычный статичный кликабельный jpeg не более 240*320 пикселей. При этом чтобы язык разметки был бы всеобщим и статичным (а не так, что двухлетний браузер не может открыть половину новых сайтов).
А в чем проблема использовать блокировщики?
А в чем проблема использовать блокировщики?
Например, вот в этом
html.no-print-color-adjust body._metro-jams-experiment._font_loaded._app_ready._url_controlled._map_ready div.body div.app div.sidebar-container div.sidebar-view._name_home._shown div.sidebar-view__panel div.scroll._width_narrow div.scroll__container div.scroll__content div.home-panel-content-view div.home-panel-content-view__body div.hw__eabffdabcadc div.knl__aadfbbbbbfc div.xureq__cebabedfaaff div.udn__fbeaecacaebffadd div.whoik__fdadfebbdcede div.bwu__fbcfdfbaffbcdcd div.ldhzu__adeafabccfeaaf div.cujf__efebcaccaedccfНЛО прилетело и опубликовало эту надпись здесь
Можете пояснить, как работает кеширование JS? Т.е. в каком случае мы пытаемся скачать ту же jQuery, а в каком пользуемся локальной копией? Ну и глупый вопрос: если взять самые популярные/толстые/медленные библиотеки, переписать их на условных плюсах и сделать плагин для браузера, чтобы обращения к cdn подменял на вызов этих библиотек где-то в глубинах движка, насколько станет проще жить?
С некоторых по ключу типа: домен_страницы + полный урл ссылки. CDN теперь лишь "приближает" файл к юзеру, на то что этот урл был скачен когда-то для другого сайта рассчитывать уже нельзя
- Вроде же есть WebAssembly
- Могут потребоваться разные версии библиотек. Да и как обновлять их? Если не указана версия (т.е. подразумевается последняя), то возникнет неоднозначность.
- Кроме того, это всё скорее проблема первой загрузки, потом всё равно из локального кэша подтянется.
1. Он же требует усилий от разработчика?
2. Ну это решается организационными мерами. Как-то же научились справляться с library hell через менеджеры пакетов, здесь не вижу большого различия.
3. А подтянется ли?
Вообще меня несколько смущает то, как ругают С и плюсы за отсутствие модульности и менеджера пакетов, ад с версиями библиотек, обилие велосипедов и небезопасность, а в стильно-модно-молодёжном вебе все те же проблемы, но это как бы ОК.
2. Ну это решается организационными мерами. Как-то же научились справляться с library hell через менеджеры пакетов, здесь не вижу большого различия.
3. А подтянется ли?
Вообще меня несколько смущает то, как ругают С и плюсы за отсутствие модульности и менеджера пакетов, ад с версиями библиотек, обилие велосипедов и небезопасность, а в стильно-модно-молодёжном вебе все те же проблемы, но это как бы ОК.
2.решение library hell для веба, полагаю, должно выглядеть в духе "Отображение этого сайта не поддерживается в вашей версии браузера. Пожалуйста, обновите браузер." ))
Вообще, в этом духе построен IPFS. Его, кста, поддерживает CloudFlare (и собственно применимо к вебу: https://blog.cloudflare.com/distributed-web-gateway/). Присмотритесь к этому решению, если вам это интересно.
Спасибо. Но с подходом «Отображение этого сайта не поддерживается в вашей версии браузера.» мы не придём к китаенету и к обновлениям апдейтов хотфиксов виндовс?
Вот и я про то. Не вижу я другого способа решения проблемы не изобретая интернет заново.
На уровне языка (например, Rust и Python) средства в принципе есть, хотя, конечно, лучше иметь тесты, чтобы быть уверенным, что функция с совпадающими названием и сигнатурой в разных версиях библиотеки делает одно и то же. Но поскольку вход в веб-программирование самый низкий, требовать что-то от заказчиков и разработчиков глупо и придётся смотреть в сторону code-to-code compilation/interpretation. В принципе-то разработки в десктопном программировании есть, особенно для борьбы с легаси или миграции на другой язык.
тут я не в теме
Библиотеки на публичных CDN обычно имеют версию в урле в том или ином виде, иногда даже рандомную, но на кэширование это на практике не влияет, если 6+ знаков
Однозначно, если нет вытеснения или пользователь постоянно кэш не чистит, но на время одной сессии можно рассчитывать
Почему-то 8% веб-сайтов определяют полифил setImmediate/clearImmediate для функции, реализация которой даже не планируется ни в одном из браузеров.
redux жи ну
Де-факто гугл сжирает чуть ли не половину… Доколе мы будем терпеть произвол?
Все блокировщики рекламы это всё давно блокируют.
Так запросы все равно уходят.
Нет, конечно.
Почему бы? Я вот сейчас с AdBlock Plus на страницу Яндекса зашел — 160 запросов на открытии, чуть ли не половина — Google Ads и Директ, хоть рекламы самой на странице и нет (т.к. плагин удаляет блоки с уже отрисованной страницы)
Так надо ведь пользоваться чем-то современнее, чем AdBlock Plus.
Вот, например: up.agrd.eu/jHm89H.png
Вот, например: up.agrd.eu/jHm89H.png
Ну вон, GitHub отказались.
Интернет погубит выбранная модель монетизации и человеческая жадность. На моё скромное мнение на каждой странице сейчас порядка десатков килобайт полезной информации (ради которых мы и заходим на страницу), а всё остальное трэкеры, реклама, сценарии и прочий мусор. Блокировщики намеренно написаны самым плюшевым образом, чтобы пользователь никогда не смог отрезать жадных коммерсантов от дохода. Однако возврат во времена начала, с интерактивным контентом в Java-аплетах и Flash тоже не вариант. Потому что уже сценарии начала 2000х это не только интерактивные формы, но и трэкеры с прочим мусором. Было бы здорово получить современный HTML5+CSS без загружаемых исполняемых сценариев, но это антинаучная фантастика, хотя отрубить загрузку сценариев со сторонних (относительно просматриваемой страницы) сайтов очень хотелось бы. Тем более, что структура кэша на это намекает. Но получится как в том случае, когда Роскомнадзор отключил AWS.
Как вариант — сделать это в виде аддона для браузеров и библиотеки скриптов/правил очищалок для каждого сайта отдельно. Для CNN одни правила будут, для Meduza.io другие, для Apple.com третьи. А вот для IgrushkiDlyaDeteyGorodKirov.ru правил не будут и там скрипты останутся, но трафик этого сайта не такой уж и значительный.
Я так и не понял, каков же в результате ответ на вопрос в заголовке? Из-за чего таки тормозит Веб? Только лишь jQuery?
Из-за коммерческих костылей и наплевательскому отношению к ресурсам.
Похоже, мы не можем отвязаться от того факта, что протоколы стали быстрее, а поэтому довольные программисты пользуются этим ускорением, доставляя в браузер больше данных.
Да не потому что протоколы стали быстрее, а потому что 15-20 лет назад скорость интернета была во много раз ниже, а даже сложный сайт был набором html-страниц, а не приложением на реакте даже для визиток.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мы отрендерили миллион страниц, чтобы понять, из-за чего тормозит веб