но активное использование в том же ютубе вполне тянет на фактическое продвижение
вы h264 имеете в виду? Шутите что-ли? Гугл активно продвигал свои кодеки, а не h264. Конечно, поддержку h264 ему тоже пришлось оставить, потому что vp8/vp9 далеко не везде поддерживались софтом, особенно поначалу. "Гугл продвигал h264" - даже звучит смешно. Так продвигал, что многим юзерам приходилось ставить специальное расширение, чтобы ютуб выдавал видео именно в h264, а не vp8/vp9, которые у этих юзеров железо аппаратно не поддерживало.
Потому что те API, что использует гугол - депрецированы уже. Удалены из стандарта.См
я в курсе ситуации с Shadow DOM v0, да, можно сказать, гугл этим подставил браузеры, которые не захотели имплементировать у себя v0 стандарт. Но, с другой стороны, разве документация по нему была скрыта?
Я даже на 95% уверен, что в действиях работников гугла не было злого умысла - просто они настолько вдохновились черновиком стандарта, что построили свой фреймворк (Polymer) на нем, а потом сложно было сразу переделывать. Они это сделали, но позже, в следующих мажорных версиях.
Gmail & [Google] Docs started to experience selective performance issues and bugs on Firefox
Ну и банальные проверки "если user agent != хром, то работай хреново/медленно", которыми ещё Intel грешил
вот это уже более интересные заявления, но, к сожалению, они не подкреплены фактами. Если гугл действительно умышленно ломал свои сервисы в чужих браузерах, его было бы легко поймать за руку, ведь это веб, исходный код доступен каждому.
Вот как раз вторая ваша ссылка и является такой попыткой поймать "корпорацию зла" на горячем. И даже на первый взгляд все выглядит страшно:
To clarify it more, it's simply this code in their polymer script link:
setTimeout(function() { c(); a.resolve(1) }, 5E3); which doesn't do anything except making you wait 5s (5E3 = 5000ms = 5s).
Но если перейти на реддит, откуда взята цитата, то в последующих сообщениях ситуацию можно увидеть в несколько ином контексте:
I checked the code with the part you quoted, I doubt this is firefox related as there'sno check on the user agent when this code is executed. It looks more like an ad-thing.
function smb() { var a, b, c, d, e, h, l; return t(function(m) { a = new aj; b = document.createElement("ytd-player"); try { document.body.prepend(b) } catch (p) { return m.return(4) } c = function() { b.parentElement && b.parentElement.removeChild(b) }; 0 < b.getElementsByTagName("div").length ? d = b.getElementsByTagName("div")[0] : (d = document.createElement("div"), b.appendChild(d)); e = document.createElement("div"); d.appendChild(e); h = document.createElement("video"); l = new Blob([new Uint8Array([26, 69, 223, 163, 159, 66, 134, 129, 1, 66, 247, 129, 1, 66, 242, 129, 4, 66, 243, 129, 8, 66, 130, 132, 119, 101, 98, 109, 66, 135, 129, 4, 66, 133, 129, 2, 24, 83, 128, 103, 1, 255, 255, 255, 255, 255, 255, 255, 21, 73, 169, 102, 153, 42, 215, 177, 131, 15, 66, 64, 77, 128, 134, 67, 104, 114, 111, 109, 101, 87, 65, 134, 67, 104, 114, 111, 109, 101, 22, 84, 174, 107, 169, 174, 167, 215, 129, 1, 115, 197, 135, 207, 96, 156, 234, 24, 157, 175, 131, 129, 1, 85, 238, 129, 1, 134, 133, 86, 95, 86, 80, 56, 224, 138, 176, 129, 1, 186, 129, 1, 83, 192, 129, 1, 31, 67, 182, 117, 1, 255, 255, 255, 255, 255, 255, 255, 231, 129, 0, 160, 204, 161, 162, 129, 0, 0, 0, 16, 2, 0, 157, 1, 42, 1, 0, 1, 0, 11, 199, 8, 133, 133, 136, 153, 132, 136, 63, 130, 0, 12, 13, 96, 0, 254, 229, 106, 0, 117, 161, 165, 166, 163, 238, 129, 1, 165, 158, 16, 2, 0, 157, 1, 42, 1, 0, 1, 0, 11, 199, 8, 133, 133, 136, 153, 132, 136, 63, 130, 0, 12, 13, 96, 0, 254, 232, 120, 0, 160, 187, 161, 152, 129, 3, 233, 0, 177, 1, 0, 47, 17, 252, 0, 24, 0, 48, 63, 244, 12, 0, 0, 0, 254, 229, 106, 0, 117, 161, 155, 166, 153, 238, 129, 1, 165, 148, 177, 1, 0, 47, 17, 252, 0, 24, 0, 48, 63, 244, 12, 0, 0, 0, 254, 232, 120, 0, 251, 129, 0, 160, 188, 161, 152, 129, 7, 208, 0, 177, 1, 0, 47, 17, 252, 0, 24, 0, 48, 63, 244, 12, 0, 0, 0, 254, 229, 106, 0, 117, 161, 155, 166, 153, 238, 129, 1, 165, 148, 177, 1, 0, 47, 17, 252, 0, 24, 0, 48, 63, 244, 12, 0, 0, 0, 254, 232, 120, 0, 251, 130, 3, 233 ])], { type: "video/webm" }); h.src = lc(Mia(l)); h.ontimeupdate = function() { c(); a.resolve(0) }; e.appendChild(h); h.classList.add("html5-main-video"); setTimeout(function() { e.classList.add("ad-interrupting") }, 200); setTimeout(function() { c(); a.resolve(1) }, 5E3); return m.return(a.promise) }) } That's the whole part, smb has several lines where it gets called. And this seems to be just lazy implementation instead of doing anything shady, I do similar things when using userscripts on a page where I put a setTimeout in a function that loops itself to check every X seconds whether a certain element is available on the page or not and then my script executes only if said element is available then does something and ends but it loops until the function can find the element.
To me this looks more like the lazy attempt of ensuring an ad is being displayed for at least 5 seconds until the actual video is going to load.
Why is it slow the first time someone loads and not every time? Simple, YT doesn't reload the page as we would expect it to reload, instead it prevents you from reloading the whole page but causes itself to reload the contents without reloading all of the scripts, which some websites do these days and I don't like it tbh as it will load faster but it's not an actual reload.
From what I see here, the code inserts a tiny static video (340 byte 1x1px), styles it like an ad presumably to make adblockers falsely block it, and then sees if the video plays (fires a timeUpdate event).
If it does, the function resolves with result 0.
If timeUpdate isnt fired within 5 seconds, the video probably failed to load which is likely due to an adblocker, and the function resolves with result 1.
If the video immediately plays successfully, the function resolves in much less than 5 seconds. The 5 seconds of delay should only occour if an Adblocker is present (or something else is preventing the video from loading/playing).
Since many people are reporting that this is gone after an account switch, it's likely on A/B testing currently. No evidence that this is exclusive to firefox here - since it's on A/B test, we would expect any browser/device change to reroll wether the check will get used or not, which would also explain the User Agent switcher resolving the issue.
И, внезапно, оказывается, что данное замедление является результатом борьбы не с другими браузерами, а с адблокерами (давайте вынесем за скобки разумность борьбы с адблокерами именно таким способом).
Но зачем "журналистам" во все это вникать? Ведь можно сразу состряпать громкий заголовок "YouTube seemingly intentionally slow loading on Firefox while Google Chrome works fine". Ну а читатели тоже не отстают и верят во все факты, подтверждающие их точку зрения, не проверяя эти самые "факты".
Честно говоря, не слышал, чтобы гугл занимался именно продвижением h264, тем более, что он всю дорогу разрабатывал открытые альтернативы - vp8, vp9. Поэтому мне было бы интересно увидеть источник данной информации.
Реализует "черновик стандарта", который нормально не специфицирован нигде
нет, стоп, стандарт это стандарт. Если он опубликован, пусть даже в виде черновика, кто мешает другим браузерам реализовать у себя этот стандарт?
которые гугл тут же дропнет, как только они перестанут выполнять свою "ограждающию" функцию
нельзя просто взять и дропнуть что-нибудь, пока не разработана альтернатива. Да, гугл в силу распостраненности своих сервисов может "диктовать" некоторые стандарты, но так как они не проприетарные, то другие движки так же могут их имплементировать. Другое дело, что они по своим причинам могут не захотеть это делать, но это уже их проблемы.
Как именно другие браузеры (хотя имеются в виду движки, скорее всего, а не браузеры) подстраиваются под Хром? Имплементируют новые веб-стандарты, разработанные в Хроме? Это вы называете "подстраиванием" или что-то другое?
Не нужно отвечать вопросом на вопрос. Дайте все-таки ответ - какой именно стандарт в Хроме, который активно используется веб-разработчиками, является проприетарным? Вы же это утверждали, а не про оптимизацию.
Старый софт (не адаптированный под hiDPI) действительно выглядит плохо при масштабировании. Но еще лет пять назад такого софта оставалось немного, а сегодня и тем более.
Минусы некратного масштабирования проявляются только до некоторого значения PPI. Выше такого значения блур становится незаметным из-за малого размера точки.
При 4К на 16" как раз такой размер точки, что блура уже не видно.
Простите, но высокое разрешение нужно вовсе не для того, чтобы использовать его в 100% масштабе. Оно нужно, чтобы не видеть отдельных пикселей. Это особенно важно при просмотре и редактировании изображений, а так же при работе с текстом (чтобы не отвлекаться на корявые шрифты).
Она очевидно ложная, потому что сетевой стек и оконечное оборудование давно обновлены под IPv6
сетевой стек - да, но ведь разве не проблемы с оконечным оборудованием тормозят провайдеров от перехода? Или какая причина? То, что админы провайдеров знают IPv4 и не знают IPv6? А разве им не придется учить, как работать с "IPv4+4"?
вам очень нужен новый 5к монитор Asus, пиксели стали ещё меньше
если вы лично не видите разницы между монитором с ppi ~100 и ppi ~200, то это не значит, что никто не видит. Да, представьте себе, существуют люди, которые видят отдельные пиксели на мониторе 24" 1080р, и поэтому предпочитают мониторы с большим ppi, где пикселей не видно.
картинка стала ещё более плавная 666 гц
зачем утрировать? Да, 666 Гц будет полезно может 0.1% покупателей (а именно про-геймерам), но разницу между 60Гц и 120Гц заметят почти все, и даже не в играх, а просто в интерфейсе ОС. 180 Гц, как в данном мониторе, будет заметно в шутерах для тех, кто в них играет. Да, это не 100% всего населения, но и монитор этот позиционируется как игровой, а не офисный.
проблему видят те провайдеры, которые раньше могли выдавать абонентам белый IPv4, а сейчас не могут. Они и переходят в первую очередь на IPv6. А остальные - ну что ж, пусть не спешат, их дело.
Мы ходим по кругу, как мне кажется. Чтобы к устройству нельзя было обратиться из интернета, существует файрвол на роутере. К тому же, пространство адресов IPv6 нельзя просто взять и полностью просканировать, значит, у злоумышленников поле для маневра сокращается.
Да, нельзя быть на 100% уверенным, что у всех пользователей включен файрвол и что хоть у кого-то из них не найдется уязвимость, но давайте решать проблемы по мере их возникновения. Некоторые провайдеры до сих пор выдают белые IPv4, большинство провайдеров еще 10-15 лет назад выдавали белые IPv4 (CGNAT сравнительно недавно получил массовое распространение) и переход на CGNAT произошел не потому, что провайдеры внезапно захотели "защитить" своих пользователей, а по причине нехватки белых IPv4.
вы h264 имеете в виду? Шутите что-ли? Гугл активно продвигал свои кодеки, а не h264. Конечно, поддержку h264 ему тоже пришлось оставить, потому что vp8/vp9 далеко не везде поддерживались софтом, особенно поначалу. "Гугл продвигал h264" - даже звучит смешно. Так продвигал, что многим юзерам приходилось ставить специальное расширение, чтобы ютуб выдавал видео именно в h264, а не vp8/vp9, которые у этих юзеров железо аппаратно не поддерживало.
я в курсе ситуации с Shadow DOM v0, да, можно сказать, гугл этим подставил браузеры, которые не захотели имплементировать у себя v0 стандарт. Но, с другой стороны, разве документация по нему была скрыта?
Я даже на 95% уверен, что в действиях работников гугла не было злого умысла - просто они настолько вдохновились черновиком стандарта, что построили свой фреймворк (Polymer) на нем, а потом сложно было сразу переделывать. Они это сделали, но позже, в следующих мажорных версиях.
вот это уже более интересные заявления, но, к сожалению, они не подкреплены фактами. Если гугл действительно умышленно ломал свои сервисы в чужих браузерах, его было бы легко поймать за руку, ведь это веб, исходный код доступен каждому.
Вот как раз вторая ваша ссылка и является такой попыткой поймать "корпорацию зла" на горячем. И даже на первый взгляд все выглядит страшно:
Но если перейти на реддит, откуда взята цитата, то в последующих сообщениях ситуацию можно увидеть в несколько ином контексте:
И, внезапно, оказывается, что данное замедление является результатом борьбы не с другими браузерами, а с адблокерами (давайте вынесем за скобки разумность борьбы с адблокерами именно таким способом).
Но зачем "журналистам" во все это вникать? Ведь можно сразу состряпать громкий заголовок "YouTube seemingly intentionally slow loading on Firefox while Google Chrome works fine". Ну а читатели тоже не отстают и верят во все факты, подтверждающие их точку зрения, не проверяя эти самые "факты".
Теперь расскажите, где я не прав?
Честно говоря, не слышал, чтобы гугл занимался именно продвижением h264, тем более, что он всю дорогу разрабатывал открытые альтернативы - vp8, vp9. Поэтому мне было бы интересно увидеть источник данной информации.
нет, стоп, стандарт это стандарт. Если он опубликован, пусть даже в виде черновика, кто мешает другим браузерам реализовать у себя этот стандарт?
нельзя просто взять и дропнуть что-нибудь, пока не разработана альтернатива. Да, гугл в силу распостраненности своих сервисов может "диктовать" некоторые стандарты, но так как они не проприетарные, то другие движки так же могут их имплементировать. Другое дело, что они по своим причинам могут не захотеть это делать, но это уже их проблемы.
Другие браузеры не могут кодировать видео? Или существует проприетарный гугловский кодек, который гугл не разрешает использовать в других браузерах?
Как именно другие браузеры (хотя имеются в виду движки, скорее всего, а не браузеры) подстраиваются под Хром? Имплементируют новые веб-стандарты, разработанные в Хроме? Это вы называете "подстраиванием" или что-то другое?
Не нужно отвечать вопросом на вопрос. Дайте все-таки ответ - какой именно стандарт в Хроме, который активно используется веб-разработчиками, является проприетарным? Вы же это утверждали, а не про оптимизацию.
То есть, в хроме реализован некий стандарт, который активно используется веб-разработчиками и при этом является проприетарным?
А можно узнать его название?
Старый софт (не адаптированный под hiDPI) действительно выглядит плохо при масштабировании. Но еще лет пять назад такого софта оставалось немного, а сегодня и тем более.
Минусы некратного масштабирования проявляются только до некоторого значения PPI. Выше такого значения блур становится незаметным из-за малого размера точки.
При 4К на 16" как раз такой размер точки, что блура уже не видно.
Если их не видите вы, это не значит, что никто не видит. На экране FullHD 16" пиксели вполне заметны невооруженным глазом. С обычного расстояния.
Это, конечно, зависит от того, какое расстояние от глаз до монитора, но в общем случае 140 PPI будет маловато. Хотя бы 180 нужно.
Простите, но высокое разрешение нужно вовсе не для того, чтобы использовать его в 100% масштабе. Оно нужно, чтобы не видеть отдельных пикселей. Это особенно важно при просмотре и редактировании изображений, а так же при работе с текстом (чтобы не отвлекаться на корявые шрифты).
сетевой стек - да, но ведь разве не проблемы с оконечным оборудованием тормозят провайдеров от перехода? Или какая причина? То, что админы провайдеров знают IPv4 и не знают IPv6? А разве им не придется учить, как работать с "IPv4+4"?
если вы лично не видите разницы между монитором с ppi ~100 и ppi ~200, то это не значит, что никто не видит. Да, представьте себе, существуют люди, которые видят отдельные пиксели на мониторе 24" 1080р, и поэтому предпочитают мониторы с большим ppi, где пикселей не видно.
зачем утрировать? Да, 666 Гц будет полезно может 0.1% покупателей (а именно про-геймерам), но разницу между 60Гц и 120Гц заметят почти все, и даже не в играх, а просто в интерфейсе ОС. 180 Гц, как в данном мониторе, будет заметно в шутерах для тех, кто в них играет. Да, это не 100% всего населения, но и монитор этот позиционируется как игровой, а не офисный.
Я не совсем понимаю, можете объяснить на пальцах, как можно было расширить IPv4 без обновления сетевого стека ОС и оконечного оборудования?
Вот, кстати, еще на эту тему: с таймстампом
Расшифровка, если не хочется смотреть видео:
Скрытый текст
ну как бы не совсем не знаем: https://www.google.com/intl/en/ipv6/statistics.html
Уже практически 50% глобально. Путь небыстрый, но стабильный.
проблему видят те провайдеры, которые раньше могли выдавать абонентам белый IPv4, а сейчас не могут. Они и переходят в первую очередь на IPv6. А остальные - ну что ж, пусть не спешат, их дело.
не "никому не нужные", а не нужные лично вам. Не надо говорить за всех.
Мы ходим по кругу, как мне кажется. Чтобы к устройству нельзя было обратиться из интернета, существует файрвол на роутере. К тому же, пространство адресов IPv6 нельзя просто взять и полностью просканировать, значит, у злоумышленников поле для маневра сокращается.
Да, нельзя быть на 100% уверенным, что у всех пользователей включен файрвол и что хоть у кого-то из них не найдется уязвимость, но давайте решать проблемы по мере их возникновения. Некоторые провайдеры до сих пор выдают белые IPv4, большинство провайдеров еще 10-15 лет назад выдавали белые IPv4 (CGNAT сравнительно недавно получил массовое распространение) и переход на CGNAT произошел не потому, что провайдеры внезапно захотели "защитить" своих пользователей, а по причине нехватки белых IPv4.
Поэтому я не до конца понимаю вашу позицию.