Недавно мне пришлось использовать достаточно большое число png иконок (gif не подходит по той причине, что фон под иконками разный и обтравить его не представляется возможным) на одой странице и тут возникла достаточно интересная ситуация. Иконок в сумме всего четыре, тегов img для них порядка 200. Казалось бы, что это ничего страшного, так как иконка загрузится всего один раз и далее будет браться из кеша, что собственно и происходит.
Исходим из наличия четырех иконок и употребления их на странице в числе 265 штук. Тестирование производится локально. В качестве средств тестирования выступает ie6, Windows Task Manager, Http analyzer
Начнем проводить тестирование производительности каждого из фиксов с самого основного — дополнительного для ie6 свойства filter. Напомню, что выглядит оно так
Правда, что бы он заработал для тега img его нужно модифицировать до вида, хотя есть и другие вариации.
где dot.gif — однопиксельная прозрачная gif картинка.
Открываем «испытуемого» в ie6 и видим, что фон у картинок пропадает поочередно. Причиной этого является то, что для обработки каждой из иконок браузер отсылает по одному http запросу к файлу dot.gif, что в сумме дает 269 http запросов на картинки (с учетом самих иконок) — назовем это «Основная проблема». Суммарное время обработки при первой загрузке сотавило 2.781 секунды. По результату десяти тестов среднее время обработки составило 2.85 секунды. Именно эту цифру мы принимаем за минимальную величину и переходим к тестирования более «автоматических» фиксов.
Начнем с одного из самых часто используемых — iepngfix.htc Данное решение основано на использовании того же filter, только заключается в автоматическом нахождении элементов через DOM. Требует однопиксельный gif. Поведение ie6 к обработке каждой из иконок идентично первому способу. Среднее время обработки — 3.05 секунды, что несколько больше, чем при использовании expression. Но основная проблема осталась.
Менее известный скрипт — supersleight.js,
который тоже основан на использовании filter показал абсолютно аналогичный результат по сравнению с iepngfix.htc, только особенность его обработки в том, что он начинает обработку с последней картинки.
Среднее время в случае использования данного фикса — 3.5 секунды
Неменее неизвестный скрипт — unitpngfix.js
Отличается, пожалуй, только тем, что «весит» 950 байт. В целом поведение один в один с supersleight.js.
Среднее время обработки данным скриптом — 4 секунды
Популярный плагин к библиотеке jquery «pngFix.js»
проявил себя достаточно плохо. Он отправил всего 4 http запроса, при том условии что использует он все тот же filter, но из десяти тестов браузер полностью завис три раза, остальный разы рендеринг страницы длился более 20 секунд. Так что этот вариант нельзя использовать при таком числе картинок.
Отличный по своей функциональности ie7-js
тут же показал себя просто отлично. 4 http запроса, небольшое время обработки всех картинок (порядка пяти секунд), отсутствие зависания браузера. Наблюдается лишь подвисание исчезновения серого фона у иконок.
Самое последнее (имеется ввиду по дате появления) решение проблемы прозрачности png-24 — DD_belatedPNG
Тут происходит самое интересное явление, которое заключается в том, что браузер посылает 8 http запросов, т.е по 2 раза к одной иконке, при этом время отклика по итогам тестирование ни разу не превысило 0.5 секунд, но приводило к существенному зависанию браузера на время рендеринга всех картинок. Фактически браузер «зависал» на 10—15 секунд, после чего отображал страницу. Такое поведение можно считать неприемлемым вариантом.
Подводя итоги данного теста DD_belatedPNG и jquery pngFix можно признать самыми неудачными вариантами в случае использования большого числа изображений, хотя DD_belatedPNG во всех других ситуациях, т.е при небольшом числе обрабатываемых изображений формата png-24, фактически не имеет себе равных. iepngfix, supersleight и expression в целом оказались значительно быстродейственнее, хотя создают много http запросов. Победителем данного теста можно смело назвать ie7-js и expression
_________
Текст подготовлен в ХабраРедакторе
Исходим из наличия четырех иконок и употребления их на странице в числе 265 штук. Тестирование производится локально. В качестве средств тестирования выступает ie6, Windows Task Manager, Http analyzer
Начнем проводить тестирование производительности каждого из фиксов с самого основного — дополнительного для ie6 свойства filter. Напомню, что выглядит оно так
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='../image.png', sizingMethod='image');Правда, что бы он заработал для тега img его нужно модифицировать до вида, хотя есть и другие вариации.
background-image: expression(
this.runtimeStyle.backgroundImage = "none",
this.runtimeStyle.filter =
"progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" +
this.src + "', sizingMethod='image')",
this.src = "dot.gif"
);где dot.gif — однопиксельная прозрачная gif картинка.
Открываем «испытуемого» в ie6 и видим, что фон у картинок пропадает поочередно. Причиной этого является то, что для обработки каждой из иконок браузер отсылает по одному http запросу к файлу dot.gif, что в сумме дает 269 http запросов на картинки (с учетом самих иконок) — назовем это «Основная проблема». Суммарное время обработки при первой загрузке сотавило 2.781 секунды. По результату десяти тестов среднее время обработки составило 2.85 секунды. Именно эту цифру мы принимаем за минимальную величину и переходим к тестирования более «автоматических» фиксов.
Начнем с одного из самых часто используемых — iepngfix.htc Данное решение основано на использовании того же filter, только заключается в автоматическом нахождении элементов через DOM. Требует однопиксельный gif. Поведение ie6 к обработке каждой из иконок идентично первому способу. Среднее время обработки — 3.05 секунды, что несколько больше, чем при использовании expression. Но основная проблема осталась.
Менее известный скрипт — supersleight.js,
который тоже основан на использовании filter показал абсолютно аналогичный результат по сравнению с iepngfix.htc, только особенность его обработки в том, что он начинает обработку с последней картинки.
Среднее время в случае использования данного фикса — 3.5 секунды
Неменее неизвестный скрипт — unitpngfix.js
Отличается, пожалуй, только тем, что «весит» 950 байт. В целом поведение один в один с supersleight.js.
Среднее время обработки данным скриптом — 4 секунды
Популярный плагин к библиотеке jquery «pngFix.js»
проявил себя достаточно плохо. Он отправил всего 4 http запроса, при том условии что использует он все тот же filter, но из десяти тестов браузер полностью завис три раза, остальный разы рендеринг страницы длился более 20 секунд. Так что этот вариант нельзя использовать при таком числе картинок.
Отличный по своей функциональности ie7-js
тут же показал себя просто отлично. 4 http запроса, небольшое время обработки всех картинок (порядка пяти секунд), отсутствие зависания браузера. Наблюдается лишь подвисание исчезновения серого фона у иконок.
Самое последнее (имеется ввиду по дате появления) решение проблемы прозрачности png-24 — DD_belatedPNG
Тут происходит самое интересное явление, которое заключается в том, что браузер посылает 8 http запросов, т.е по 2 раза к одной иконке, при этом время отклика по итогам тестирование ни разу не превысило 0.5 секунд, но приводило к существенному зависанию браузера на время рендеринга всех картинок. Фактически браузер «зависал» на 10—15 секунд, после чего отображал страницу. Такое поведение можно считать неприемлемым вариантом.
Подводя итоги данного теста DD_belatedPNG и jquery pngFix можно признать самыми неудачными вариантами в случае использования большого числа изображений, хотя DD_belatedPNG во всех других ситуациях, т.е при небольшом числе обрабатываемых изображений формата png-24, фактически не имеет себе равных. iepngfix, supersleight и expression в целом оказались значительно быстродейственнее, хотя создают много http запросов. Победителем данного теста можно смело назвать ie7-js и expression
_________
Текст подготовлен в ХабраРедакторе