Comments 29
Спасибо. Судя по всему, должен облегчить работу. Попробую в действии.
Хабралюди! Накиньте, плиз, человеку кармы, чтобы он перенес это в Клиентскую оптимизацию. Наработка была реально стоящая, чтобы вытащить ее из песочницы.
Зачем нужен qpimg?
qpimg позволит увеличить время загрузки вашего сайта, а также снизить нагрузку на web-сервер, используя технологию CSS спрайтов.
code.google.com/p/qpimg/
зачем увеличивать время загрузки?
qpimg позволит увеличить время загрузки вашего сайта, а также снизить нагрузку на web-сервер, используя технологию CSS спрайтов.
code.google.com/p/qpimg/
зачем увеличивать время загрузки?
На мой взгляд, очень полезный скрипт, пойду тестить.
А зачем вам какая-то ерунда про смену имён при отладке? Неужели нельзя перезагрузить страницу без кэша по Ctrl+F5?
Я наверное чего-то не понимаю.
Я наверное чего-то не понимаю.
Ну, строго говоря, пока это генерация сферического коня для вакуума.
Мне кажется, что такой скрипт должен работать автоматически, анализируя содержимое папок, а не через мудрёный конфиг. Как пример, четыре папки:
i/content/
i/icons/
i/repeat-x
i/repeat-y
…на выходе:
i/content/…
i/icons.png
i/repeat-x.png
i/repeat-y.png
Безусловно, такая разработка очень нужна, но пока пользоваться ей — это дополнительные сложности, а не преимущество. Такой инструмент должен работать сам, причём по принципу драг-н-дроп, в нашем случае — драг-картинку-в-папку.
Ну и пример включает в себя не только оформительскую графику, но и обычные контентные изображения, интеграция которых в спрайт выглядит сомнительно.
Мне кажется, что такой скрипт должен работать автоматически, анализируя содержимое папок, а не через мудрёный конфиг. Как пример, четыре папки:
i/content/
i/icons/
i/repeat-x
i/repeat-y
…на выходе:
i/content/…
i/icons.png
i/repeat-x.png
i/repeat-y.png
Безусловно, такая разработка очень нужна, но пока пользоваться ей — это дополнительные сложности, а не преимущество. Такой инструмент должен работать сам, причём по принципу драг-н-дроп, в нашем случае — драг-картинку-в-папку.
Ну и пример включает в себя не только оформительскую графику, но и обычные контентные изображения, интеграция которых в спрайт выглядит сомнительно.
Подход интересен, но имеет некоторые минусы:
* базовый минус — невозможность тонкой настройки свойств каждого объекта карты. Например, большое кол-во объектов будет назначаться для определенных css-селекторов документа, по типу: для «ul.list1 li», для «ul.list2 li», для «ul.backlist li.active». При определении папки — это теряется либо нужно «еще как-то хитро изощряться» чтобы указывать их;
* именования css-селекторов будет явно подвязано к имени файла, что не всегда удобно. Например, при изменении имени файла измениться и css-селектор объекта, соответвенно нужно будет менять его по всем шаблонам. Плюс нужно будет обрабатывать под папки, а это может привести к часным случаям «совпадения» имен css-селекторов.
* каждая папка создает одну карту с определенным набором изображений (объектов). Получается что нельзя указать выборочные изображения из других папок. А это может быть полезно, если генерируются несколько карт в которых некоторые элементы должны быть вставлены из одного изображения;
* невозможность использования удаленных изображений (случай крайне редкий, но...);
Да и, например, возмем minify. Проект не мало известен и юзабелен, но всё же каждый файл указывается в массиве.
Хотя в целом идея интересна. Можно будет подумать и записать в ToDo ;-)
* базовый минус — невозможность тонкой настройки свойств каждого объекта карты. Например, большое кол-во объектов будет назначаться для определенных css-селекторов документа, по типу: для «ul.list1 li», для «ul.list2 li», для «ul.backlist li.active». При определении папки — это теряется либо нужно «еще как-то хитро изощряться» чтобы указывать их;
* именования css-селекторов будет явно подвязано к имени файла, что не всегда удобно. Например, при изменении имени файла измениться и css-селектор объекта, соответвенно нужно будет менять его по всем шаблонам. Плюс нужно будет обрабатывать под папки, а это может привести к часным случаям «совпадения» имен css-селекторов.
* каждая папка создает одну карту с определенным набором изображений (объектов). Получается что нельзя указать выборочные изображения из других папок. А это может быть полезно, если генерируются несколько карт в которых некоторые элементы должны быть вставлены из одного изображения;
* невозможность использования удаленных изображений (случай крайне редкий, но...);
Да и, например, возмем minify. Проект не мало известен и юзабелен, но всё же каждый файл указывается в массиве.
Хотя в целом идея интересна. Можно будет подумать и записать в ToDo ;-)
было бы хорошо иметь что-то вроде автоматического решения: на вход скармливаешь CSS-файлы, а на выходе получаешь их же в измененном состоянии + набор спрайтов.
Примерно так же, как сделано в DURIS:
duris.ru/
Примерно так же, как сделано в DURIS:
duris.ru/
Я вообще к тому, что пока не готов разрешать кому-то писать за меня CSS-код )
CSS-спрайты — это не то, что нужно использовать по умолчанию в 100% случаев. В частности из-за того, что это усложняет вёрстку. Это скорее финальный тюнинг, поэтому нужно думать над такой моделью работы скрипта, которая работает с уже готовым кодом и картинками.
CSS-спрайты — это не то, что нужно использовать по умолчанию в 100% случаев. В частности из-за того, что это усложняет вёрстку. Это скорее финальный тюнинг, поэтому нужно думать над такой моделью работы скрипта, которая работает с уже готовым кодом и картинками.
Если это «финальный тюнинг», то в qpimg нет смысла :)
А использование css-файлов на входе и получение результирующего css-файла с изображениями (спрайтами) на выходе — такая мысль была. В частности для интеграции qpimg с minify.
Это будет чуть позже, в последующих версиях. Возможно даже в ооочень ближайщем будущем :)
А использование css-файлов на входе и получение результирующего css-файла с изображениями (спрайтами) на выходе — такая мысль была. В частности для интеграции qpimg с minify.
Это будет чуть позже, в последующих версиях. Возможно даже в ооочень ближайщем будущем :)
Возникает идея: нужно сделать qpming как плагин для симфони?
Там можно интегрировать qpimg без единого изменения в коде шаблона.
Т.е. практически сходу использовать на готовом проекте.
Там можно интегрировать qpimg без единого изменения в коде шаблона.
Т.е. практически сходу использовать на готовом проекте.
я создавал такой скрипт. работы на час.
использовал готовую библиотеку для парсинга css.
использовал готовую библиотеку для парсинга css.
Как это читать? «Купмиг» иль «КуПиАйЭмДжи» — закрытый перелом языка)
Очень сомнительны преимущества использования.
Спрайты — это конечно хорошо. Но городить такое «мясо» и засовывать в него картинки контента считаю неразумным.
Проводились ли тесты. Сколько времени сожрет склейка склейка и не дешевле ли будет отдать множество изображений.
Бесспорно идея здоровская.
Но интересна более продуманная реализайия.
Спрайты — это конечно хорошо. Но городить такое «мясо» и засовывать в него картинки контента считаю неразумным.
Проводились ли тесты. Сколько времени сожрет склейка склейка и не дешевле ли будет отдать множество изображений.
Бесспорно идея здоровская.
Но интересна более продуманная реализайия.
>> Но городить такое «мясо» и засовывать в него картинки контента считаю неразумным.
В примере было показано как можно «все» картинки сунуть в спрайты. Разработчик же сам определяет какие именно изображения необходимо засовывать в спрайт. По большому счету это могут быть картинки «скругление форм», «повторяющийся фон», «любые другие _декоративные_ элементы». Например, тот же логотип сайта, я бы не засовывал (и не засовываю) в спрайт.
Засовывать ли картинки «контента» — это тоже определяет разработчик. Например вазмем страницу продукции мобильного телефона. На ней представлено фото телефона и 3-6 маааахеньких изображения preview-данного телефона. Если еще само изображение телефона можно грузить отдельно, то смысл разделять preview? их можно объединит, а уже каждое fullsize-изображение отдавать отдельно. При этом формировать css-спрайт для preview-картинок можно на лету — объединение изображений произойдет 1 раз и будет дооооолгим только для первого посетителя страницы, а остальным же будет изображение отдаваться из кэша. (ps: для этого есть user-функция — qpimg_user_get_map() для генерации структура карты на лету). Либо можно реализовать свой доп-модуль по генерации спрайтов при изменении изображений контента в админке сайта Примером работы склейки на лету можно посмотреть тут www.nomoc.com (preview изображения как раз и генеряться online)
>> Проводились ли тесты.
да :)
>> Сколько времени сожрет склейка склейка
скажу просто — «много», до нескольких секунд. Зависит от кол-ва изображений, их объема, нагрузки сервера, и т.д. Тем более, как уже писалось ранее, склейка может идти именно в процессе dev-разработки. Т.е. релиз-сайт уже будет хранить склеенные изображения и они будут отдаваться из кэша. В итоге будто сайт содержит не 15-30 картинок на страницу, а всего 3-5.
>>… не дешевле ли будет отдать множество изображений
как раз смысл уйти от этого.
А сравнительная таблица есть тут code.google.com/p/qpimg/wiki/PageLoadTime — «Зависимость времени загрузки страницы от кол-ва изображений на ней». Имхо, разница очень даже существенная.
Еще один момент, зачем нужен qpimg. Выше «pepelsbey» написал что qpimg можно юзать как «финальный тюнинг». Однако qpimg позволяет генерить css спрайты на лету именно в процессе разработки. Т.е. qpimg посути должен облегчить процесс разработки сайта. Также вставка этих спрайтов требует некоего пересмотра кода шаблонов (например, вставка пустых ссылок в src-атрибут изображений и вставка qpimg-генерируемых class-значений для этих же изображений). А пересмотр кода «перед запуском» проекта может быть довольно таки не-быстро-делательной работой :) Посяму лучше qpimg использовать в проекте изначально. Плюс в дальнейшей доработке проекта модификация спрайта будет очень простой.
В примере было показано как можно «все» картинки сунуть в спрайты. Разработчик же сам определяет какие именно изображения необходимо засовывать в спрайт. По большому счету это могут быть картинки «скругление форм», «повторяющийся фон», «любые другие _декоративные_ элементы». Например, тот же логотип сайта, я бы не засовывал (и не засовываю) в спрайт.
Засовывать ли картинки «контента» — это тоже определяет разработчик. Например вазмем страницу продукции мобильного телефона. На ней представлено фото телефона и 3-6 маааахеньких изображения preview-данного телефона. Если еще само изображение телефона можно грузить отдельно, то смысл разделять preview? их можно объединит, а уже каждое fullsize-изображение отдавать отдельно. При этом формировать css-спрайт для preview-картинок можно на лету — объединение изображений произойдет 1 раз и будет дооооолгим только для первого посетителя страницы, а остальным же будет изображение отдаваться из кэша. (ps: для этого есть user-функция — qpimg_user_get_map() для генерации структура карты на лету). Либо можно реализовать свой доп-модуль по генерации спрайтов при изменении изображений контента в админке сайта Примером работы склейки на лету можно посмотреть тут www.nomoc.com (preview изображения как раз и генеряться online)
>> Проводились ли тесты.
да :)
>> Сколько времени сожрет склейка склейка
скажу просто — «много», до нескольких секунд. Зависит от кол-ва изображений, их объема, нагрузки сервера, и т.д. Тем более, как уже писалось ранее, склейка может идти именно в процессе dev-разработки. Т.е. релиз-сайт уже будет хранить склеенные изображения и они будут отдаваться из кэша. В итоге будто сайт содержит не 15-30 картинок на страницу, а всего 3-5.
>>… не дешевле ли будет отдать множество изображений
как раз смысл уйти от этого.
А сравнительная таблица есть тут code.google.com/p/qpimg/wiki/PageLoadTime — «Зависимость времени загрузки страницы от кол-ва изображений на ней». Имхо, разница очень даже существенная.
Еще один момент, зачем нужен qpimg. Выше «pepelsbey» написал что qpimg можно юзать как «финальный тюнинг». Однако qpimg позволяет генерить css спрайты на лету именно в процессе разработки. Т.е. qpimg посути должен облегчить процесс разработки сайта. Также вставка этих спрайтов требует некоего пересмотра кода шаблонов (например, вставка пустых ссылок в src-атрибут изображений и вставка qpimg-генерируемых class-значений для этих же изображений). А пересмотр кода «перед запуском» проекта может быть довольно таки не-быстро-делательной работой :) Посяму лучше qpimg использовать в проекте изначально. Плюс в дальнейшей доработке проекта модификация спрайта будет очень простой.
Sign up to leave a comment.
qpimg — динамическое создание CSS спрайтов