5️ Методики для вмісту веб-сайту Lazy-Load для кращого & SEO & User Experience

Сценарії вмісту "Lazy-Load"
ЗМІ
Код
Копіювати
Обробка зображення Lazy Loaded
Що таке IntersectionObserver?
Розбиття / Неперервне прокручування
Використання API історії
Завантаження скриптів у міру необхідності
Загортання

Ледачі завантаження веб-сайтів активів для кращого користувальницького досвіду

Наша команда-партнер Artmisto

Швидкість веб-сайту є вирішальним аспектом на сторінці SEO Кожен може контролювати. Ваша мета - бути інтерактивним за три секунди, навіть на базовому телефоні через з'єднання 3G.

Однак більшість веб-сайтів мають так багато запитів і велику корисну навантаження, оскільки цей термін або бюджет не може бути досягнуто. Насправді, середня веб-сторінка займає 22 секунди для завантаження, згідно з дослідженнями Google.

Але що, якщо я сказав вам, що є спосіб розвантажити або навіть уникнути завантаження активів сторінки, поки вони не потрібні?

Це може дати вашому сайту явну перевагу над вашою конкуренцією, тому що Google не тільки полюбить ваші сторінки краще, аніж ваші відвідувачі!

Доброю новиною є те, що потрібно трохи JavaScript і навмисне прагнення оновити ваш сайт.

І Команда Пошуку Google - це все для цієї техніки , що називається 'lazy-loading'.

Короткий посібник Google зазначає три основні моменти:

Завантажити видимий вміст
Як підтримувати нескінченну прокрутку і розбиття
Як перевірити свою реалізацію

Хитрість полягає не в тому, щоб приховати вміст, який потрібно індексувати від Google. Отже, вони опублікували цей корисний, але тонкий путівник.

Вони також опублікували a Керівництво по використанню Intersection Observer для ледачого завантаження зображень і відео до тих пір, поки вони не з'являться.

Для середніх веб-сайтів, які обмінюються вмістом, наприклад блогом або маркетинговим сайтом, ледаче завантаження досить просте. Але для веб-додатків це може бути більш складним, і я буду занурюватися в деякі методи, я використовую для завантаження коду, як необхідно, щоб переконатися, що мої програми швидко і чуйно.

Я розгляну пункти, які пропонує Google, і надаю поради та приклади з власного досвіду, використовуючи IntersectionObserver і трохи про те, як працює API API.

Ледачі навантажувальні рекомендації оголюють своїм останнім керівництвом програми для однієї сторінки та SEO тому що це хороша техніка для покращення роботи користувачів веб-сайту.

Для більш складних веб-додатків, я буду торкатися техніки для завантаження скриптів на вимогу, а не спереду, що зберігає сторінку від рендеринга.

Сценарії вмісту "Lazy-Load"

Перш ніж додати на ваш сайт можливості для завантаження ледачих, вам слід інвентаризувати, які активи завантажують ваші сторінки, і визначити, що потрібно для початкового досвіду, і що можна завантажити, коли користувач починає читати чи взаємодіяти з вмістом.

Дозвольте мені повернутися до моїх двох основних сценаріїв веб-сайту, вмісту та додатків, оскільки потреби в змісті змінюються, але мають дублювання.

По-перше, веб-сайт із вмістом або продажем. Для простоти я просто назве це блогом. Ці сайти зазвичай потребують HTML, CSS, JavaScript, зображень і спеціальних шрифтів. Вони також, як правило, сайти ви хочете безкоштовний органічний трафік від Google, що означає, SEO є важливим.

За винятком того, щоб завантажувати сторінку швидше, потрібно переконатися, що вміст доступний павуку пошукової системи, яка не виконає ваш JavaScript або не прокрутить сторінку, щоб керувати вмістом, що завантажується леніво.

Вміст може посилатися на носій, код або копію (текст і розмітка).

ЗМІ

Зображення та відео - великі файли. Відмінне навантаження має негайний позитивний вплив на час завантаження сторінки.

Код

JavaScript, CSS, HTML і шрифти необхідні для візуалізації сторінок. Але сценарії та CSS можуть бути вашими найбільшими вузькими місцями для швидкого часу до першої взаємодії. Затримка їх завантаження робить ваш вміст набагато раніше.

Копіювати

Іноді потрібно відкласти завантаження вмісту сторінки та скопіювати її. Просто переконайтеся, що це важливо для SEO це доступно для павуків.

Для цього я покажу вам, як використовувати IntersectionObserver для завантаження активів, таких як зображення та відео, коли вони прокручуються у вікно перегляду. Але перед тим, як це зробити, нам потрібно налаштувати розмітку для індексації зображень і відео.

Складні веб-додатки можуть бути трохи делікатнішими, оскільки вони спираються на більшу логіку застосування. Це означає, що вони вимагають більше файлів JavaScript. Коли ці файли завантажуються, питання. Хоча ви можете використовувати IntersectionObserver для цього, вашому додатку потрібна хороша техніка для динамічного завантаження скриптів у міру необхідності. Пізніше в цій статті я дам вам саме це!

Обробка зображення Lazy Loaded

Хоча Google і Bing можуть виконувати JavaScript на вашій сторінці, вони не стають пріоритетними. Вони також не намагаються прокручувати сторінку, щоб ініціювати такі дії, як IntersectionObserver.

Це означає, що ваш завантажений вміст може не існувати.

Спочатку ви не можете вважати це великою угодою, але зображення SEO може бути ключовим фактором, який допоможе вам краще оцінити пошуки. Крім того, пошук зображень може бути прихованим джерелом додаткового органічного трафіку.

Секрет створення доступного павука вмісту полягає в тому, щоб приховати його за тегом notcript.

Я знаю, що в цьому прикладі багато коду, але я перехожу атрибути 'data-' у наступному розділі.

Те, що я хочу, щоб ви зосередилися на прямо зараз, є нористським елементом. Усередині цього елемента використовується традиційний елемент IMG з значенням src, встановленим у великому розмірі зображення.

Тепер пошукові павуки завантажують зображення та індексують його для вас.

Тег noscript - це семантичний механізм, за допомогою якого браузер може виводити вміст всередині елемента, лише якщо браузер (агент користувача) не підтримує JavaScript. Більшість відвідувачів увімкне JavaScript, тому вони не будуть ініціювати завантаження зображення спочатку. Але, як ви незабаром побачите, це станеться, коли невидимене зображення буде видно.

Тепер давайте поринемо в тому, як використовувати IntersectionObserver.

Що таке IntersectionObserver?

Відносно новий API браузера, IntersectionObserver підтримується всіма сучасними браузерами і є стабільний polyfil можна динамічно завантажувати для тих, хто цього не робить.

Цей API ініціює зворотний виклик, коли виходять цільові елементи. Цей зворотний виклик дозволяє виконувати код, який за нашим сценарієм є завантаженням активів за потребою.

Це простий API, але є кілька частин, які потрібно розібрати.

Спочатку, як створити IntersectionObserver:

var config = {// Якщо зображення потрапляє в межах 50px на осі Y, розпочніть завантаження. rootMargin: '50px 0px', поріг: 0.1}; imgObserver = новий IntersectionObserver (showImage, config); imgObserver.observe (yourImage);

IntersectionObserver завантажує вміст, оскільки він входить у вікно перегляду

Ви створюєте новий об'єкт IntersectionObserver, передаючи метод зворотного виклику і об'єкт конфігурації. Пізніше я розкриваю зворотний виклик.

Параметри конфігурації повідомляють спостерігачеві, наскільки близьким до видимого вікна є спостережуваний елемент, перед запуском методу зворотного виклику. Значення rootMargin вказує, який розмір елемента може бути вертикально і горизонтально.

У моєму прикладі я повідомляю спостерігачеві, щоб він викликав зворотній виклик, коли спостережуваний елемент знаходиться в межах 50 вертикальних пікселів вікна перегляду. Я встановлюю горизонтальну позицію на 0, оскільки я рідко використовую горизонтальну прокрутку.

Зворотний виклик буде стріляти протягом 100 мс, оскільки поріг встановлений на 0,1 секунди.

Тут я спростив метод 'спостереження', але зазвичай вибираю всі елементи певного виду і перебираю результати. Тут я показую лише одне зображення.

Кожен елемент, який ви хочете спостерігати за цим спостерігачем, повинен бути доданий окремо. Ось чому я перекриваю результати, тому що кожне зображення, відео або будь-яке інше потрібно явно додати.

Метод зворотного виклику є логікою, яка запускається, коли переглядається елемент, що спостерігається.

Метод зворотного виклику отримує два параметри: цілі, які викликали зворотний виклик (теоретично більше одного може задовольняти ваші пороги одночасно) і посилання на фактичного спостерігача.

Записи аналогічні типовому об'єкту обробника подій. Щоб отримати доступ до фактичного елемента DOM, ви посилаєтеся на цільове значення запису. Об'єкт також має властивості isIntersecting і intersectionRatio, які можна використовувати, щоб визначити, чи хочете ви діяти на елементі чи ні.

У цьому прикладі я перевертаю атрибути даних до їх відповідного атрибуту зображення, що призводить до відображення зображення. Оскільки я завжди використовую відповідні зображення, потрібно перевернути атрибути data-srcset, data-src і data-sizes.

До цих пір я використовував цю техніку з зображеннями, відео та картами на різних сайтах.

Якщо ви дивуєтеся, я роблю це з усіма своїми зображеннями, навіть з зображеннями, що видаються "над складовою". Незважаючи на невелику затримку в рендерінгу зображень, це не впливає на мій UX. Основний вміст завантажується надшвидко, особливо на мобільний.

Зображення завантажуються, тому що IntersectionObserver для цих вище елементів складки задовольняється і негайно спрацьовує. Він не вимагає перегляду зображення для перегляду.

Говорячи про перегляд, функція безперервного прокручування також може бути полегшена за допомогою IntersectionObserver.

Розбиття / Неперервне прокручування

Розбиття та неперервна прокрутка

Деякі цікаві вказівки від Google, які привернули мою увагу останнім часом, це те, як боротися зі списками сторінок і безперервним досвідом прокрутки.

По-перше, безперервний свиток.

Це стало загальною тактикою на сайтах, пов'язаних з новинами, за останні пару років. Тут ви можете прокрутити статтю, і коли ви досягнете нижньої частини, ви побачите нову статтю. Ця методика дійсно народилася з соціальних медіа, таких як Twitter і Facebook, що дозволяє прокручувати повідомлення після публікації, поки ви не вийшли після сну.

Ви можете використовувати IntersectionObserver для перегляду елемента, можливо, останній абзац-два, щоб дізнатися, коли читач закінчує статтю. Оскільки ці нижні елементи прокручуються у вікно, ви можете скористатися функцією fetch, щоб отримати наступну статтю та додати її нижче поточної статті. Ви також хочете використовувати API історії, яку я коротко розгляну, щоб оновити URL-адресу.

Інший сценарій - індекс списків, як, наприклад, налаштування сторінок мого блогу. Кожна сторінка відображає 20 карт або записів до блогу. У нижній частині знаходиться стандартний розділ "pagination" з посиланнями на попередню та наступну сторінки за номером.

У безперервному сценарії прокрутки Google не буде ініціювати наступну статтю. Так що просто знайте про це.

Замість цього ви можете перелічити відповідні статті, як я роблю на цьому сайті, нижче статті. Якщо ви дійсно хочете отримати безперервний досвід прокрутки, ви можете приховати пов'язані статті за елементом noscript, використовуючи техніку, яку я описав раніше.

Для пейджинга Google пропонуємо створити велику сторінку з усіма переліченими посиланнями. Ви можете використовувати канонічний тег, щоб вказати на цю первинну сторінку з кожної сторінки індексу. Таким чином, Google не намагатиметься індексувати ці сторінки, які мають мало реальної цінності для пошуку.

Використання API історії

Історія API, і я не маю великої історії, добре, це трохи мовою в щоку, але правда. Я особисто не використовував цей API, тому що мій перший досвід роботи з цим API, майже 7 років тому, був жахливим.

Останнім часом я розглядаю його знову, оскільки Google рекомендував його в декількох останніх статтях. І я повинен визнати цей другий раз, коли він відчуває себе "краще" і корисним.

Я не буду “забруднювати вас своїм первинним досвідом, але охоплювати те, що це означає сьогодні.

Я згадав про його використання в секції безперервного прокручування, оскільки Google рекомендує використовувати його в цьому сценарії. Але якщо ви керуєте досвідом застосування однієї сторінки, ви також повинні використовувати цей API.

=> Вставити графіку адресного рядка

Основною перевагою, яку він надає, є можливість змінити URL-адресу в адресному рядку, не запускаючи запит на сервер, що викликає повне перезавантаження сторінки. Він багато в чому схожий на техніку хеш-фрагментів, але використовує URL для спільного використання.

var stateObj = {foo: "bar"}; history.pushState (stateObj, "сторінка 2", "bar.html");

У прикладі коду можна побачити метод pushState історії має три параметри: стан, ім'я та URL. Для наших цілей ви можете передати null на перші два параметри, URL є важливим значенням.

Зміна URL-адреси змінює URL-адресу в адресному рядку, але, як я вже згадував, не буде викликати запит на сервер. У безперервному сценарії прокрутки потрібно зробити виклик AJAX у фоновому режимі і ввести отриманий HTML в DOM, трохи нижче поточної статті або елемента. Після зміни URL-адреси користувач побачить реальну URL-адресу нової статті, і якщо вони розділять URL-адресу, це буде прямим посиланням на сторінку статті.

Просто переконайтеся, що URL, який ви передаєте методу pushState, є справжньою посиланням на нову статтю!

Також потрібно переконатися, що код зворотного виклику IntersectionObserver ініціює оновлення в будь-який момент, коли цільовий елемент прокручується в активний вигляд, щоб змінити URL-адресу, щоб він відповідав прямій сторінці елемента. Наприклад, якщо я прокручую сторінку назад.

Що Google дійсно підштовхує до вас, використовує реальну URL-адресу, але URL-адресу, керовану JavaScript. У сценарії безперервного прокручування, коли тригери IntersectionObserver можна завантажити нову статтю і змінити URL-адресу динамічно. Тепер користувач побачить URL-адресу нової статті і може перезавантажити сторінку.

Тепер ваші URL-адреси синхронізовані, і Google побачить пряму URL-адресу, коли вона знайде посилання й т.д.

Завантаження скриптів у міру необхідності

Якщо ви знаєте мене, ви знаєте, що я рекомендую використовувати як можна менше JavaScript. Для тематичних сайтів, подібних до цього, я часто можу позбутися 15 кб або менше після стиснення. Але веб-програми можуть швидко підірвати це.

Отже, як утримувати надмірний JavaScript від підривання вашого користувальницького досвіду?

По-перше, використовуйте тільки те, що вам дійсно потрібно. Наприклад, Netflix зменшив середній час відтворення 50% після усунення React з їх переднього кінця і обмеження до візуалізації на стороні сервера (SSR).

А як щодо тих часів, коли вам потрібна бібліотека, щоб керувати вашим досвідом застосування?

Завантажуйте їх, коли вони потрібні, і тільки тоді, коли вони потрібні.

Це вимагає трохи витонченості, але може зробити ваш UX набагато кращим, що повинно поліпшити задоволеність клієнтів і збереження, одночасно зменшивши виклики служби підтримки.

Хто не хоче цих КПІ ?!

Я використовую цю техніку, щоб завантажити всі мої сценарії, я називаю це завантаження досвід. Але ви можете поширити його на ліниві завантажувальні скрипти на вимогу.

Ось скрипт, і ніхто його не створив, команда Chrome спочатку поділилася ним:

спробуйте {var scripts = [{{{scripts}}}], src, pendingScripts = [], firstScript = document.scripts [0]; // polyfil чеки і навантаження тут, якщо (typeof IntersectionObserver === "undefined" || IntersectionObserver.toString (). indexOf ("[рідний код]") === -1) {scripts.unshift ("js / libs / polyfil / intersection-observer.js "); } // Дивитися сценарії завантаження в функцію IE stateChange () {// Виконайте стільки скриптів, скільки ми можемо вар pendingScript; while (pendingScripts [0] && pendingScripts [0] .readyState == 'завантажується') {pendingScript = pendingScripts.shift (); // уникати майбутніх завантажень подій з цього скрипта (наприклад, якщо зміни в src) pendingScript.onreadystatechange = null; // не може просто appendChild, стара помилка IE, якщо елемент не закритий firstScript.parentNode.insertBefore (pendingScript, firstScript); } console.log ("скрипти повинні бути завантажені зараз"); } // циклічний перегляд наших URL-адрес сценарію (src = scripts.shift ()) {if ('async' у firstScript) {// сучасний скрипт браузерів = document.createElement ('script'); script.async = true; script.src = src; document.body.appendChild (сценарій); } else if (firstScript.readyState) {// IE <10 // створюємо скрипт і додаємо його до нашого скрипта todo pile = document.createElement ('script'); pendingScripts.push (скрипт); // прослуховувати зміни стану script.onreadystatechange = stateChange; // необхідно встановити src ПОСЛЕ додавання слухача onreadystatechange // інакше ми пропустимо завантажену подію для кешованих скриптів script.src = src; } else {// повернемося до відкласти document.write ('<script src = "' + src + '" defer> </' + 'script>'); }}} catch (error) {alert (error)); }

Я зменшив його, як саме завантажувати поліфіл IntersectionObserver, оскільки я розглянув його у цій статті. Але хитрість полягає в тому, щоб створити масив скриптів, які потрібно завантажити з кожним, у розумному порядку для управління залежностями.

Примітка: сценарій використовує Нотація вуса , отже поле {{{script}}} у верхній частині скрипта, щоб ввести посилання на залежність скрипту сторінки.

Вам не доведеться турбуватися про завантаження асинхронних або відкладених файлів, оскільки всі ці скрипти завантажуються за запитом, що має бути після відображення основного вмісту.

Основною сутністю логіки тут є створення елемента сценарію для кожного сценарію та додавання його до DOM. Після додавання браузер завантажує скрипт так само, як якщо б він був частиною початкової розмітки.

Я використовую цю техніку для завантаження поліфілів, якщо і коли вони потрібні. Але ви можете скористатися цією технікою для завантаження сценаріїв, як це вимагає дія користувача. Замість polyfil, можливо, вашій програмі потрібна бібліотека, але не до тих пір, поки не буде виконано певний критерій або дія користувача.

Тепер замість того, щоб затримувати час до першої взаємодії на 1-5 секунд (або більше), ви можете розвантажити цю продуктивність і UX-удар доти, доки це не потрібно. Або, можливо, ви використовуєте це для завантаження скриптів, коли потік інтерфейсу неактивний (користувач не робить нічого активного), тому він не заважатиме реальному досвіду користувача.

Загортання

Існує безліч причин, чому вміст сторінки ледачого завантаження допомагає створити кращий досвід користувача. Основною перевагою є більш швидкий час взаємодії або покращена швидкість сторінки. Але правильне керування лазі-завантаженням може дати вам перевагу SEO і UX.

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

Google винагороджуватиме швидші веб-сторінки з кращими рейтингами, але тільки якщо їхні павуки можуть отримати доступ до ледачого вмісту. Для цього потрібно належним чином кодувати сторінки, щоб зробити ледачий вміст доступним, навіть якщо JavaScript не ввімкнено, що є типовим для павуків пошукових систем.

Перехресний спостерігач і API історії можна використовувати для керування завантаженням вмісту та активів у разі потреби без порушення користувацького досвіду. Ці інструменти можуть збільшити складність вашого сайту, і ви повинні протестувати або переконатися, що ці зміни не порушують роботу користувача.

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

Але що, якщо я сказав вам, що є спосіб розвантажити або навіть уникнути завантаження активів сторінки, поки вони не потрібні?
Що таке IntersectionObserver?
Отже, як утримувати надмірний JavaScript від підривання вашого користувальницького досвіду?
А як щодо тих часів, коли вам потрібна бібліотека, щоб керувати вашим досвідом застосування?
Хто не хоче цих КПІ ?

Категории

Новости