Программное объединение изображений в PHP

Question

Я большой поклонник рекомендаций Yahoo по ускорению веб-сайтов. Одна из рекомендаций - комбинировать изображения, где это возможно, чтобы сократить размер и количество запросов. Однако я заметил, что, хотя спрайты CSS могут быть легко использованы для макетов, другие виды использования изображений не так легко комбинируются. Основной пример, о котором я думаю, - это список блогов или статей, где с каждым блогом или статьей также связано изображение. Эти изображения могут сильно повлиять на время загрузки и размер страницы, особенно если они не оптимизированы. То, что я ищу, в концепции или на практике, - это способ динамического объединения этих изображений при запуске их без сжатия без потерь с использованием PHP.

Несколько добавленных мыслей или проблем:

• Объединение изображений и генерация динамическая таблица стилей CSS для позиционирования фоны изображений могут быть одним из способов пойти об этом, но я также беспокоиться о доступности и семантика. Насколько я понимаю, CSS изображения должны быть использованы для макета элементы и тег img (с атрибут alt) должен использоваться для изображения, которые предназначены для передачи Информация. Я мог бы установить изображение в качестве фона для элемента div и заменить атрибут заголовка для атрибут alt, но я не уверен насчет доступность и семантика последствия этого.
• Может быть, библиотека GD будет хорошей кандидат на что-то подобное? Можете ли вы порекомендовать другие варианты?

Answer 1

Я бы не пошел по этому пути на твоем месте. Конечно, вы можете сэкономить несколько байтов в служебных данных протокола, уменьшив количество запросов, но это, скорее всего, приведет к саморазрушению.

Представьте себе этот сценарий: Блог-сайт, на главной странице которого есть 10 статей одновременно. С каждой статьей связано собственное изображение. Чтобы сэкономить один или два байта времени передачи, вы программно создаете составное изображение из всех 10 изображений статьи. Теперь у вас есть одна из двух проблем.

1. Вы должны обновлять составное изображение каждый раз, когда создается новое сообщение, поскольку самые последние 10 изображений будут иметь измененный набор содержимого.
2. Вы решаете создавать новый составной каждый запрос на лету.

Очевидно, что # 1 здесь предпочтительнее, и его не составит труда реализовать. Однако что делать, если пользователь ищет все сообщения, помеченные словом «SQL»? Вы вряд ли получите составное изображение первых 10 результатов, уже созданных для этого простого запроса, не говоря уже о более сложном. Кроме того, что произойдет, если вы захотите обновить или удалить изображение? Еще раз вам придется запустить фоновое создание композита.

Как насчет агрегатора RSS, такого как Google Reader? У него не было бы необходимой логики, чтобы выяснить, какую часть составного изображения нужно будет отобразить, и, вероятно, отображалось бы полное изображение. (Я упоминаю Google Reader, потому что очень редко посещаю сайты блогов напрямую, склоняясь к доверию службе агрегации RSS, такой как Reader)

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

Сказав, что, если вы все равно решите пойти по этому пути, я бы сказал, что библиотека GD - отличное место для старта.

Answer 2

Вам почти наверняка будет лучше уменьшить размер файлов изображений в статьях, чем объединить их. Я согласен с тем, что могут быть проблемы с доступностью при использовании предложенного вами метода. Кроме того, я полагаю, это зависит от того, что вы подразумеваете под «динамическим» - если вы думаете о комбинировании этих изображений и создании CSS для каждой загрузки страницы, вы можете обнаружить, что это приводит к более медленному времени загрузки страницы для пользователей со средней скоростью соединения .

Что касается вашего второго замечания, GD, безусловно, справится с этим. Лучшее использование GD для сокращения времени загрузки страницы может заключаться в снижении качества изображений ваших статей, чтобы уменьшить размеры файлов во время создания статьи, а не при загрузке страницы.