Программное объединение изображений в PHP
Я большой поклонник Yahoo рекомендации для ускорения веб-сайтов. Одна из рекомендаций - по возможности комбинировать изображения, чтобы сократить размер и количество запросов. Однако я заметил, что, хотя спрайты CSS можно легко использовать для макетов, другие виды использования изображений не так легко комбинировать. В качестве основного примера я думаю о блоге или списке статей, где с каждым блогом или статьей также связано изображение. Эти изображения могут сильно повлиять на время загрузки и размер страницы, особенно если они не оптимизированы. То, что я ищу, концептуально или на практике, - это способ динамического комбинирования этих изображений при их прогоне через сжатие без потерь с использованием PHP.
Несколько дополнительных мыслей или опасений:
- Объединение изображений и создание таблица стилей динамического CSS для размещения фон изображений может быть одним из способов сделать это, но я также беспокоиться о доступности и семантика. Насколько я понимаю, CSS-изображения должны использоваться для макета элементов и тега img (с атрибут alt) следует использовать для изображения, которые предназначены для передачи Информация. Я мог бы установить изображение в качестве фона для элемента div и замените атрибут заголовка на alt атрибут, но я не уверен насчет доступность и смысловая последствия этого.
- Может ли библиотека GD быть хорошей кандидат на что-то подобное? Можете порекомендовать другие варианты?
Ответы 2
На твоем месте я бы не пошел по этому пути. Конечно, вы можете сэкономить несколько байтов на накладных расходах протокола, уменьшив количество запросов, но это, скорее всего, закончится саморазрушением.
Представьте себе такой сценарий: Сайт блога, на первой странице которого одновременно размещается 10 статей. С каждой статьей связано собственное изображение. Чтобы сэкономить один или два байта времени передачи, вы программно создаете составное изображение всех 10 изображений статей. Теперь у вас есть одна из двух проблем.
- Вы должны обновлять составное изображение каждый раз, когда создается новая публикация, так как самые последние 10 изображений будут иметь измененный набор содержимого.
- Вы решаете на лету создавать новую композицию для каждого запроса.
Очевидно, что №1 здесь предпочтительнее, и его нетрудно реализовать. Однако что, если пользователь ищет все сообщения, помеченные словом «SQL»? У вас вряд ли будет составное изображение первых 10 результатов, уже созданных для этого простого запроса, не говоря уже о более сложном. Кроме того, что произойдет, если вы захотите обновить или удалить изображение? И снова вам нужно будет запустить создание фона композита.
Как насчет агрегатора RSS, такого как Google Reader? У него не было бы необходимой логики, чтобы выяснить, какую часть составного изображения ему нужно будет отобразить, и, вероятно, он отобразил бы полное изображение. (Я упоминаю Google Reader, потому что я очень редко посещаю сайты блогов напрямую, склоняясь к службе агрегирования RSS, такой как Reader)
Если бы это был я, я бы оставил отдельные изображения в покое. При современных скоростях соединения компромисс между дополнительной пропускной способностью и временем обработки на сервере вряд ли принесет вам большую выгоду.
Сказав это, если вы все равно решите пойти по этому пути, я бы сказал, что библиотека GD - отличное место для начала.
Очень хорошие моменты. Я не рассматривал страницы результатов поиска и т. д. Этот вопрос был своего рода размышлениями вслух, но я спорил о том, стоит ли какого-либо увеличения производительности, если принять во внимание процесс создания изображения. Я могу просто согласиться на сжатие.
Вам почти наверняка будет лучше уменьшить размер файла изображений в статьях, чем комбинировать их. Я согласен с тем, что при использовании предложенного вами метода могут возникнуть проблемы с доступностью. Кроме того, я полагаю, это зависит от того, что вы подразумеваете под «динамическим» - если вы думаете об объединении этих изображений и генерации CSS для каждой загрузки страницы, вы вполне можете обнаружить, что это приводит к более медленной загрузке страницы для пользователей со средней скоростью соединения. .
Что касается вашего второго пункта, GD определенно справится с этим. Лучшее использование GD для сокращения времени загрузки страницы может заключаться в снижении качества изображений ваших статей для уменьшения размера файлов во время создания статьи, а не при загрузке страницы.
Хорошие моменты. Я тоже думал в этом направлении, но решил посмотреть, что думают и другие люди.
Отличный ответ - в частности, ваш первый бит (комбинация изображений может отличаться для разных загрузок страницы) мне не пришло в голову.