Оптимизируем загрузку библиотеки ExtJS до двух запросов

    Я хочу поделиться решением, которое я использую для оптимизации загрузки админки, разработанной с использованием библиотеки ExtJS. Это решение применимо не только непосредственно к ExtJS, но для данной библиотеки, это очень актуально. Заранее предупреждаю, что решение очень плохо, если почти никак, работает с семейством 60- и 70-летних интернет стариков-эксплореров.

    Проблема:


    Почти первое, что сразу отпугивает большинство разработчиков и заказчиков, перед тем как приступить к разработке на extjs — «блин, да это же почти мегабайт жаваскрипта!?!». По сути так оно и есть, а если включить в список для загрузки файлы css стилей и картинки, то можно получить и все полтора-два. Приправим блюдо плагинами, что неизбежно, ведь в этом и есть плюс extjs — мощные плагины, то на закуску прилагается много скриптиков, каждый требующий запрос к серверу.

    В итоге, каждый заход на страницу админки требует, что-бы клиент (получил бесплатные четки) загрузил все скрипты и скриптики и оформление. Это, плачевно влияет на скорость подьема страницы в браузере. А от пользователя требует дополнительного терпения, что никак не добавляет плюсов в карму разработчика.

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


    Решение:


    1. Объединить множество файлов в один.

    Формируем список файлов которые необходимы для полноценной работы и объединяем файлы библиотек, плагинов и хелперов в один большой жаваскрипт файл. То же самое делаем и для стилей, и тоже формируем из них один файл. Это уменьшит количество запросов со стороны клиента к серверу, но недостаточно.

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

    2. Вставка картинок в файл стилей.

    Использование Data SRC URI (http://en.wikipedia.org/wiki/Data_URI_scheme), позволяет вставить содержимое изображения непосредственно в файл стилей. Это хорошо работает почти во всех браузерах, за исключением 6/7 интернет эксплореров, а в 8 эксплорере есть ограничение на размер данных. Мне повезло, я не такой как все, мой клиент забил на IE. Выгода от этого решения в том, что клиент получает все картинки стиля одномоментно и в процессе рендеринга не наблюдает, как постепенно то одна, то другая часть визуальных компонентов «обрастает» оформлением. А также никаких лишних запросов к серверу.

    Вот так выглядит data uri в css (взято из wiki):
    ul.checklist > li.complete { margin-left: 20px; background:
    url('data:image/png;base64,
    iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD/
    //+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4U
    g9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC')
    top left no-repeat; }


    А еще это хорошая тема для холивара замена css sprites, в том плане, что тоже все-в-одном, но при этом, нет ограничений как у спрайта на цвета (если это gif) или использование в качестве фона картинки с repeat стилем. К примеру, в ExtJS (2.0) картинка чекбокса это спрайт, со всеми состояниями чекбоксов. При попытке сделать в гриде, колонку с чекбоксами, у которой чекбокс будет в заголовке, а при этом в заголовке будет надпись, то спрайт покажет свою истинную натуру, заполонив фон вдоль этой надписи. Когда я разделил картинку из спрайта на составлящие, то эта проблема исчезла.

    3. Компрессия.

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

    Пример использования с yuicompressor

    java -jar yuicompressor.jar --type js extjs.js
    java -jar yuicompressor.jar --type css extjs.css


    Эта компрессия хороша, но недостаточна. Ошеломительный эффект дает apache с использованием mod_deflate.

    Результаты у меня примерно такие:
    После склейки: js — 1000kb, css — 1000kb (да да, много картинок в base64 ).
    После компрессии: js — 800kb, css — 700kb.
    После mod_deflate, это то что скачивает клиент: js — 170kb, css — 200kb.

    Как видно, размер файлов все еще большой, но зато есть уверенность, что клиент получит полностью все extjs окружение в два запроса: один для жаваскрипта, а второй для стилей.

    4. Кэширование и срок годности.

    Решение самое тривиальное, настроить на apache mod_expires для этих двух файлов, что-бы клиент загрузив их однажды, не скачивал заново, тогда размер в 500kb для скачивания не будет так ощутим. А для принудительной инвалидации будем использовать timestamp (типа ext.1249090480.js) в имени файла. При новом деплойменте, просто меняется номер файла и клиент скачивает новую версию при следующем заходе на админку.

    link rel="stylesheet" type="text/css" href="extjs.1245678910.css"
    script type="text/javascript" src="extjs.1245678910.js"


    Для автоматизации, я написал скрипт который выполняет пункты с 1 по 3.
    Опубликован на форуме ExtJS и на Pastebin.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 9

      0
      Нам, в деле загрузки ExtJS, со всеми нашими расширениями, хорошо помогает Web Optimzer от sunnybear. Он тоже делает все, что вами описано.
        0
        вот так: стоит только отлучиться на месяц, а тебя понимать добрым словом начинают :)
        0
        Скоро буду делать крупный проект на ExtJS — будем оптимизировать. За mod_expires спасибо, не знал
          +2
          Вы рассказываете простейшие вещи, которые уже очень давно вошли в норму.
            0
            да, еще можно собрать кастомную версию екста, под свои нужды через онлайновый конструктор или вручную. Кстати, размер никак не пару мегабайт, а чуть больше 500 кб ( я о ext-all.js + ext-base.js)
              0
              Я брал дебаговые версии, не сжатые, т.к. их удобней использовать при разработке.
                0
                При разработке то зачем все в один файл объединять :)
                Это имеет смысл делать на продакшн версии, а ее даже и не нужно через yuicompressor пропускать.
                Повторюсь, все что вы написали это хорошо, но делается Web Optimizer'ом, особого смысла писать свой велосипед нет.
                  0
                  У меня в проекте есть система стейтов, при дебаговом режиме не используются сжатые файлы, а используются дебаговые версии. То что я описал я использую только для продакшна.

                  По поводу веб оптимайзера, это хорошо что есть готовый проект, но не всегда его можно использовать.
                    0
                    вообще проект писался под довольно широкие нужды, в том числе и для перегонки dev-версии в продакш

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое