Простые и полезные советы, которые позволят вам максимально разогнать сайт без необходимости закапываться в метриках Google PageSpeed и Lighthouse.
JavaScript
- Вместо JavaScript старайтесь чаще использовать HTML5 теги: <input type=date>, <input type=time>, Details/Summary и т.д.
Мы очень часто забываем или даже не знаем о готовых решениях встроенных в браузеры, которые лучше будут работать под разными устройствами и которые не требуют дополнительного JavaScript кода. - Используйте минификацию JavaScript кода.
- Постарайтесь вынести весь ваш JavaScript код в футер или отложенную загрузку и чем меньше JavaScript будет в <head>, тем лучше будут показатели в Google PageSpeed.
- <script src="путь-к-файлу"> требует дополнительного обращения к серверу, помните об этом.
Если вместо JavaScript файла, вставить в футере содержимое файла:
<script> содержимое файла </script>
Тогда первая загрузка будет быстрее, но не будет кэширования JavaScript файла.
Отложенная загрузка
- Используйте ленивую (отложенную) загрузку для изображений, iframe, video, audio, javascript и других подобных объектов. Ее стоит включать для элементов, которые находятся в попапах или на втором и следующих экранах на странице.
Для этих целей есть множество библиотек: lazyload, lazysizes, autoload и т.д. - В Chrome можно использовать нативную ленивую загрузку.
- ВК предлагает размещать подключение JavaScript кода в <head> для работы их виджета комментариев, но это понижает Google PageSpeed и скорость загрузки страницы.
Вместо кода, который предлагает ВК:
<!-- Put this script tag to the <head> of your page --> <script type="text/javascript" src="https://vk.com/js/api/openapi.js?162"></script> <script type="text/javascript"> VK.init({apiId: ID, onlyWidgets: true}); </script> <!-- Put this div tag to the place, where the Comments block will be --> <div id="vk_comments"></div> <script type="text/javascript"> VK.Widgets.Comments("vk_comments", {limit: 10, attach: "*"}); </script>
Вставляем чуть измененный код под отложенную загрузку:
<div id="vk_comments"></div> <script onload="showvk()" data-aload data-original="https://vk.com/js/api/openapi.js?162"></script> <script> function showvk() { VK.init({apiId: ID, onlyWidgets: true}); VK.Widgets.Comments("vk_comments", {limit: 10, attach: "*"}); } </script>
В результате получаем код, который загрузится только когда экран долистает до виджета.
Код карты, который предлагает вставить Google на сайт:
<iframe src="https://www.google.com/maps/embed?pb=!1m14" width="600" height="450" frameborder="0" style="border:0;" allowfullscreen=""></iframe>
Если карта находится в попапе или далеко в футере, то человек зайдя на вашу страницу, сразу же начнет подгружать очень много лишнего из этого фрейма и скорость загрузки подобной страницы будет очень низкой, Google PageSpeed вам поставит минус и большой!
Вставляем чуть измененный код под отложенную загрузку:
<iframe data-aload data-original="https://www.google.com/maps/embed?pb=!1m14" width="600" height="450" frameborder="0" style="border:0;" allowfullscreen=""></iframe>
Все сводится к тому, чтоб не давать браузеру src="" сразу, а только когда человеку это реально понадобится. И так со всеми объектами!
Jquery
- Если есть возможность, то не используйте Jquery у себя в проектах и это значительно повысит скорость вашего сайта, но если уже используете, то постепенно заменяйте на чистый нативный JavaScript.
- Если вы подключаете Jquery в <head>, то это блокирует отображение страницы, так как браузер ожидает пока загрузится все что находится в <head>, а уж потом показывает страницу. Но так как сама библиотека маленькая, а инет у всех быстрый, то это слабо влияет на скорость, гугл если и понижает рейтинг, то примерно 0.5, хотя раньше 10 или 20 очков снимал за такое...
- Весь Jquery код, который вы написали или Jquery библиотеки, которые вы используете, лучше поместить в футер сайта, из-за блокировки отображения. Если не можете перенести в футер, то возможно вам стоит использовать отложенное исполнение кода, статья на эту тему: Safely using .ready() before including jQuery.
Шрифты
- Google Fonts
- Если Google шрифт подключали давно, то обязательно подключите его по новой, так как важно наличие в урле &display=swap — это новая опция, которая влияет на Google PageSpeed и она разрешает показывать текст на странице до загрузки шрифта… не всегда это красиво, но увеличивает скорость отображения сайта… и влияет на Google PageSpeed
- Если есть возможность заменить Google шрифты своими шрифтами, то так и сделайте, лучше если шрифты будут на вашем сервере, это тоже повышает скорость.
- Когда выбираете шрифт на Google фонтс, постарайтесь выбрать по минимуму опций, выбирайте только то, что вам нужно, и если вы не используете на сайте наклонный шрифт или толщиной 200, то в настройках не выбирайте это, так как это повлияет на скорость загрузки.
- Свои шрифты
- Проверьте наличие css стиля font-display: swap; в ваших шрифтах, Google PageSpeed обращает внимание на это, и занижает показатели, если этого стиля не стоит:
@font-face { font-family: 'Saira Condensed'; src: url(sairacondensed.woff2) format('woff2'); font-display: swap; } - Если подключаете шрифты через отдельный файл стилей, то это влияет на время первого рендеринга и уменьшает показатели у Google PageSpeed, лучше так не делать:
<link href="/fonts.css" rel="stylesheet">
Если вы подключение шрифта вставите в <head> через тег <style>, а не через <link>, то это улучшит скорость загрузки и показатели Google PageSpeed, так как браузеру не нужно будет отдельно обращаться за вашим файлом стилей:
<head> <title>Demo</title> <style> @font-face { font-family: 'Saira Condensed'; src: url(sairacondensed.woff2) format('woff2'); font-display: swap; } </style> </head> - Если есть возможность, то уберите все лишнее, то что вы не используете, из ваших файлов шрифтов, чтоб повысить скорость загрузки.
- Можно сделать двухэтапную загрузку шрифтов: Developing a Robust Font Loading Strategy for CSS-Tricks
- Проверьте наличие css стиля font-display: swap; в ваших шрифтах, Google PageSpeed обращает внимание на это, и занижает показатели, если этого стиля не стоит:
CSS
- Старайтесь избавляться от лишнего CSS кода, под старые браузеры, в том числе от префиксов -moz- -o- -ms- -webkit-
- Старайтесь не загружать стили, которые не используются на этой странице, но используются на других страницах сайта.
- Если есть возможность, то стоит подгружать куски CSS и HTML кода через отложенную загрузку.
- Подгружать стили при помощи <link href='st.css' rel='stylesheet'> замедляет первую загрузку страницы и ее рендеринг, но дает возможность кэширования браузером этого файла.
Если у вас уникальные стили для каждой страницы или вам важнее чтоб первая загрузка страницы была чуть быстрее, то вместо файла вставляем тег style:
<style> содержимое файла </style> - Используйте минификацию CSS, например Cssresizer или другими подобными инструментами.
HTML
- Чем больше HTML тегов на странице, тем больше ресурсов браузеру нужно на рендеринг страницы, и это сказывается на показателях Google PageSpeed, но только если ваша страница слишком перегружена тегами.
- Избегайте чрезмерной вложенности HTML тегов, на это тоже обращает внимание Google PageSpeed.
- Стоит чистить свой HTML от кода для старых браузеров, так как обычно именно такой код создает огромное количество лишних и вложенных тегов.
- Количество тегов и вложенность, особенно сильно влияют на Google PageSpeed для мобильных.
Изображения
- Используйте тег <picture>, чтоб можно было использовать современные форматы изображений (JPEG 2000, JPEG XR и WebP). Google PageSpeed обращает на это внимание, если у вас нет ленивой загрузки изображений.
<picture> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="Тест"> </picture>
Так же можно использовать media и подставлять разные изображения под разные разрешения и разную плотность пикселей.
<source media="(max-width: 640px)" srcset="image.png, image-retina.png 2x">
Подобное полезно как для картинок, так и для видео.
Минус: нужно много места, ибо придется хранить разные форматы картинок (видео) и под разные разрешения. - Используйте ленивую загрузку для всех изображений, которые находятся в попапах или на втором и следующих экранах на странице.
- Используйте максимальное сжатие картинок, на это тоже обращает внимание Google PageSpeed. Инструментов для сжатия много, один для примера: compressor.io
Серверные настройки
- Включить кэширование статических файлов (шрифты, скрипты, картинки, css и так далее), при этом установить год кэширования, иначе гугл ругается.
- Включить gzip сжатие.
- Используйте HTTP заголовки Last-Modified и If-Modified-Since для кэширования страниц.
Связь
- Результаты сильно зависят от удаленности вашего сервера от вас. Если вы находитесь на Гаваях, а сервер в Москве, то результаты для вас будут плачевные.
- Результаты зависят от вашего сервера и компьютера, и если во время тестов сервер или компьютер был перегружен чем-то, то будет плохой результат.
Заключение
Выжать PageSpeed 108 или больше пунктов невозможно :)
Даже 100 пунктов выжимать под мобилу бессмысленно. Мы должны стремиться к 100, а не впадать в параною! Это всего лишь один из многих показателей, которые важны для сайта.
Можете посмотреть пример страницы, где показатели для мобилы 97-98 и 100 для компа.
На этой странице есть 2 ютуб видео в попапах и видео активируется только когда попап открыт.
Все фотки помещены в ленивую загрузку.
Весь JavaScript вынесен из <head> в футер страницы.
Но при этом в <head> подключаются: Jquery, GoogleFonts и Яндекс(Google) счетчики.
Стили вставлены в тег <style> код-стилей </style>.
<picture> на этой странице не используется.
На странице есть целый ряд разделов, которые присутствуют на странице, но доступны только по прямой ссылке для клиентов, их нужно будет сделать подгружаемыми по необходимости, что уменьшит количество html и css кода.
Спасибо за внимание!
Комментарии (58)
eumorozov
23.09.2019 11:02<input type=date>до сих пор не поддерживается Safari. «Safari is a new IE».iefedorov Автор
23.09.2019 11:20Мобильный сафари поддерживает и кстати очень классно сделали, лучше чем у других… а вот с десктопным они чет тормозят и сильно… и придется пользователю мака вводить вручную дату… вместо удобной выборки… хотя процент маков не такой уж и большой… большинство браузеров сафари под iOS…
Получается: вам решать, стоит ли оно того, и прикручивать ли доп скрипты ради пользователей Mac OS или пусть вводят дату с клавы…
Как крайний случай: можно на уровне HTTP заголовков определять OS и если это Mac, то подставлять JS календарик, а всем остальным дефолтный.
vintage
23.09.2019 11:15-1Открываем: http://mol.js.org/app/demo/-/#demo=mol
И видим:
При этом, идя по чек листу:
- Используются ненативные датепикеры и прочие контролы.
- Нет минификации.
- Нет отложенной загрузки скриптов и стрилей, всё грузится сразу.
- Скрипты и стили не вкомпилены в страницу, а грузятся отдельными запросами.
- Кеширование ресурсов всего 10 минут.
- Тегов не очень много, но аттрибутов в них — много.
Однако:
- Не используются кастомные шрифты.
- Гзипоание есть.
iefedorov Автор
23.09.2019 11:23да, когда body пустое, то достаточно легко получить 98 или даже 100
vintage
23.09.2019 13:09Эта писькомерка замеряет полную загрузку страницы в браузере, а не только html.
iefedorov Автор
23.09.2019 13:25да, только не понятно к чему вы это?
vintage
23.09.2019 15:45К тому, что причина низкой скорости многих сайтов не в том, что не выполнены эти оптимизации, а в чём-то другом.
iefedorov Автор
23.09.2019 15:49Согласен! Но если эти оптимизации сделаны, то это большой плюс!)
vintage
23.09.2019 16:45Да, целых 2 пункта из 100. И то может быть.)
iefedorov Автор
23.09.2019 16:52та не, не преуменьшайте важность этого) скорее 50 из 100, а не 2… возьмите тот же хабр, сделали б они оптимизацию, и вместо 46, могло быть 96
vintage
23.09.2019 17:06Вон же выше я привёл пример, где нет этих оптимизаций, а число очков — 98.
Или вот читалка статей — 99:
iefedorov Автор
23.09.2019 17:37посмотрел я ваши тесты: 18 и 17 успешных аудитов! так что не надо!) просто вы достигаете большинства успешных аудитов за счет JavaScript, отложенная загрузка и так далее… о чем я и говорил в статье… по сути, отложенная загрузка, это одно из самых важных, для хороших показателей в гугл спид… но не только… ну и ваши примеры, это не примеры реальных сайтов… сложно это сравнивать… но вы правы, хорошего результата можно достичь разными способами! Ниже zlo1 написал что он 96 добился за счет установки модуля под друпал: AdvAgg…
Кто-то писал, что если поставить на body display:none, то результаты будут 100/100 — но это вообще плохой пример, если он работает, по сути хак)vintage
23.09.2019 17:45большинства успешных аудитов за счет JavaScript, отложенная загрузка и так далее…
Нет там никакой отложенной загрузки. Вообще.
ваши примеры, это не примеры реальных сайтов
Это нереальные сайты?
iefedorov Автор
23.09.2019 17:55Да? а как это называется: когда я захожу на главную страницу хабра и делаю быструю прокрутку: сразу видно что пролистываю…
а когда на ваш первый сайт захожу и начинаю быстрое пролистывание, то вижу пустоту и потом постепенно все прорисовывается… чтоб не быть голословным, беру открываю дебаг в хроме и перехожу во вкладку нетворк и начинаю листать и вижу как большинство объектов подгружаются во время прокрутки, тоесть не сразу прогружаются, а как раз во время прокрутки!vintage
23.09.2019 18:02Это называется ленивый рендеринг и это не какая-то оптимизацися, это особенность фреймворка.
iefedorov Автор
23.09.2019 18:54как по мне: игра слов… от изменения названия суть не меняется…
Мои клиенты тоже используя мой продукт смотрят на показатели гугл спида и радуются! Как вы говорите: ничего не делали и результат около 100…
И они тоже думают: это особенность cPortfolio)
Но правда заключается в том, что кто-то сделал это на фреймворке за вас, а вы пользуетесь… возможно даже не понимая как это работает и почему именно так…
iefedorov Автор
23.09.2019 18:59Хотя может я не прав! Расскажите подробней про ленивый рендеринг вашего фреймворка
vintage
23.09.2019 19:07А что тут рассказывать. Один фреймворк рендерит сразу всё, что замедляет открытие пропорционально размеру страницы. А другой рендерит лишь видимую область, что гарантирует высокую скорость старта без каких-то дополнительных приседаний.
justboris
24.09.2019 11:17Непонятно, за что этому комментарию минусы. Реклама mol всем уже надоела, конечно, но в контексте этого поста ссылка вполне уместна. Хорошая демка, быстро загружается, всем бы так делать.
zlo1
23.09.2019 12:47Для CMS Drupal 7 подключил модуль AdvAgg, агрегированные css и js разместил в tmpfs
тест для мобильных и компьютеров 96
edogs
23.09.2019 12:51не используйте Jquery у себя в проектах и это значительно повысит скорость вашего сайта
Все же этот совет отчасти из серии «не используйте си у себя в прогах, пишите на асме»© Простые вещи можно и напрямую JS сделать, но в jquery слишком много оптимальных решений для чуть более сложных вещей, что бы свой велосипед оправдывал себя вот прям так безапелляционно.iefedorov Автор
23.09.2019 13:11Это все советы) И выбирать вам, где можно или нужно следовать совету, а где вредно!) Заметьте, в примере я показал, что jquery сама по себе не сильно влияет на метрики, и показатели были 98-100… если убрать jquery то возможно будет 99-100, но стоит ли оно того… это вам решать!
Но с другой стороны, если у вас на странице много чего, то влияние jquery может быть значительным…
И я с вами согласен, на jquery написано очень много классных плагинов!
PaulZi
23.09.2019 13:26Большая часть советов перекопированы с самого pagespeed, такое ощущение, что автор писать статью ради ссылки на портфолио. А если и есть советы, то они странны, мол jQuery замедляет. С таким же успехом можно написать, что и React замедляет страницу, пишите на чистом html.
iefedorov Автор
23.09.2019 14:25Ничего не копировал) просто рассказал что знаю!
jQuery и React нельзя ставить в один ряд и сравнивать их…
У них разные цели!
jQuery была создана лет 15 назад и главной ее целью было: сделать прослойку между нативным JavaScript и разработчиком и уберечь его от проблем несовместимости… Тогда действительно была проблема со стандартизацией и унификацией… у каждого браузера был свой JavaScript сильно отличающийся от других… По этой причине jQuery раньше было спасением… Даже элементарные операции порождали сотни условий и проверок, например, если вы хотели выбрать элемент по ID, то вам нужно было как минимум сделать такое:
if (document.getElementById) { return document.getElementById(objID); } else if (document.all) { return document.all[objID]; } else if (document.layers) { return document.layers[objID]; }
И это была вершина айсберга! Так было во всем… а Jquery в то время предложил свою унификацию $('#objID'), $('.objID') и т.д., и это очень упрощало жизнь разработчикам.
Сейчас же, у JavaScript появились стандарты, которым следуют браузеры и они их разрабатывают совместно. По этой причине, в большей степени Jquery прослойка уже лишняя, хотя очень полезная, когда нужен уже готовый плагин написанный кем-то 5 лет назад… Jquery скопилась огромная база плагинов, это огромный плюс! так что ее стоит использовать, но не для того чтоб выбирать объект по ID, а таких людей и проектов хватает)
React же, это полноценный фреймворк и цель его не прослойка между нативным JS и разработчиком, а создание пользовательского интерфейса на компонентной основе… тоесть это все равно, что сравнить небо и землю… и я конечно же не мог сказать: не используйте React…
но вы правы, чистый html быстрее)PaulZi
23.09.2019 15:01Я прекрасно знаю что такое JQuery, но с чего вдруг он замедляет страницу? Я понимаю ещё там ветка 1.x весила много ради совместимости с ie8, но в текущей версии библиотека весит 86 кбайт, для сравнения react-dom весит 111 кбайт. Или вы считаете что PageSpeed занижает оценку из-за jQuery потому что он не модный?
iefedorov Автор
23.09.2019 15:10В статье я написал «Но так как сама библиотека JQuery маленькая, а инет у всех быстрый, то это слабо влияет на скорость, гугл если и понижает рейтинг, то примерно 0.5, хотя раньше 10 или 20 очков снимал за такое...»
Если сейчас посмотреть на гугл тест для cportfolio, то гугл тест ругается JQuery и пишет:
Устраните ресурсы, блокирующие отображение 0,15 s
…js/jquery.js(cportfolio.ru) 30 KB 780 ms
.../css?family=Roboto:100&display=swap&subset=cyrillic(fonts.googleapis.com) 1 KB 780 ms
И если я их уберу, скорее всего +1 будет, но может быть +0.9
И это не критично, по этой причине я их не убираю.
А вот год назад, гугл за такое -15 мог снять, по старым алгоритмамPaulZi
23.09.2019 15:53А вы его хоть асинхронно подключаете? На любой большой скрипт в head не подключенный асинхронно PageSpeed будет ругаться, тут дело вовсе не в jQuery, а методе подключения.
iefedorov Автор
23.09.2019 16:09написал вам ответ и потом увидел ваше сообщение)
>А вы его хоть асинхронно подключаете?
нет, и причину написал в другом комменте… сначала делал асинхронно для себя, но проблема еще в клиентах, которые вставляют свой код и у них фатальная ошибка появляется… проще оставить так, чем учить каждого клиента, отложенному исполнению кода.
iefedorov Автор
23.09.2019 16:06Но с гугл шрифтом проблема решаемая и быстро: просто качается шрифт, загружается на свой сервер, потом вместо ссылки на css файл шрифта, вставляем тег style, и все, проблема решена(описание в статье), то с jquery это чуть сложнее…
Чтоб мы не помещали в тег head, все это блокирует прорисовку страницы, тоесть браузер ожидает пока прогрузится все из тега head, а уж потом начинает работать с body, и на это гугл спид обращает внимание.
Конечно можно поставить асинхронную загрузку jquery, тогда блокировки не будет, но после jquery идет код который вы написали или код плагина и есть шанс что браузер начнет его выполнять раньше чем jquery загрузится, тогда будет фатальная ошибка… можно еще делать отложенное выполнение jquery кода, что я тоже описал в статье… но это лишний гемор… так что, получается что jquery нужно загружать обычным способом в head, и он будет чуть блокировать… но это чуть относительное понятие, если например в Москве скорость инета классная, то пользователь не заметит задержки, ее не будет, а вот если вашим сайтом будет пользоваться человек из Лас-Вегаса, то он может почувствовать реальную задержку…PaulZi
23.09.2019 16:23Конечно можно поставить асинхронную загрузку jquery, тогда блокировки не будет
Ну вот и корень всех ваших проблем с jQuery. Вы обвиняете jQuery, хотя по факту он прекрасно работает и загружается асинхронно. Самый простой способ избежать подобных фатальных ошибок — упаковать всё в один бандл с помощью webpack или подобных скриптов. Либо же использовать динамическое подключение зависимостей с каллбэком. Либо вообще банально сделать onload на скрипте с jQuery.
iefedorov Автор
23.09.2019 16:30))))))) я не обвинял
но да, вы правы! решений много есть и ваши хорошие!
mike_IT
24.09.2019 11:27ее стоит использовать, но не для того чтоб выбирать объект по ID, а таких людей и проектов хватает)
да, некоторые веб аналитики часто используют такие конструкции для извлечения значений: return $().val() или тот же getElementById
А по вашему как по феншую это делать?iefedorov Автор
24.09.2019 11:37Конструкции хорошие)
Суть чуть в другом… Если у вас проект, прекрасно поживает без jquery, и вы понимаете что вам нужно получить данные из поля или сделать выборку элементов по id или классу, то ошибкой будет подключать jquery для этого, вам вполне хватит нативного JavaScript.
Ну а вместо $('#id').val() использовать document.getElementById('id').value — одинаковое по функционалу, только не требует подключение дополнительной библиотеки.document.getElementById('id'); document.querySelectorAll('.class');
Но если у вас уже используется jquery в проекте и вы решили получить значение поля или выборку, то использование jquery нормально, тоесть конструкция $().val() в этом случае оправдана.
asakasinsky
23.09.2019 13:27Поясните, пожалуйста, откуда взялось это? «data-aload data-original»
iefedorov Автор
23.09.2019 14:07Это атрибуты для JavaScript кода, у каждой JS библиотеки они свои. Просто по ним JavaScript определяет: какой элемент должен ждать загрузки.
Но data-original — это рекомендованный от яндекса атрибут, они говорили что его считывают, если нет SRC
inoyakaigor
23.09.2019 13:39data-aload
Тут видимо используется какой-то внешний скрипт? data-атрибуты, насколько мне известно, целиком и полностью пользовательские.
nckma
23.09.2019 20:48Подскажите пожалуйста, а как правильно (с точки зрения скорости загрузки страницы) подключать GoogleAnalitics и яндекс метрики? Это же тоже скрипты, но им вроде нельзя ленивую загрузку ставить?
Ну и рекламные блоки того же яндекса… как их?iefedorov Автор
23.09.2019 21:39GoogleAnalitics и Яндекс метрика — используют асинхронную загрузку и разработаны так, чтоб минимально влиять на скорость проекта… по сути они минимум загружают на ваш сайт, если конечно вы не визуализируете их счетчики на странице.
Можете размещать их где угодно, но если вы размещаете в head, то они начнут грузиться на страницу до начала рендеринга страницы, если же вы их вставите в футере, то загрузка начнется после… Вам решать, где лучше, но влияние их минимальное!
>Ну и рекламные блоки того же яндекса… как их?
не использовал, не уверен, покажите вашу страницу с таким блокомnckma
24.09.2019 22:41Честно говоря, я не уверен, что там используется асинхронная загрузка, ведь тогда как скрипт сможет точно измерить время проведенное пользователем на конкретной странице?
iefedorov Автор
25.09.2019 12:57А они не могут, они могут измерить только после загрузки их скрипта!
Ну в любом случае, с яндекс.метрикой и гугл.аналитикой вы ничего не можете сделать, так как они должны грузится сразу и их нельзя в отложенную или ленивую загрузку запихнуть… откладывается только то, что визуализируется ниже первого экранаnckma
25.09.2019 13:54Тогда возникает вопрос — можно ли и нужно ли ставить на сайт обе метрики одновременно?
С одной стороны наверное они замедляют загрузку страницы, а с другой стороны не может ли поисковик «обидеться», что не стоит его метрики и тем самым понизить выдачу?iefedorov Автор
25.09.2019 14:06Чем меньше счетчиков и метрик, тем быстрее сайт загружается, это факт!
Сколько их ставить, это вам решать… может «обидеться»))
Но не только в обиде дело, и гугл и яндекс анализирует поведение пользователя на вашем сайте, количество отказов, время проведенное на нем, количество посетителей и так далее… и по этим показателям либо повышает ваш сайт в рейтинге, либо понижает… если вы убираете их счетчик, то они не могут эти показатели отследить и повышать или понижать вас не могут…
iefedorov Автор
25.09.2019 14:09Поведенческие факторы поисковик может отследить за счет счетчиков и они при ранжировании имеют очень большое значение!
denisshabr
24.09.2019 12:09Хоть бы ссылку указал на библиотеку aload, о которой пишешь, иначе data-aload не заработает — github.com/pazguille/aload
iefedorov Автор
24.09.2019 14:59Библиотек ленивой загрузки сотни, а может и тысячи, при этом лидеры каждый год меняются, то одна в топе, то другая… Так как меняются технологии и совершенствуются браузеры… Какая лучше сейчас, я не знаю… не проверял… Поэтому я просто написал 3 названия для примера, а дальше уж дело техники: найти лучшую и применить… и еще есть фреймворки, в которых уже встроен такой функционал и не нужно отдельно библиотеку подключать, выше в комментах пример такого фреймворка был.
Атрибут data-aload это просто название, которое я применил в cPortfolio, мне показалось такое название более логичным и запоминающимся, хотя если вы используете библиотеку, в которой вместо атрибута data-aload, используется loading=«lazy» или class=«b-lazy» или любой другой, это сути не меняет…
Но спасибо что дали ссылку, может кому-то это поможет!)
Когда я изучал и внедрял в cPortfolio ленивую загрузку, то я взял 3 штуки топовых на тот момент и изучил их, каждую строчку кода) у каждого были свою плюсы или минусы… и потом самое лучшее из трех взял на вооружение и применил… мне лично не подходило: взять и использовать готовую, так как мне нужно было не только ленивая загрузка, а автозапуск видео, анимации при прокрутке и тому подобное… это нужно было все объединить в одно, а не вешать десятки библиотек для разных целей…
Замечу еще, что в ссылке которую вы указали, не используется атрибут data-original="" который в моем примере и я добавил когда-то в своем проекте для яндекса, чтоб этот урл считывал их бот, так как когда-то яндекс его рекомендовал для правильной индексации картинок ленивой загрузки…
Но data-original уже немного устаревшее, сейчас я в своем проекте использую микроразметку на тегах itemtype=«schema.org/ImageObject», itemprop=«contentUrl» и другие полезные атрибуты… и теперь поисковику не нужно угадывать в каком атрибуте находится реальный урл, так как есть уже стандарт микроразметки и все поисковики следуют ему…
iefedorov Автор
24.09.2019 15:33Из 3, что я выбрал когда-то, точно запомнил dinbror.dk/blog/blazy
Другие не помню…
Но, ссылку что вы дали, похоже, что именно эту библиотеку я тогда тоже встречал и возможно из-за нее решил такое название сделать атрибуту!)
Помню, что мне понравилась она тем, что очень маленькая и простая…
И решение с фоновыми картинками понравилось, своей простотой.
[data-aload] { background-image: none !important; }
vovasik
Имеется в виду то что больше 100% выжать нельзя или были прецеденты когда выжимали более 100? Никогда такого не видел.
iefedorov Автор
да, выжать больше 100% нельзя) просто многим хотелось бы)