Видалити AMP і не впливають на рейтинг SEO, органічний трафік, продуктивність

Видалення AMP
SEO і органічні трафік результати видалення AMP
Попередня вибірка веб-сторінок для миттєвого перегляду
Тестування мобільного користувача
Налаштуйте HSTS
Кеш все з Cloudflare CDN
Оптимізуйте досвід завантаження зображень
Попередньо завантажте версію з низьким дозволом
Перегляньте залежності
Значення порівняно з ціною
Резюме

Раніше я рекомендував Сторінки Google AMP як надійний спосіб підвищити рейтинг сайту SEO і органічних відвідувачів трафіку. Нещодавно я видалив AMP з мого веб-сайту. У цьому блозі я опишу, як це вплинуло на мій блог і кілька більш просунутих методів оптимізації веб-продуктивності, які я використовую замість фірмового стандарту, як Accelerated Mobile Pages.

Видалення AMP

Як це зробити

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

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

Ви повинні почати з налаштування перенаправлення з AMP версії сторінки на стандартну. У моєму випадку це було зроблено з використанням простої директиви NGINX:

розташування ~ ^ / amp /(.*)$ {return 301 / $ 1; }

Крім того, переконайтеся, що маєте правильний rel = "canonical", що вказує на AMP версію сторінки на початкову. Коли ви працюєте, ви можете видалити rel = "amphtml" та змінити запит у консолі пошуку Google.

Через пару днів ваші сторінки AMP почнуть зникати з мобільного SERP.

SEO і органічні трафік результати видалення AMP

Сторінки AMP пройшли з мого блогу близько місяця під час написання цієї посади. Має бути достатньо часу, щоб побачити деякі ефекти на трафік.

Я не помітив негативного впливу на позицію SERP та кількість органічних перевезень.

Червона точка вказує дату, коли я вилучив підтримку AMP з цього блогу

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

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

Попередня вибірка веб-сторінок для миттєвого перегляду

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

Кожен пост в цьому блозі посилається на попередній і наступний. Я використовую наведені нижче теги посилань для попереднього завантаження вмісту HTML у сусідніх публікаціях:

Кожна сторінка HTML важить близько 10 кб, так що навіть на мобільних пристроях це незначні накладні витрати.

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

Я помітив, що попереднє завантаження надійно працює на робочому столі Chrome і мобільних браузерах Android. Він пропонує миттєвий досвід навігації, навіть якщо з'єднання погано. На жаль, це не впливає на iPhone, настільні Safari або Firefox. Chrome є найпопулярнішим веб-переглядачем.

Тестування мобільного користувача

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

я використовую Кондиціонер мережі Link перевірити, як мої веб-сайти працюють у поганих умовах мережі:

Якщо ви хочете створювати швидкі веб-сайти, використовуйте повільний Інтернет

Налаштуйте HSTS

З такими інструментами Давайте шифрувати і Cloudflare пропонуючи безкоштовні SSL / TLS сертифікати, немає жодної причини, чому будь-яка частина вашого веб-сайту повинна обслуговуватися через звичайний HTTP.

Додавання заголовка HSTS (HTTP Strict Transport Security) є простим способом уникнути непотрібних переадресацій на стороні сервера, коли користувач вводить URL вашого сайту безпосередньо в браузер.

Без перенаправлення заголовка HSTS буде виконано за допомогою коду HTTP 301, перенаправлення версії HTTP на HTTPS. Якщо у вас є заголовок HSTS на місці, переадресація буде зроблена на стороні клієнта, зменшуючи одну повну мережу і, таким чином, покращуючи початковий досвід користувача.

Крім того, ви можете надіслати свій веб-сайт Список попереднього завантаження HSTS щоб відвідувачі перенаправлялися до версії HTTPS за умовчанням, навіть якщо вони ще не відвідували ваш веб-сайт раніше.

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

Кеш все з Cloudflare CDN

Я використовую Cloudflare як CDN для цього блогу. За замовчуванням кешується лише кеш статичні ресурси .

У цьому випадку кожен відвідувач повинен буде завантажити веб-сайт HTML з сервера VPS, розташованого в США. Це означає повну мережу туди й назад до США, незалежно від їх географічного розташування, лише щоб побачити щось на екрані.

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

Заголовки кешу Cloudflare і конфігурація правил сторінки

Щоб працювати, я використовую наступну конфігурацію NGINX:

(?: ico | css | js | gif | jpe? g | png) $ {закінчується 8d; add_header Кеш-контроль "public"; try_files $ uri = 404; } location / {закінчується 15 м; add_header Кеш-контроль "public"; try_files $ uri $ uri .html $ uri / /404.html; }

Я можу кешувати статичні ресурси протягом 8 днів Статистика сторінки Google щасливий. я використовую jekyll-активів для додавання дайджесту md5 до імені файлу на основі вмісту, тому застарілий кеш не є проблемою.

Після кожного розгортання я запускаю наступний скрипт Ruby, який очищає кеші Cloudflare для статичних сторінок HTML:

вимагати "sitemap-parser" вимагати "http" відповідь = HTTP. заголовки ("X-Auth-Email" => ENV. fetch ("CLOUDFLARE_EMAIL"), "X-Auth-Key" => ENV. fetch ("CLOUDFLARE_API_KEY"), "Content-Type" => "application / json" ). post ("https://api.cloudflare.com/client/v4/zones/ # {ENV. fetch ('CLOUDFLARE_ZONE_ID')} / purge_cache", json: {файли: SitemapParser. new ("./docs/sitemap. xml "). to_a})

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

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

Більшість відвідувачів цього блогу, ботів чи ні, є з США

Нещодавно я переніс сервер VPS мого бічного проекту Abot Slack Bot до США. Хоча Abot користувачі розкидані по всьому світу, бот сам підключається до API Slack Американські сервери для кожної команди. Скорочення відстані в бічних мережах значно збільшило час відгуку.

Оптимізуйте досвід завантаження зображень

Відображення заповнювача

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

Якщо ви знаєте співвідношення зображень, ви можете скористатися простим трюком CSS, щоб запобігти «стрибку» навколишнього вмісту, коли зображення нарешті завантажено:

<div class = "main-image-placeholder"> <img src = "/images/image.jpg"> </div> .main-image-placeholder {position: relative; нижнє покриття: 61%; / * відношення висоти зображення до ширини * / висоти: 0; переповнення: приховано; колір: #eee; фоновий колір: #eee; } .main-image-placeholder img {position: absolute; зверху: 0; ліворуч: 0; ширина: 100%; }

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

Попередньо завантажте версію з низьким дозволом

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

(функція () {Array. prototype. slice. call (документ. getElementsByClassName ('js-async-img')) дляEach (функція (asyncImgNode) {var fullImg = new Image () fullImg. src = asyncImgNode. onload = function () {asyncImgNode. classList. видалити ('js-async-img') asyncImgNode. src = asyncImgNode. набір даних: src};});}) ();

Відповідний вузол HTML img:

45 kb Elk проти 4 kb Elk

Перегляньте залежності

Передозування зовнішніх розміщених бібліотек JavaScript третьої сторони є найпростішим способом знищити продуктивність вашого веб-сайту. Стандарт AMP не дозволяє вам їх взагалі включати. Я хотів би запропонувати середній підхід.

Видалення ще одного <script src = "..."> може здатися не дуже важливим. Легко забути, що один тег скрипта може привести до каскаду запиту, кожен з яких містить більше скриптів і ресурсів. Давайте подивимося на вартість вбудовування зразків бібліотек JavaScript третьої сторони:

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

3 МБ і 16 запитів проти двох десятків рядків HTML + CSS

Врешті-решт, я вирішив, що Disqus - єдина бібліотека JavaScript у важкій вазі третьої сторони, яка пропонує достатньо значення для вбудовування її в цей блог. Можливо, якщо б я використовував SUMO повноекранні спливаючі вікна та інші інструменти перетворення, було б доцільно додати ці 3 Мб пропускної здатності.

[Оновлення] Я переніс мою систему коментарів на легкий Коментар .

Значення порівняно з ціною

Я хочу сказати, що дуже легко пропустити ціну продуктивності включення залежностей JavaScript і, отже, зіпсувати досвід перегляду користувача.

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

Навпаки, 8 додаткових запитів і майже 200 kb для інтерактивної кнопки щебетати не виглядають як хороший компроміс.

Запити, видані під час включення бібліотеки JavaScript Sumo

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

Резюме

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

Я реалізував всі оптимізації, які я описав вище Шаблон Jekyll SEO . Ви можете завантажити його безкоштовно. Це стандартне лікування для електронної пошти.

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

Ico | css | js | gif | jpe?