Комплексная подготовка сайта к Retina

К написанию этого материала меня побудила статья и назревшая необходимость адаптации нескольких своих сайтов к поддержке Retina-дисплеев. Под адаптацией я понимаю подготовку изображений высокого разрешения на страницах сайта.

Пожалуй лучшим способом адаптации на сегодняшний день является способ c background-image в CSS. Но он не применим к обычным изображениям в теге <img>. Поэтому я решил определить для себя список необходимых мер по достижению результата в комплексе и продолжить поиски решения. Ниже описано два способа, каждый из которых применим к своим задачам. Показанные решения не претендуют на открытие, скорее это агрегация существующих способов, описанных ранее моими коллегами по цеху веб-разработок и небольшие собственные дополнения.

Полумера: обработчик background-image

Если вы не хотите утруждать себя обработкой контентных изображений или у вас их нет в принципе, используйте способ показанный в коде ниже и не читайте статью дальше. Например, на одном из сайтов мне не принципиально производить обработку изображений в <img>, но элементы интерфейса (иконки) слишком бросаются в глаза. Поэтому можно использовать простой, но действенный способ:

.elem {     background-image: url(elem.png); }  @media only screen and (-webkit-min-device-pixel-ratio: 1.5),     only screen and (min-resolution: 144dpi) {         .icon {             background-image: url(elem@2x.png);             }     } 

Разумеется, класс elem приведен для примера и нужно адаптировать этот css под ваши нужды. Ну и не забываем про подготовку дополнительного комплекта нарезки изображений дизайна сайта. Разумеется, тут придется поработать, особенно если дизайн сайта насыщен изображениями, но я сторонник разового выполнения таких работ, особенно если их сравнивать с разнообразными «костылями».

Постановка задачи комплексной поддержки Retina

Для себя определил следующие критерии для решения задачи комплексного перевода сайта на поддержку Retina:

1. способ должен быть универсальным и должен включать обработку всех без исключений изображений на сайте;
2. способ не должен приводить к обновлению страниц в результате какого-либо редиректа;
3. способ должен быть максимально лояльным к пользователю, он не должен закачивать в браузер пользователя исходную картинку и подготовленную для Retina.

Решение

Заранее обозначу, что решение адаптировано для Apache.

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

Механизм загрузки и обработки графических файлов описывать не буду, поскольку он учитывает индивидуальные особенности проекта, но суть сводится к тому, что из загруженной пользователем картинки необходимо сформировать рабочее изображение для сайта и его копию, оптимизированную для Retina, в том случае, если качество загруженного изображения это позволяет. Например, в рассматриваемом проекте максимальная ширина контентных изображений составляет 800px. Разумеется, если пользователь загружает изображение с шириной 400px, сформируется только его копия шириной 400px. А вот если пользователь загрузит изображение с шириной хотя бы 1600px, что случается довольно часто, мы сможем порадовать посетителей сайта с Retina.

При этом нужно учесть, что загруженные ранее изображения сохранить в высоком разрешении уже не получится, а уменьшать значения height и width без ведома пользователя как-то неправильно. Поэтому способ должен предусматривать работу как с существующими @2x картинками, так и без оных.

Первым шагом в шаблон страниц (ну или в один из ваших подключаемых js файлов) добавляем простой js-скрипт (важно чтобы этот код выполнился до начала загрузки контента страницы и любого CSS, в котором указаны изображения, которые необходимо подменить):

<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+("devicePixelRatio" in window ? ","+devicePixelRatio : ",1")+'; path=/';</script> 

JS код сформирует куку, по которой серверный скрипт может понять с каким дисплеем пришел на сайт пользователь. Следующим шагом во многих описанных способах формируется редирект посредством js и скрипты CMS, анализируя куку resolution, выдают правильную версию графики. Но мы не ищем легких путей и редирект не применяем. Посредством .htaccess или конфига apache устанавливаем обработчик куки вне скриптов CMS сайта:

RewriteCond %{REQUEST_URI} ^/images #RewriteCond %{REQUEST_URI} !^/images/excluded RewriteCond %{HTTP_COOKIE} resolution=([^;,]+),2 RewriteCond %{REQUEST_URI} !@2x\.(jpe?g|gif|png)$ RewriteRule ([^.]+)\.(jpe?g|gif|png)$ $1@2x.$2 [L] 

Первая строка RewriteCond подсказывает скрипту в какой папке лежат обрабатываемые файлы изображений.
Вторая (закомментированная) строка позволяет добавить папку-исключение в обработчик.
В третьей строке RewriteCond мы избавляемся от того самомго редиректа, определяя куку, которая была выставлена при загрузке страницы.
Четвертое условие исключает из обработки уже отданные изображения высокого разрешения (с фрагментом "@2x" в конце имени файла).
В пятой строке мы определяем к изображениям какого формата необходимо применить подмену.

Преимущества описанного способа:

• решение работает для всех изображений сайта;
• нет редиректа страницы;
• при отсутствии куки «resolution» пользователь увидит дефолтный контент страницы.

Недостатки:

• (по мнению автора этого способа) не учтен пользовательский способ подключению к интернету и возможность выкачивания им изображений в высоком разрешении;
• существенный недостаток, с моей точки зрения, в необходимости использования редиректа на hi-res изображение посредством Apache;
• также, с моей точки зрения, существенная проблема состоит в отсутствие проверки наличия @2x изображения на сервере.

Для себя я внес в рассмотренный способ коррективу для того, чтобы избежать проблем с несуществующими изображениями.

В .htaccess строка

RewriteRule ([^.]+)\.(jpe?g|gif|png)$ $1@2x.$2 [L] 

заменена на

RewriteRule ([^.]+)\.(jpe?g|gif|png)$ retina.php?img=$1@2x.$2 

Простой php скрипт определяет наличие запрашиваемого изображения на сервере и выдает его. Если файл изображения не найден, скрипт отдает обычную (не hi-res) картинку. Разумеется с проверкой запрашиваемых данных:

<?php if (!empty($_GET['img']) && mb_substr_count($_GET['img'], '@2x'))     {     function isImg ($dress)         {         if (function_exists('exif_imagetype'))             $type_file = exif_imagetype ($dress);         else             {             $type_file = getimagesize ($dress);             $type_file = $type_file[2];             }         // проверка типа файла изображения         // 1 = GIF, 2 = JPG, 3 = PNG         if (in_array($type_file, array(1,2,3)))             {             if (type_file==1)                 header("Content-Type: image/gif");             elseif ($type_file==2)                 header("Content-Type: image/jpeg");             else                 header("Content-Type: image/x-png");             header(sprintf('Content-Length: %d', filesize($dress)));                         return true;             }         unset ($type_file);         return false;         }      $_GET['img'] = $_SERVER['DOCUMENT_ROOT'].'/'.$_GET['img'];          if (file_exists($_GET['img']) && isImg ($_GET['img']))         die (file_get_contents($_GET['img']));     else         {         $_GET['img'] = str_replace("@2x", "", $_GET['img']);         if (file_exists($_GET['img']) && isImg ($_GET['img']))             die (file_get_contents($_GET['img']));         }     header("HTTP/1.1 404 Not Found"); // если нет картинок     } else     header("HTTP/1.1 403 Forbidden"); ?> 

Разумеется, это изменение увеличило нагрузку на сервер, но другого решения я не видел. Буду рад вашим мнениям.

За основу изложенного способа решения задачи взят метод Automatically serve retina artwork by Sam Sehnert.