Докато мобилните устройства и таблетка Тъй като те най-накрая идват да доминират в света, уеб технологията е в надпревара да приеме непрекъснато нарастващите цифри в размера на екрана. Разработването на инструменти за справяне с това явление ни носи нов брой проблеми, с една от последните думи, които се появяват: „Уеб отзивчив“ . Това е предизвикателството да накараме мрежата да работи на повечето, ако не и на всички устройства, без да се понижава качеството на потребителското изживяване. Вместо да проектира съдържание, подходящо за настолен компютър или лаптоп, информацията трябва да е достъпна за мобилни телефони, таблети или всякакви повърхности, свързани към мрежата. Тази еволюция на отзивчив уеб дизайн Оказа се трудно и понякога болезнено.

Въпреки че може да бъде почти тривиално да се побере текстова информация, сложната част идва, когато разглеждаме съдържание като отзивчиви изображения, инфографика, видеоклипове и т.н., което някога е било проектирано с мисъл за настолни компютри. Това не само повдига въпроса за възможността за правилно показване на съдържанието, но и как самото съдържание се консумира с помощта на различни устройства. Потребителите на смартфони се различават от потребителите на настолни компютри. Неща като планове за данни и скорост на обработка са неща, които трябва да имате предвид. Google започна да откроява сайтове, които са удобни за мобилни устройства в резултатите от търсенето, с някои спекулации ако това ще доведе до значително нарастване на редиците на тези сайтове. Предишните решения се фокусираха върху това чрез стартиране на поддомейни, които бяха само мобилни (и пренасочени), но това увеличи сложността и бързо остаряха. (Не всички сайтове имат възможността да си позволят този маршрут).

При адаптивно търсене на изображения в мрежата

На този етап разработчиците и дизайнерите могат да гарантират, че зареждането на уебсайта им е оптимизирано за потребители, които са на мобилни сайтове. Повече от 20% от уеб трафика сега идва от мобилни потребители и броят им нараства. С изображенията, поемащи сред най-големите части от съдържание на данни, оразмеряването се превърна в приоритет, включително решения от страна на сървъра и отпред. За да обсъдим тези решения за коригиране на преоразмеряването, първо трябва да разберем текущите недостатъци на свързващите изображения.

той просто има атрибут източник, свързан директно със самото изображение. Нямате начин да определите правилния тип на изображението, което е необходимо, без никакви допълнения.

Не можем ли да поставим всички размери на изображенията, включени в HTML, и да използваме CSS правила, за да поставим display:none за всичко, освен за правилното изображение? Това е най-логичното решение в един перфектен логически свят. Но по този начин браузърите могат да игнорират всички неекспонирани изображения и теоретично да не ги изтеглят. Браузърите обаче са оптимизирани извън общата логика. За да направи страницата възможно най-бърза, браузърът визуализира свързано съдържание, дори преди таблиците със стилове и JavaScript файловете да се заредят напълно. Вместо да игнорира големите изображения, предназначени да работен плот , завършихме с изтеглянето на всички изображения, което доведе до много по-голяма страница за зареждане. Техниката само за CSS работи само за изображения, които са предназначени за фонове, защото те могат да бъдат зададени в таблици със стилове (с помощта на медийни заявки ).

И така, какво трябва да прави уебсайтът?

Back-End решения за мащабируемост на изображенията

С изключение на сайтовете / поддомените само за мобилни устройства, ние продължаваме да подушваме потребителския агент (UA) и го използваме, за да обслужваме правилния размер на изображенията на потребителя. Всеки разработчик обаче може да свидетелства колко ненадеждно може да бъде това решение. Новите UA нишки се появяват през цялото време, което го прави уморително да поддържа и актуализира изчерпателен списък. И разбира се, това дори не отчита колко ненадеждни и колко лесни за заобикаляне са UA нишките за начало.

Персонализиращи се изображения

Въпреки това, някои вторични сървърни решения си заслужава да бъдат разгледани. Персонализиращи се изображения това е чудесно решение за тези предпочитани отзивчиви масиви от образи. Не изисква никакви надценка специално, но от друга страна, той използва малък JavaScript файл и прави по-голямата част от тежкото повдигане във вашия бекенд файл. Той използва PHP и конфигуриран сървър nginx. Това също не зависи от проследяване на UA и вместо това проверява ширината на екрана. Адаптивните изображения работят добре за мащабиране на изображения, но са полезни и при нужда от големи изображения направление на изкуството Например намаляване на изображението чрез техники като изрязване и завъртане, а не само мащабиране.

Докоснете Сенча

Sencha Touch е друго решение отзад за отзивчиви дизайнерски изображения, въпреки че най-добре е посочено като възложено на външни изпълнители решение. Sencha Touch ще преоразмери съответно размера на изображението, когато проследява UA. По-долу е даден основен пример за това как работи тази услуга:

Има и опция за определяне на размери, в случай че не искаме Sencha да променя размера си автоматично. В края на деня решенията за вторичен сървър (и възложени на външни изпълнители) ще изискват ресурси за обработка на заявката, преди да изпратят правилното изображение обратно. Това отнема скъпо време и по този начин забавя пътуването заявка-отговор. По-добро решение може да бъде, ако устройството само определя кой ресурс да се иска директно и сървърът реагира правилно.

Предни крайни решения

Напоследък има значителни подобрения от страна на браузъра за справяне с проблеми с отзивчиви изображения.

Елементът той е въведен и одобрен в спецификациите на HTML5 от W3C. Понастоящем не е наличен във всички браузъри, но няма да мине много преди това да се случи. Дотогава разчитаме полифилове Javascript за елемента. Polyfills също са чудесно решение за стари браузъри, които нямат този елемент.

Има и случая на атрибут srcset атрибут което е достъпно за различни базирани на браузър WebKits за елемента Това може да се използва без никакъв JavaScript и е чудесно решение, ако браузърите, които не са webKit, се игнорират. Това е добър временен ресурс за редкия случай, когато други решения не са достатъчни, но не трябва да се счита за цялостно решение.

как да се сформира консултативен съвет

Picturefill

Picturefill това е книжарница полифил за елемента. Това е една от най-популярните библиотеки в групата от предни решения за мащабиране на изображенията и свързаните с тях проблеми. Има две версии; Picturefill v1 имитира елемента, използвайки span докато Picturefill v2 използва елемента сред браузърите, които вече го имат и предоставя полифил за наследени (напр. за IE> = IE9). Има някои ограничения и смущения , най-вече за Android 2.3 - което между другото е пример за това как img srcset идва на помощ. Ето пример от надценка за използване на Picturefill v2:

За да се подобри производителността за потребители с ограничени планове за данни, Picturefill може да бъде в съчетание с мързеливо натоварване . Библиотеката обаче може да предложи по-широка поддръжка на браузъра и да обработва странни случаи, вместо да разчита на кръпки.

Imager.js

Imager.js е библиотека, създадена от екипа на BBC News за да се постигне, че отзивчивите изображения са имали различен подход от този, използван в Picturefill. Докато се опитва да донесе елемента в неподдържани браузъри, Imager.js се концентрира върху изтеглянето само на подходящите изображения, докато гледа скоростта на мрежата. Той също така включва лениво зареждане, без да разчита на изнесени библиотеки. Той работи чрез поставяне на елементи на заместител и ги заменете с елементи. Показаният по-долу код показва това поведение:

new Imager({ availableWidths: [480, 768, 1200] });

Изобразеният HTML ще изглежда така:

new Imager({ availableWidths: [480, 768, 1200] });

Поддръжката на браузъра е много по-добра от Picturefill с цената на по-прагматично решение от прогресивното.

Разбъркване на източника

Разбъркване на източника подхожда към този проблем от малко по-различен ъгъл от останалите библиотеки с преден край. Прилича на нещо извън мисленето „първо за мобилни устройства”, където по подразбиране обслужва възможно най-малката разделителна способност. Като открива кое устройство има най-големия екран, то променя източника на изображението на по-голям. Чувства се по-скоро като хак и по-малко като напълно израснала книжарница. Това е чудесно решение главно за мобилни сайтове, но това означава, че двойното изтегляне на ресурси за настолни компютри и / или таблети е неизбежно.

как да измерим ценова еластичност

Други забележителни JavaScript библиотеки са:

• HiSRC - jQuery плъгин за отзивчиви изображения. Разчитането на jQuery може да е проблем.

• Mobify.js - Обща библиотека за отзивчиво съдържание, включително изображения, таблици със стилове и дори JavaScript. „Заснемете“ dOM преди зареждането на ресурса. Mobify е мощна и всеобхватна библиотека, но може да бъде преувеличена, ако целта е просто да има отзивчиви изображения.

в обобщение

В края на деня, разработчикът трябва да реши кой подход да използва в отзивчив уеб дизайн от изображения за вашата потребителска база. Това означава, че събирането на данни и тестването ще ви дадат по-добра представа кой подход да използвате.

За да го закръглите, може да ви помогне да разгледате списъка с въпроси по-долу, преди да вземете решение за подходящото решение за отзивчиви изображения.

• Проблем ли са наследените браузъри? Ако не са, помислете за използването на по-модерен подход (например Picturefill, атрибут srcset).

• Критично ли е времето за реакция? Ако не е, отидете на back-end или външно решение.

• Трябва ли решенията да са вътрешни? Опциите, възложени на външни изпълнители, очевидно не може да става и дума.

• Има ли много изображения на сайта, които се опитват да преминат към отзивчиви изображения? Има ли опасения относно валидирането или семантичните етикети (или несемантични етикети)? Това ще изисква бекенд решение, което да насочва заявките за изображения към нещо като Адаптивни изображения.

• Проблем ли е посоката на изкуството (по-специално за големи изображения с много информация)? Библиотека като Picturefill може да е по-доброто решение за такъв сценарий. Също така, всяко от back-end решенията също може да работи.

• Има ли притеснения относно JavaScript? Всяко фронт-енд решение ще бъде изключено, оставяйки опции като back-end или outsourced, които разчитат на UA проследяване.

• Има ли приоритет за времето за реакция на мобилни устройства спрямо времето за реакция на работния плот? Библиотека като разбъркване на източници трябва да е най-подходящата за този случай.

• Необходимо ли е да се осигури отзивчиво поведение за всеки аспект на сайта, не само за изображенията? Mobify може да работи по-добре.

• Постигнат ли е идеалният свят? Така че използвайте само CSS приближение display:none!