Ефективність адаптивних веб-сайтів
Був час, коли можна було з упевненістю відрізнити веб-сторінку для комп’ютера від веб-сторінки для мобільних пристроїв. Фактично настільки, що ціла індустрія виросла навколо перепрофілювання сайтів для настільних комп’ютерів для мобільних пристроїв.
Деякий час ви були ніким, якщо у вас не було окремого мобільного сайту в окремому домені. Потім все почало змінюватися.
Мобільні дисплеї вдосконалені до невпізнання. Так само зробили мобільні браузери. Таблетки додали ще один елемент у рівняння. З’явився 4G. Дисплеї Retina пропонують новий рівень чіткості для кінцевих користувачів.
Раптом межа між настільним комп’ютером і мобільним пристроєм стала розмитою.
У той же час зростала різноманітність розмірів і роздільної здатності настільних дисплеїв.
І зростаючий головний біль для веб-дизайнерів.
Минули ті часи, коли вам потрібно було обслуговувати лише кілька розмірів вікна перегляду. Справи ускладнювалися.
На щастя, допомога була під рукою у вигляді медіа-запитів і концепції адаптивного дизайну.
Завдяки медіа-запитам стало можливим змінювати стилі та макет – навіть вміст – залежно від ширини вікна перегляду та роздільної здатності екрана. Звісно, медіа-запити — аж ніяк не єдиний інструмент у наборі хитрощів адаптивного дизайнера, але справедливо сказати, що вони складають основу техніки.
Це була чудова новина для мобільних пристроїв. Адаптивний дизайн означає, що ви можете ефективно доставляти різні версії одного сайту на різні пристрої. І все без розробки окремого мобільного сайту в іншому домені.
Що щодо продуктивності?
Власники сайтів починають розуміти, що кінцеві користувачі дбають про продуктивність. Зокрема, роздрібні торговці починають розуміти, що скорочення часу завантаження в мілісекундах може призвести до мільйонів на балансі.
На щастя, адаптивні сайти пропонують одну очевидну перевагу в продуктивності порівняно зі своїми спеціальними мобільними братами: усувається переспрямування на мобільний домен.
Однак, незважаючи на це, адаптивний дизайн зумів придбати репутацію низької продуктивності.
У певному сенсі це досить несправедливо, але варто звернути увагу на додаткові проблеми з продуктивністю, які чуйний дизайн створює для необережних…
Зображення
Файли зображень великі. І оскільки вони великі, вони часто винні в повільному завантаженні. Тому вони є хорошим місцем для початку для тих, хто намагається оптимізувати продуктивність сайту.
На жаль, одне з перших рішень для адаптивної доставки зображень не було чудовим для продуктивності.
Техніка неймовірно проста. Просто використовуйте max-width: 100%, щоб переконатися, що зображення масштабуються відповідно до ширини елемента, що містить:
img
{
max-width: 100%;
}Оскільки контейнер зменшується, щоб відповідати меншим вікнам перегляду, усі зображення всередині зменшаться разом із ним. легко!
Але є проблема. Розмір зображення може зменшуватися на екрані, але розмір файлу залишається незмінним. Це далеко не ідеально з точки зору продуктивності. Ви можете надсилати зображення розміром 800 x 800 пікселів по дроту, щоб воно відображалося у розмірі 80 x 80 пікселів: іншими словами, ви можете передати сотні (або тисячі) непотрібних байтів. Мало того, що зображення завантажуватиметься довго, всі ці зайві байти можуть виснажувати цінні дані кінцевого користувача.
Однак це не єдиний і навіть не найкращий спосіб створення адаптивних зображень. З одного боку, зображення, яке працює з шириною 800 пікселів, не обов’язково буде добре працювати з різними фракціями такого розміру.
Щоб упоратися з цим, ви можете використовувати медіа-запит для відображення різних версій зображення залежно від розміру вікна перегляду за допомогою медіа-запиту та display: none.
CSS:
@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}HTML:
![]()
![]()
Це дозволяє відображати різні версії зображення, а не просто те саме зображення в різних розмірах. Однак це не зменшує кількість байтів. Насправді загальний розмір сторінки буде більшим, оскільки всі зображення будуть завантажені, незалежно від того, відображаються вони чи ні.
Кращою альтернативою – якщо це практично – є використання фонових зображень замість
@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}Це добре працює: відвідувачі завантажують лише ті зображення, які їм потрібні, коли вони їм потрібні. Проблема в тому, що він неохайний, фактично трактуючи вміст як стиль. Таким чином, це потенційно створює проблему ремонтопридатності, а також може призвести до того, що пошукові системи ігноруватимуть важливі зображення.
Натомість чому б не використати SVG (масштабована векторна графіка): формат зображення, який масштабується за своєю природою? Зображення SVG також мають перевагу в тому, що їх легко стилізувати за допомогою CSS (перегляньте цей чудовий посібник про адаптацію SVG за допомогою CSS). Це ідеально підходить для піктограм і логотипів, але, на жаль, ви не зможете використовувати SVG для фотографій – для них вам доведеться вдатися до растрових форматів, таких як JPEG.
Іншим варіантом є використання одного з ряду рішень JavaScript для надання адаптивних зображень. Це популярний спосіб зробити це, але він додає ще один рівень складності. Більше того, оскільки JavaScript блокує конструкцію DOM, будь-яке рішення, що включає JavaScript, може призвести до затримки відтворення. Отже, хоча є кілька дуже розумних плагінів, просто додавши JavaScript до рівняння, ви певною мірою змиритеся з меншим із двох зол.
Донедавна це були єдині варіанти.
Однак тепер елементи and
У цьому дивовижному новому світі ви можете використовувати srcset, щоб створити список зображень-кандидатів для вибору браузером. Потім ви можете використовувати медіа-запит в атрибуті sizes, щоб вказати розмір, у якому відображатиметься зображення. Використовуючи елемент разом із медіа-запитами в одному чи кількох елементах, ви можете вказати різний діапазон зображень для різних умов (наприклад, для вікон перегляду до певної ширини використовуйте зображення a, b або c, а для більших вікон перегляду використовуйте зображення x, y або z). Це корисно, якщо вам потрібно доставити обрізану версію зображення для користувачів із маленькими екранами.
Точні деталі того, як використовувати новий синтаксис, виходять за межі цієї статті, але ви можете знайти чудовий посібник на alistapart.
Можливо, єдиним недоліком цієї нової специфікації є те, що вона досить довгострокова, що може означати роздутий HTML на сторінках із великою кількістю зображень. Однак переваги значно переважують недоліки.
Завантаження CSS, який вам (обов’язково) не потрібен
Хоча медіа-запити дозволяють застосовувати різні правила CSS залежно від встановлених вами критеріїв, неможливо уникнути того факту, що кінцевим користувачам доведеться завантажити всі CSS, які можуть застосовуватися. Це вірно, навіть якщо ви розміщуєте свій CSS в окремих файлах і розміщуєте медіа-запит в
елементі.Наприклад, обидві наступні таблиці стилів будуть завантажені, незалежно від ширини вікна перегляду:
Це не помилка браузера. Критерії, які використовуються в медіа-запитах, часто стосуються речей, які змінюються під час відвідування сторінки. Наприклад, відвідувач може вирішити змінити розмір вікна браузера або повернути свій планшет/мобільний пристрій. Результуюча зміна у відображенні має бути безперебійною, і відправлення запиту на інший файл CSS було б далеко не ідеальним. Особливо це стосується мобільних пристроїв, які прагнуть закрити радіозв’язок за першої нагоди, щоб зберегти заряд акумулятора. Потенційна необхідність повторного встановлення цього зв’язку, коли розмір вікна перегляду змінюється, може бути поганою новиною для роботи батареї.
Однак Chrome докладає зусиль, щоб працювати з цими різними файлами розумним способом. У той час як усі файли будуть завантажені, лише той, який зараз відповідає медіа-запиту, блокуватиме рендеринг. Усі інші завантажуватимуться з нижчим пріоритетом.
На жаль, інші браузери не настільки зобов’язують. У Firefox, наприклад, файли CSS, які не використовуються, не просто блокують візуалізацію – вони також блокують завантаження інших об’єктів на сторінці.
Наведена нижче діаграма водоспаду ілюструє це. Зображення на цій сторінці не почнуть завантажуватися, доки не буде повністю завантажено невикористаний файл CSS:
Ви можете обійти це, використовуючи JavaScript для умовного завантаження CSS, але, як ми вже бачили, JavaScript має власні витрати на продуктивність.
Що все це означає для продуктивності адаптивного сайту порівняно з мобільним сайтом?
Що ж, користувачам мобільних пристроїв і користувачам комп’ютерів на адаптивному сайті доведеться завантажити той самий CSS.
І його буде більше, ніж на сайті, призначеному лише для комп’ютера чи мобільного пристрою.
Більше того, спеціалізований мобільний сайт, швидше за все, використовуватиме полегшену, урізану версію настільного CSS (хоча зараз це, можливо, менш вірно, оскільки користувачі все частіше очікують більшого досвіду на все більш складних мобільних дисплеях).
Таким чином, за інших рівних умов, схоже, є щось в аргументі, що адаптивний сайт, швидше за все, буде повільнішим, ніж мобільний сайт, через потрібний додатковий CSS. Однак, якщо дизайнери знають про потенційні підводні камені, вони повинні мати можливість створювати швидкозавантажувальні таблиці стилів для адаптивного сайту. Зокрема, доцільно:
-
уникайте використання URI даних для зображень – двійкові фонові зображення (зазвичай) завантажуватимуться лише якщо/коли вони потрібні, але всі URI даних завантажуватимуться незалежно від цього. -
тримайте його легким – оскільки весь CSS потрібно завантажити, важливо бути ефективним. Це означає уникати дублювання та переконатися, що глобальні правила встановлюються за межами CSS, керованого медіа-запитами.
RESS (адаптивний веб-дизайн + серверні компоненти)
RESS — це гібрид між чуйним і адаптивним дизайном, який передбачає пошук агентом користувача на сервері для перегляду характеристик клієнтського пристрою та доставки вмісту, який відповідає йому.
Якщо одним із заперечень проти адаптивного дизайну є те, що він передбачає доставку всього вмісту на всі пристрої, чому б не пом’якшити це, вирізавши частину цього вмісту, де це можливо?
Це може мати великий сенс. Якщо є зображення, яке ви ніколи не захочете відображати на пристроях, екран яких менший за певний розмір, ви можете також не надсилати його на ці пристрої, заощаджуючи пропускну здатність і скорочуючи час завантаження.
Більше того, якщо ви використовуєте медіа-запити, які, як ви знаєте, не можуть бути задоволені на певних пристроях, є принаймні аргумент для того, щоб розділити ваш CSS на різні файли та завантажувати їх умовно.
Варто мати на увазі, що весь цей процес не є «безкоштовним» з точки зору продуктивності. Певна робота, очевидно, повинна бути виконана на сервері, що потребує часу – ймовірно, недостатньо, щоб переважити переваги, але це те, що потрібно знати.
Вирок
Чи повільно реагують сайти?
Це залежить від того, що ви маєте на увазі під повільним.
Чи найшвидший адаптивний сайт, який ви можете створити, буде повільнішим, ніж найшвидший спеціальний сайт для мобільних пристроїв, який ви можете створити?
Ймовірно.
Ми також побачили, що є кілька підводних каменів. Якщо ви не будете обережні, можна легко змусити користувачів завантажувати багато зайвих зображень і CSS, що зробить ваш адаптивний сайт набагато повільнішим, ніж потрібно.
Однак це не повинно бути саме так. Цілком можливо створити адаптивний сайт, який буде настільки швидким, наскільки це потрібно, і забезпечуватиме чудову взаємодію з користувачем. І оскільки і стандарти, і браузери починають наздоганяти те, що хочуть розробники, це має стати легшим.
Джерело запису: instantshift.com