Оптимизация картинок для Web
Во многих случаях общий размер картинок, которые грузятся на стринце составляет 50% (и более) от веса всех компонент страницы. Это следует учитывать при клиентской оптимизации, т.к. картинки могут стать бутылочным горлышком Вашей системы. Необходимо обдумывать использование каждого графического элемента на странице. Тем не менее, есть ряд практик и советов, которые позволяют ускорить загрузку изображений.
Используйте правильные форматы картинок
В статье “Оптимизация клиентской части” были рассмотрены используемые в Web форматы изображений. Еще раз об основных форматах:
- GIF - использует ограниченную палитру, что позволяет создавать картинки малого размера. Их удобно использовать для иконок и картинок для верстки. Помимо этого, GIF позволяет использовать прозрачность и создавать анимацию
- JPEG - хорошо подходит для цветных фотографий (отличительной их особенностью является обширная палитра). Предоставляет возможность прогресивной загрузки картинки (сначала грузится превью худшего качества, а потом полное изображение). Поддерживает прогрессивный формат, когда изображение загружается итеративно - от низкого качества к высовому
- PNG - полнофункциональный формат. Может использовать как ограниченную так и полную палитру. Позволяет использовать прозрачность. Его следует использовать только в крайних случаях, например когда необходима градиентная прозрачность
Минимизируйте размер изображений
Понятно, что минимизация размера изображения приведет к его более быстрой загрузке. Есть ряд простых техник для этого:
- Делайте изображение только таким размером, который требуется. Не оставляется белых краев, их легко можно реализовать при верстке
- Используйте сжатие JPEG вместе со сглаживанием, что-бы добиться минимального размера картинки при допустимом качестве
- Используйте минимальную палитру в GIF изображении. Если у Вас два цвета, то палитра тоже должна состоять из двух цветов
- Вырезайте всю доп. информацию из изображения (комментарии и прочие данные, которые сохраняют многие редакторы по умолчанию)
- Склеивайте маленькие картинки в одну и пользуйтесь техникой CSS спрайтов для отображения на странице
Настройка отдачи
Не забывайте устанавливать заголовки кеширования про отдачи с Web сервера картинок. Это позволит избежать повторной загрузки их у клиента при повторном открытии страницы.
Чего делать не стоит
- Не используйте браузерный ресайз (задание аттрибутов width и height меньшими, чем реальный размер фото)
- Не сохраняйте текст в виде изображения (по крайней мере тот, который можно перенести в HTML)
- Не используйте маленькую прозрачную картинку для верстки (мелочь, но только усложнит Вам жизнь)
Еще можно было осветить утилиты для минимизации изображений (удаляют комментарии, пережимаю и т.д.) для полноты статьи.
Правда ли, что если разнести картинки, скрипты, стили по разным сабдоменам браузер будет создавать несколько потоков для загрузки вместо одного?
@IgorN
Да, совершенно верно, но это актуально не для всех браузеров. В любом случае практика эта полезна, т.к. хуже она не сделает, а вот в последствии можно будет делать изолирование (разделение на подсистемы) без проблем.
Разносят на разные домены картинки и html в основном для уменьшения входящего трафика (при каждом запросе, не важно, картинка это, css или еще какой файл) браузер передает куку, если она для домена установлена. Что генерит на самом деле неслабый входящий трафик. Перенос картинок (особенно мелкой ерунды под верстку) на другой домен (на который куки не записаны) снижает входящий траффик довольно ощутимо. Напривер вот что посылает мой браузер для этой страницы
Host highload.com.ua
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3
.5.30729)
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language ru,en-us;q=0.7,en;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Connection keep-alive
Referer http://highload.com.ua/
Cookie
__utma=232180614.2898944716182242000.1242659804.1246563050.1246830249.11; __utmz=232180614.1246225165
.3.3.utmcsr=yandex|utmccn=(organic)|utmcmd=organic|utmctr=memcachedb; __utmc=232180614; comment_author_f906fa3c14e3bae4339043cf61d94fc0
=kaa; comment_author_email_f906fa3c14e3bae4339043cf61d94fc0=kaa%40berloga.ru; comment_author_url_f906fa3c14e3bae4339043cf61d94fc0
=http%3A%2F%2Fberloga.ru; __utmb=232180614.2.10.1246830249
Cache-Control max-age=0
Кука занимает наверное треть. Если не больше. Еще для картинок, которые на этой странице есть, довольно много занимает реферер (русские буквы в урле этому только способствуют). И вот результат - если все картиночки вынести на другой домен (субдомен) - сократим входящий трафик существенно.
Если кто-то думает, что входящий трафик - небольшой, это же веб-сервер - он ошибается - на нашем небольшом по посещаемости сервере (core2duo/1 гиг, средняя загрузка 5%) входящий трафик за первых 4 дня текущего месяца составил почти 13 гиг. Там безусловно большая доля почты, но все же cookie-like трафика там тоже хватает.
to @IgorN
Извините, но вы бред написали.
Разные домены или поддомены порождают дополнительные запросы к DNS, что чревато потерей времени при первой загрузке. Количество потоков в браузере ограничено по айпи адресам, не более N-ого количества на один сервер (один айпи). Того требует стандарт и ничего плохого в этом нет, чтобы клиенты не положили ваш сервер. В старых браузерах ограничение очень жесткое N = 2 и действительно является узким местом, но опять же суб-доменов не достаточно, необходимо чтобы у них были разные айпи-адреса. Да и в современных браузерах такой проблемы не существует.
@VBart
Вы не могли бы скинуть ссылку на описание стандарта, в котором говорится, что потоки ограничены на IP адреса.
По спецификации HTTP 1.1 количество паралельных запросов ограничивается только по доменным именам (для преодоления этого ограничения иногда даже CNAME записи используют: http://www.webreference.com/programming/web_optimization/)
@VBart
DNS резолвится только при первом обращении, потом достается из кеша (как правило). А вот разницы, на одном ip домены или на разных, нет вообще никакой. Другое дело, что разнесение статики на другие домены все же чаще имеет целью минимизацию входящего трафика…