Ваш браузер больше работать не будете

Ликбез по браузерам для Windows в 2020

Доброго времени суток, Хабр! В очередной раз читая комментарии, наткнулся на мысль о том, что далеко не все понимают, как обстоит ситуация с браузерами для Windows на данный момент. От чего хотелось бы провести небольшой обзор текущего положения. Ну, и сразу к делу!

Браузерные движки

Браузер — программа не простая, это целый набор компонентов, взаимодействующих между собой. Для краткого обзора потребуются всего два компонента из множества — движок отрисовки содержимого и движок исполнения JavaScript.

Существующие движки отрисовки содержимого

Существующие движки исполнения JavaScript

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

Браузеры

Chromium

Chromium — это open-source ответвление браузера Chrome. Браузеры на основе Chromium составляют большую часть из всех используемых браузеров на планете Земля.

Обычно, браузеры на базе Chromium между собой отличаются только визуально, ведь у всех под капотом движки Blink и V8, хотя, какие-то компании пытаются привнести больше функционала в браузер, чем имеется.

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

Всех браузеров на основе Chromium подсчитать одному человеку вряд ли под силу, поэтому приведу список только тех, что помню:

• Chrome — в представлении не нуждается, браузер от Google;
• Chr Edge — новый браузер от Microsoft со старым названием. Поговаривают, отличается большей производительностью от Chrome. С некоторых пор предустанавливается в систему;
• Brave — браузер с повышенной безопасностью настолько, что приватный режим использует Tor;
• Яндекс.Браузер, Opera, Vivaldi, тысячи их.

Firefox

Firefox использует движки Gecko и SpiderMonkey для своей работы. Имеет небольшое количество базирующихся на Firefox браузеров, но самый известный — Tor Browser. Является единственным рубежом до полного перехода интернета на браузеры на основе Chromium.

Internet Explorer

Это любимая всеми утилита для скачивания браузеров. Как и Chrome — не нуждается в представлении. До 11 версии использовал движки Trident и Chakra JScript. В 11 версии, за исключением режима совместимости, стал использовать движки Trident и Chakra JavaScript. Этот браузер ещё долго будет использоваться для всякого рода систем видеонаблюдения, поскольку имеет, почему-то, популярный в узких кругах API для расширений. В Windows 8 и Windows 8.1 имел особую модификацию движка Trident на базе WinRT для Metro режима.

(Legacy) Edge

Браузер, начавший своё существование с кодовым названием Project Spartan, являлся новым браузером от Microsoft в 2015 году, использующим движки EdgeHTML и Chakra JavaScript. Конечной целью проекта была полная совместимость с сайтами, отлично работающими в Chrome. В итоге — получилось нечто своеобразное, но, очевидно, не выжившее под давлением Google.

Safari

Safari? А нет его больше, этого вашего Safari, кончился.

Нецелевое использование браузеров

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

• П р ограммистов на JS нечем занять;
• На JS+HTML новичкам проще программировать;
• Кроссплатформенность;
• Требуется возможность отображать веб-страницы.

Приведу примеры подобного использования:

Chromium

Нынешние браузеры настолько сложны, что одному человеку создать собственный браузер не под силу (либо это должен быть гений). Они по сложности сравнимы с операционными системами! А, постойте, вот и первый кандидат на нецелевое использование — Chrome OS. Да, весь пользовательский интерфейс — просто модифицированный Chromium.
Однако, помимо этого, в виде CEF (Chromium Embedded Framework), Chromium используется в:

• Игровые платформы: Steam, Epic Games Store, Battle.Net и другие;
• Игры: GTA V, все игры от Blizzard, DOTA 2, CS GO и множество других;
• Редакторы кода: Atom, VS Code, Visual Studio Installer(. );
• Программы для общения: Skype, Viber, WhatsApp, Discord, Slack и множество других;
• Другие программы: balenaEtcher, draw.io и великое множество других.

Internet Explorer

Почти любое Win32 приложение, умеющее отображать WEB-страницы и при этом в распакованном виде занимающее меньше 60 мегабайт использует внутри Internet Explorer. Кстати, это касается не только маленьких по размеру приложений, например, Visual Studio использует Internet Explorer для отображения WEB-страниц, когда это требуется в работе IDE. Ещё существуют HTA приложения — древний предшественник CEF на базе Internet Explorer. И ведь до сих пор работает.

(Legacy) Edge

Новым приложениям — новые движки! Любое UWP приложение, использующее внутри отображение WEB-страниц работает на базе Edge. Не то, чтобы Microsoft запрещали использовать что-то другое, но никто просто и не старался. Так же, пока что, в предварительных сборках Windows новая клавиатура с GIF панелью тоже использует Edge для рендеринга. В будущих версиях, полагаю, перейдут на Chr Edge.

Производительность

Постойте, столько приложений, а что там с производительностью? Лично я — не специалист в оценке производительности, но хочу поделится с вами некоторыми занимательными фактами.

Prefetcher

В Windows есть такая штука — Prefetcher. Она занимается подгрузкой программ в ОЗУ при старте ОС и на протяжении её работы. Штука эта достаточно умная, и она анализирует чаще всего запускаемые программы, чтобы в дальнейшем их подгружать.

Как это связано с браузерами? Идея в том, что это может смазать первый пользовательский опыт с другим браузером, например, пользуясь постоянно Chrome, имеете установленную версию Firefox. При запуске Firefox будет вести себя крайне медленно — медленнее, чем ваш основной браузер. Всё потому что он запылился в глазах Prefetcher. В конечном итоге всё будет работать быстро, но первое впечатление после долгого неиспользования будет ужасным. Особенно это касается пользователей с HDD или малым количеством ОЗУ.

Области распределённой памяти

Да, звучит не очень. Но суть, в данном случае, простая — если одна единица исполняемого кода требуется к исполнению больше одного раза, будь то exe или dll , то в память она загрузится лишь один раз. Поясню: если два различных приложения в ходе своей работы загрузят одну и ту же библиотеку, например, edgehtml.dll , то этот файл будет загружен в ОЗУ компьютера на самом деле только один раз, хотя, казалось бы, потребуется два или больше раз. Таким образом ОС экономит нам оперативную память.

Движки нормального человека

К чему это я? А вот дело в том, что в отличии от других браузеров, Internet Explorer и (Legacy) Edge предустановлены в систему, а их движки хранятся в папке System32 . Это, вкупе с API для разработки приложений, означает, что все приложения в системе, использующие данные движки будут загружать их в память только однажды. И этот принцип распространяется на все приложения.

У людей часто возникают проблемы с UWP приложениями, а точнее — с их скоростью запуска. Всё дело в WinRT — огромном наборе библиотек, при помощи которых UWP приложение взаимодействует с ОС. Если не использовать UWP приложения часто, то этот набор библиотек не будет прогружен в памяти полностью, и придётся ожидать окончания этого процесса перед использованием приложения. Но забавный факт — используя два и более UWP приложения время их старта и общая производительность резко увеличиваются и часто даже превосходят Win32 программы. Исключением из этого является приложение «Фотографии» — тут отдельная история, покрытая туманом.

Движки курильщика

А вот с приложениями (в том числе и браузерами) на основе Chromium это так не работает. Каждое приложение комплектует с собой собственную сборку библиотеки CEF, что, кроме раздувания размера приложения, не позволяет операционной системе иметь только одну копию dll в ОЗУ. Итого это сильно замедляет производительность при использовании множества подобных приложений. Помимо того, сам размер CEF довольно удручающий.

Microsoft Store

У многих возникает вопрос — почему в Microsoft Store нет ни одного браузера(не считая нескольких кривых поделок на EdgeHTML)? Ответ, на самом деле, прост — все браузеры, включая Chr Edge имеют собственную систему обновления, что прямо запрещено правилами Microsoft Store. В остальном никто никого не ограничивает.

Как удалить новый Microsoft Edge

Это не очень сложно. Для начала требуется найти папку с Microsoft Edge, она расположена по пути:
C:\Program Files (x86)\Microsoft\Edge\Application
Далее заходим в любую версию Edge и переходим в папку Installer . Полный путь может выглядеть следующим образом:
C:\Program Files (x86)\Microsoft\Edge\Application\83.0.478.58\Installer
Далее необходимо открыть командную строку от имени администратора в данной папке и выполнить следующую команду:
setup.exe —uninstall —system-level —verbose-logging —force-uninstall
Готово! Через несколько секунд этот браузер исчезнет из системы. Но при следующем же обновлении он появится снова, будте бдительны.

Заключение

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

Администраторы Хабра, пожалуйста, почините HabraStorage в Legacy Edge! Совсем не дело.

Источник

Рейтинг самых безопасных браузеров 2021 года

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

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

Мы будем рассматривать это как навязчивое поведение и нарушающую конфиденциальность бизнес-модель. Такое поведение можно также увидеть во многих поисковых системах и сервисах электронной почты.

Если не настроить их как нужно, большинство браузеров содержат много информации, которую могут получить посторонние.

• История браузера содержит адреса всех посещённых вами веб-страниц.
• Данные на вход содержат логины и пароли от ваших учётных записей.
• Куки и трекеры помещаются на ваше устройство сайтами, на которые вы заходили.
• Информация автозаполнения содержит имена, адреса, номера телефонов и другие сведения.

Как будет сказано ниже, использование режимов «Инкогнито» и приватного просмотра в браузере не защитит вас. IP-адрес по-прежнему будет виден сайтам и различные сторонние сервисы смогут отслеживать вашу активность. Недавно появилась новость о том, что на Google подали в суд за отслеживание в режиме «Инкогнито».

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

Пусть всё это вас не пугает. Существуют эффективные методы и инструменты защиты, о которых будет рассказано в этой статье. Вот о чём именно пойдёт речь:

• Лучшие защищённые браузеры с акцентом на конфиденциальность.
• Проблемы других браузеров.
• Разделение браузеров для конфиденциальности.
• Расширения защищённых браузеров.
• Режим приватного просмотра не очень приватный и почему вам нужен VPN.

Примечание: когда в браузере используются режимы приватного просмотра и «Инкогнито», ваш реальный IP-адрес и местоположение видны каждому сайту, рекламе и трекеру, которые загружаются в браузер. Лучший способ добиться настоящей конфиденциальности состоит в сокрытии IP-адреса и местоположения при помощи сервиса VPN вместе с хорошим защищённым браузером. Ниже даны рекомендации по выбору лучшего VPN:

• NordVPN. Быстрый, защищённый и проверенный сервис VPN с продвинутыми функциями конфиденциальности и строгой политикой отсутствия логов, который размещается в Панаме.
• Surfshark VPN. VPN без логов с большим набором функций конфиденциальности и безопасности, который располагается на Британских Виргинских Островах.

Источник

Как стать свободным от «цепей» старых браузеров

Люди не готовы отказываться от старых друзей, старых традиций и старых-добрых предпочтений. А еще некоторые из них привыкли к устаревшим версиям браузеров, а современное ПО устанавливать отказываются. О том, что делать, если вы стали заложником старых браузеров, рассказал в своем докладе на конференции «Frontend Conf» руководитель направления разработки ДомКлик Денис Красновский.

Знакомьтесь: это Slowking, Slowpoke, Slowbro и Slow web.

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

• Насколько хорошо оптимизировано ваше приложение;
• Современный ли у него гаджет, например, телефон;
• Приемлема ли скорость соединения с интернетом.

Кто-то скажет: «ОК, вижу белый экран: сейчас загрузится! Все бывает. Игры тоже долго грузятся, но люди ведь от этого не перестают в них играть». Но для бизнеса важно, чтобы ваш проект хорошо индексировался. Google отдает предпочтение оптимизированным сайтам: тем, кто постарался сделать mobile-friendly приложение, и у кого оно быстро грузится.

Хочу условиться о том, что под приложением в этой статье всегда имеется в виду Web, то есть неважно – это просто лэндинг или Rich JavaScript Application.

Представим банальную ситуацию: у нас гипотетический онлайн-кинотеатр, и есть конкуренты, опять же гипотетические. Важно, чтобы решив посмотреть «Игру престолов», потенциальные зрители в поиске нашли первым именно наш кинотеатр, и кликнули на него. Но и это только половина победы.

Проблема SEO заключается в том, что если вас нет на первой странице выдачи, скорее всего, в интернете вас не существует вовсе. Потому что пользователи не ходят дальше первой страницы. Более того, первые три варианта обычно закрывают все потребности. К тем приложениям, которые находятся в первых рядах первой страницы, люди подсознательно проявляют доверие, ведь «Google фигни не посоветует».

SEO – это первый шаг, второй – впечатления пользователей.

User experience

Даже если вы находитесь на хорошем месте в выдаче поисковика — это еще не все. Нужно поработать над user experience. Именно в этот момент белый экран, особенно если он грузится довольно долго, начинает напрягать. Долгая загрузка связана, скорее всего, с большим количеством статики. Под статикой подразумеваются js, css, svg, png — в общем, все, что мы собираем для нашего приложения.

Помимо того, что мы заставляем пользователя выкачивать очень большой объем данных, мы перегреваем телефоны и разряжаем их батареи. Может быть, во время серфинга по сети на своем мобильном, вы замечали, что он очень сильно разогревается, руки потеют, а экран весь заляпывается. Если дошло до этого, приложением пользоваться уже не хочется.

Существует метрика Retention, в которой можно увидеть количество пользователей, которое вы смогли удержать после того, как они воспользовались вашим приложением. Например, я посмотрел первую серию «Игры престолов», и у меня негативный опыт: все грузится слишком долго, постоянно появляются какие-то проблемы. Скорее всего, я уйду к конкурентам. Возможно, именно они предоставят мне то, что я не получил с первым результатом в выдаче.

Третий шаг для нас, как для инженеров, тоже очень важный: речь идет о качестве продукта.

Все мы привыкли пользоваться stylelint, ESLint, которые проверяют наши js и css. Но почему бы нам не взять за основу Lighthouse?

Sonar, ESLint, Stylelint проверяют наш код на наличие ошибок, а мы смотрим, что получится в итоге, с точки зрения конечного пользователя. Lighthouse расскажет, где мы ошиблись и предложит варианты для оптимизации, чтобы улучшить наши показатели среди всех других приложений и сайтов.

Я хочу рассказать о том, как стать свободным от «цепей» старых браузеров. Давайте рассмотрим историю о взлетах и падениях. Все персонажи вымышлены, все совпадения — случайны.

This is how we do

Как-то раз ко мне обратились с предложением: «Давайте вы сделаете офигенное приложение: быстро, качественно, а еще у него должен быть хороший перфоманс». Нужно было делать Single Page Application, что подразумевало борьбу за прорисовку.

Для себя мы определили паттерны, по которым работать:

• Не оверхедить. Оверхед – это когда люди вместо того, чтобы написать простой кусочек кода, начинают изобретать ракету. Зачем? Если задать этот вопрос напрямую, услышите что-то подобное: «В будущем нам, возможно, это понадобится!». Этого будущего для уже написанного куска кода может и не быть. Не исключена и вероятность того, что через день его удалят из кодовой базы. Мы оставляли только то, что нужно здесь и сейчас, и что несет реальный профит для проекта. Меньше кода – меньше багов, а еще это значит, что будет меньше вес бандла и лучше перфоманс.

• Избегать лишних библиотек. Мы не допускали наличия библиотек, которые не несут в себе ощутимой пользы.

• Не использовать общие компоненты, не закрепленные за командой. Возможно, эта тема больная для многих из вас. На моей памяти не было ни одного сета общих компонентов, которым были бы довольны все.

• Оптимизировать ресурсы. Следующий логичный шаг – оптимизировать ресурсы: js, css, html, картинки и прочее. Мы делаем это с помощью Webpack, OptimizeCSS Plugin, UglifyJS, Tercer, HTMLWebpack Plugin.

• Настроить code splitting. Например, code splitting в Webpack можно получить с помощью dynamic import в две строчки.

• Оптимизировать доставку ресурсов. После dynamic imports логичным является либо prefetch, либо preload данных, которые объявляются ровно в том же месте, где dynamic imports, с помощью магических комментариев для Webpack. Там же вы можете указать приоритет ресурса: как быстро нужно его начинать скачивать. После того, как у нас все скачалось, с помощью prefetch мы можем подтянуть остальное. Пользователь этого не заметит. Но после того, как он нажмет кнопку «Залогиниться», его перебросит на другую страницу, и все его ресурсы останутся в кэше. То же самое можно провернуть с данными. Но основной месседж в том, что интерфейс не доставляет пользователю никаких неудобств.

• Кэшировать и сжимать статику (например использовать gzip).

Вес css + js, без gzip

Используя вышеописанные паттерны, мы сделали приложение, богатое на функциональность и js.
Вот те зависимости, с которыми мы решились работать:

Этот момент показателен. Если мы заходим на страницу с 8 КБ, зачем тащить туда все остальное? Дайте эти 8 КБ пользователю, и пусть у него все рисуется.

Диагностика

Мы сделали приложение, оно работает. Как проверить перфоманс?

• Lighthouse. Им можно воспользоваться в Chrome DevTools и в Tabaudit. Также вы можете подключить CLI, и поработать с ней.

• PageSpeed Insights. Там можно увидеть немного другой интерфейс, чем в Lighthouse.

• Внутренние ощущения (я серьезно!).

Мы часто говорим о том, что нужно помогать людям, у которых слабые телефоны и интернет. Но что делать, когда мы пропустили тот момент, когда наши приложения стали весить как игры ААА класса. Изюминка нашего приложения в том, что нам нужно было построить его, не завязываясь на старые браузеры. Мы хотели обеспечить наших пользователей наилучшим experience. Но с приходом больших денег и пользователей приходит и большая ответственность.

Браузеры кричат, как в фильме: «Somebody, please, get this browser a polyfill!».

Нас просили поддержать не только IE, но и Chrome v35 и Safari v10. Казалось бы, в чем проблема? Поддержали, добавили пару строчек кода — и все хорошо! Но дело в том, что мы уже дали пользователю почувствовать, что приложение летает. Это как будто вы посадили в ресторане клиента за столик у окошка на 86 этаже, и у него дух захватило от открывшегося перед ним вида. А через пять минут подошли к нему и предложили пересесть к туалету. Мы не хотели допустить такого эффекта, поэтому начали искать варианты работы со старыми браузерами.

Варианты работы со старыми браузерами

Рецепт

На самом деле идея проста. Для ее воплощения, нам нужны:

• package.json. Это своего рода интерфейс для работы человека с приложением, или — в случае, если речь идет о пакете — приложения с приложением.
• home made script. Немного скриптов.
• webpack. Модуль бандлер, который поможет собрать наш js, css, svg.
• babel. Он транспайлит код нового стандарта в тот код, который понимают более старые браузеры.
• browserslist. Необходим для того, чтобы указать, для каких браузеров мы что-то собираем.
• nginx. Это последний шаг — вишенка на торте хайпа. Еще полтора года назад я сам считал, что это не мое. Но — к счастью, или к сожалению — жизнь все-таки привела меня к nginx. Он будет нам нужен для того, чтобы финально решать, какие файлы и какому пользователю нужно отдать.

package.json

Во всем package.json нас сейчас интересуют три строчки:

Первые две строки — инструкция к сборке. Ключевой особенностью является указатель переменной окружения TARGET=old и TARGET=modern. Эту переменную мы будем использовать далее.

Важный нюанс: на третьей строчке мы сначала должны почистить папку, в которую все складываем. Во-первых, это просто хороший тон. А во-вторых, если не чистить папку, в которую складываете результаты билда, с большой долей вероятности на прод уедет что-то не то.

Еще один важный нюанс, о котором иногда забывают: && — это последовательное выполнение, а & — параллельное выполнение. Нам не нужно ждать, пока у нас билдится modern билд, мы запускаем их параллельно.

target.js

Нам нужно написать совсем немного скриптов.

Что здесь происходит? Мы преследуем единственную цель: собрать статику с хорошими браузерами в отдельную папку, а все остальные, кроме «мертвых» (больше 1%) — в другую папку. Это своего рода сервис. Мы объявляем полифилы, которые нам понадобятся. Переменную окружения используем для того, чтобы вернуть отсюда именно тот конфиг, который нужен Webpack и Babel.

webpack.prod.js

Все, что нам нужно сделать в Webpack, это прокинуть полифилы:

Потом перейдем в Babel.config.js:

Babel преобразует наш офигенный код в более старый, который не нравится нам, но нравится браузерам. При работе с Babel и при поддержке старых браузеров, нам необходим babel-polyfill.

Это мощная машина, которая много весит. В этот момент мы тоже указываем таргеты.

Babel-polyfill используется с параметром useBuiltIns с флагами:

• ‘entry’ => 384 KB;

Этот подход рекомендуют все гайды. Но нужно учесть, что вы обязаны заимпортить его в индексовый файл, или объявить в entry Webpack.

Итого, из исходных 294 КБ они превращаются в 384 КБ кода.

Я выбираю другой вариант.

• ‘usage’ => 334 KB.

При таком подходе ваш вендор ужимается до 334 КБ, и вы не ставите babel-polyfill в зависимости. Файлики, в которых что-то используется, вырастут примерно на килобайт.

Путем нехитрых манипуляций мы получили две сборки:

Я упоминаю Internet Explorer, поскольку для меня он является олицетворением старых браузеров.
Это разница:

1 KB – наверное, мы не такие изощренные верстальщики;
js

69 KB – годная тема.

Во фронтенде — по крайней мере у нас — принято биться за каждый килобайт.

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

У меня лапки

Иногда в браузере можно увидеть ‘last 2 versions’. Это означает, что вы решили поддерживать две версии всех браузеров, даже мертвых.

Добавьте useBuiltIns: ‘entry’, и разница между хорошим билдом и том, о котором мы сейчас говорим, будет составлять:

25 KB (в префиксе для мертвых браузеров);
js

117 KB.

И не нужно забывать о том, что эти цифры для разных случаев будут разными.

nginx split

Вишенка на торте хайпа, о которой я говорил.

Мы находимся в nginx и будем использовать директиву map, локальную переменную http_user_agent. Кроме того, объявили переменную template. В нее запишем название индексового файла, который будем отдавать пользователю.

Важный момент: мы получаем user_agent на regex. И если user_agent с версией Chrome от 0 до 74, то мы отдаем old индекс. Для всех остальных современных браузеров отдаем modern-индекс.
listen 5050 означает то, что при запуске nginx, вы зайдете на local host 5050, и он начнет следовать инструкциям, которые вы написали, и раздавать то, что вы хотите. В данном случае (строчка root) мы говорим, что по такому-то пути на компьютере рнаходится папка dist (это папка в проекте), и туда нужно отдатьпеременную template. Это либо old индекс, либо modern индекс.

Теперь смотрим, что произошло:

Chrome v74

Про v74 мы условно сказали, что это старый Chrome. Здесь есть строчка, которая заматчилась — значит, все работает.

Chrome Canary v76

Работает надежно, как швейцарские часы. Но фронтенд в целом надежен как швейцарские часы (в отличие от бэкенда).

Как выглядит реальный файл?

Real world nginx map

Он выглядит следующим образом:

В данном случае мы уже объявили переменную. Для чего мы это сделали и почему не объявили ее выше, что казалось бы логичным ходом? В nginx нельзя объявить переменную выше, чем скоуп сервер. Интересно, что нельзя сделать директиву map на скоуп сервер. Поэтому код выглядит немного странновато, но он работает.

Для чего мы написали здесь столько переменных? Если вы какой-то причине решите переименовать файлик и допустите ошибку, nginx не будет на это ругаться. Однако если здесь будет не переменная, пользователям в разбросе Chrome 0-9 будет отдаваться не то, что они хотят. И вы, как человек, у которого есть самая последняя топовая машина и самый последний топовый браузер, никогда об этом не узнаете. Насколько быстро всплывет эта ошибка, неизвестно. Почему это происходит большинство разработчиков так и не поймут. Поэтому в данном случае лучше делать все через переменные.

Наверное, вы знаете, что есть сервисы Polyfill.io, и существует вариант проверять на клиенте, работает ли тот или иной метод, и, в зависимости от полученных данных, собирать статику. Скажу сразу: этот вариант рассматривать не стоит. Почему?

Вы объявляете Polyfill.io render-blocking скриптом, потому что не можете загружать свои скрипты дальше, ведь иначе JavaScript не станет работать. Поэтому мы сначала скачиваем html, видим Polyfill.io, идем в него, и он уже решает, что нам нужно. При таком подходе о перформансе можно забыть.

По той же причине не работает проверка, есть ли метод. Вы просто создаете дополнительные round-trip’ы, которые замедляют прорисовку.

Лучше всего пойти легким путем, о котором я рассказал. У человека, который знает Webpack и Babel, создать сплит между старым и новым браузером получится за два-три часа. А если он с ними не знаком и времени потребуется больше, это все равно стоит того.

Как говорил Альтрон:

«Я покажу вам нечто прекрасное ( у нас это web, тонущий в мегабайтах JavaScript).
Вы хотите перформанс, но не готовы к эволюции, а я свободен ото всех цепей».

Источник