Как системно ускорить браузеры? Часть 1

Чем больше я наблюдаю за новыми и имеющимися браузерами тем больше понимаю что им остро нехватает системных решений в части их ускорения.

В принципе, нужны другие подходы, а не просто прокачка движков рендеринга и тому подобное.

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

Итак:

1. Кеширование типовых библиотек Javascript внутри браузера

Предположим что есть набор типовых библиотек которыми активно пользуются веб-мастера. Библиотек много, но есть наиболее популярные — jQuery, SWFObject, Prototype и так далее. Их не бесконечное количество, а вот используют их очень даже активно при этом браузеры их качают и качают, интерпретируют и интерпретируют, в общем делают много бессмысленной работы.

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

Примеры таких библиотек:

— Яндекс — http://api.yandex.ru/jslibs/

— Google — https://developers.google.com/speed/libraries/

— Microsoft- http://www.asp.net/ajaxlibrary/cdn.ashx

 

Но, у меня возникает резонный вопрос — отчего не в самом браузере? В самом деле — если есть стандартные библиотеки, если они часто используются, если за сутки веб-серфинга браузер скачивает их хотя бы однократно, то отчего же не загрузить их все прямо в браузер с самого начала.

 

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

Причем сделать так чтобы разработчики библиотек могли бы предлагать свои библиотеки для такого стандартного пакета.

 

Вот и получаем ускорение на том что:

a) Библиотеки более не скачиваются из сети.

б) Те что есть в стандартных библиотеках уже загружены в память и их не надо дополнительно интерпретировать.

 

Понятно что не все будет идеально, но ведь направление то понятное.

2. Проактивное кэширование всех DNS запросов

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

Скажите что такая история тоже уже есть — кеширующие DNS сервера. Запросы отправляются не куда-то а им и они максимально оперативно отвечают.

А вот и не совсем так. Есть путь который позволит избавиться от значительного числа обращений к кеширующим серверам — очень простой и понятный путь. Сервера должны обращаться к пользователю. Проактивное кеширование должно находится не в браузере, а в кеширующем DNS сервере. Он должен push-ать в клиента ранее разрезолвенные имена на регулярной основе. Раз в 3-4 часа обязательно и в фоновом режиме.

При этом список отресолвенных dns адресов может формироваться несколькими способами. Самый простой — это пушать 5000 наиболее популярных доменных адресов диффами. Второй способ — это индивидуальный поведенческий подбор адресов на основе накапливаемых запросов от клиента. Если видно что каждый день пользователь обращается к одному и тому же доменному адресу, то для него можно составить индивидуализированный список.

 

А попозже и все остальные идеи напишу.

About This Author

  • http://www.facebook.com/kalloc Nikita Kuznetsov

    1. чем вариант с централизованным хостингом библиотек будет лучше встроенных?

    2. как вы сами заметили, DNS использует UDP как транспорт (в основном UDP), это означает, что клиент не может быть уверенным в идентичности отправителя.

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

    Механизмы локального кэширования DNS записей давно реализованы и поддерживаются большинством платформ

    Основную нагрузку (в случае работающего DNS prefetching) идет на установку соединения. Например, в случае с SSL это может быть по времени больше чем само получение контента. (http://cl.ly/image/0F0N3q2O1S3q)

    По поводу подписки на «дифы» — по каким критериям он будет идентифицировать пользователя?

    • http://ivan.begtin.name Ivan Begtin

      1. Тем что обращение будет в память компьютера, а не в сеть.

      2. Вообще-то совершенно необязательно реализовывать описанный мной механизм именно через DNS протокол и UDP. Можно хоть свой протокол сделать, можно поверх SPDY или как-либо иначе.

      • http://www.facebook.com/kalloc Nikita Kuznetsov

        1. в случае с кэшированием время доступа будет минимально.
        В вашем же случае дополнительно создаст проблему с обновлениями.

        2. не надо такое делать, это не очень правильно, правильно нормальный локальный DNS

      • http://www.facebook.com/kalloc Nikita Kuznetsov

        1. в случае с кэшированием время доступа будет минимально.
        В вашем же случае дополнительно создаст проблему с обновлениями.

        2. не надо такое делать, это не очень правильно, правильно нормальный локальный DNS

      • http://www.facebook.com/kalloc Nikita Kuznetsov

        p.s. лучше принять WebCrypto API :)

  • http://www.facebook.com/oldayn Eugene Barbashin

    Пункт 1 хорош, основная проблема в механизме обновления встроенных библиотек, но если это аккуратно сделают те компании, которые уже сейчас у себя держат зеркала, то должно получиться нормально.
    Пункт 2 в таком виде маловероятен, слишком сильные нужны нововведения на DNS серверах, а это штука консервативная, да и подобный push от DNS сервера к клиенту плохо укладывается в идеологию современных IPv4 сетей, где почти везде есть NAT. Так что скорее в этом направлении можно двигаться двумя путями:
    2.1. Дополнить функциональность бразуеров, чтобы они по сути взяли часть функций резолвера на себя, анализируя параметры зон и запрашивая после запуска сайты, часто посещаемые пользователем. На самом деле, спорный путь, потому что многие «сидят» на одних и тех же сайтах и выигрыш от такой функции будет не так уж велик, а «новые» сайты предугадать всё равно сложно.
    2.2. Реализовать расширение протокола DNS, позволяющее объединять несколько запросов в один большой, своего рода пакет. Это позволило бы уменьшить накладные расходы при запуске браузера, открытии страницы на которой много элементов с разных доменов и т.п.. При этом направление взаимодействия остаётся прежним, обратная совместимость легко обеспечивается, возможности оптимизации для авторов браузеров появляются.

    • http://ivan.begtin.name Ivan Begtin

      По второму пункту все будет реальнее если не закладываться на DNS протокол, и делать параллельный механизм push’а в локальные ресолверы. Есть же практика установки локальных кеширующих серверов — вот и тут также.

  • http://www.facebook.com/kalloc Nikita Kuznetsov

    Вот пример реального ускорения web-a — http://blog.cloudflare.com/cacheing-the-uncacheable-cloudflares-railgun-73454

  • http://www.facebook.com/kalloc Nikita Kuznetsov
Яндекс.Метрика