Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • entry
    1
  • comments
    78
  • views
    1,339

Оптимизация и ускорение сайта: JavaScript, CSS и пр., что работает на клиентской стороне (в браузере). Повышение оценки pagespeed Гугла


sitecreator

8,298 views

Известно, что работу сайта можно разделить на две независимые составляющие с определенной степенью условности:

 

  1. серверную (выполнение кода PHP, выполнение запросов БД и т.п.)
  2. клиентскую (выполнение кода JavaScript и т.д. и т.п., что выполняется в браузере)

 

 

Разбор полетов предлагаю делать на основе тестового сайта:

https://hi-optimizer.sitecreator.pro/

 

Входные данные:

дефолтная тема (шаблон),

присутствуют на странице:

  • Карта Яндекса
  • Jivochat
  • Яндекс метрика
  • Ютюб вставка

 

оценка гугла в этом случае падает до 29 баллов.

 

Спойлер

sitecreator_ru_2aZiOaFVYp.jpg

 

 

Речь пойдет об оптимизации процессов на клиентской стороне, т.е. в браузере.

Одним из важнейших и ресурсоемких процессов является выполнение программ на JavaScript в браузере.

Гугл в своих рекомендациях всегда предлагает обратить внимание на долго выполняющиеся скрипты.

 

sitecreator_ru_uF1yRS78AV.jpg

 

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

Как пример такого скрипта - это скрипт чата Jivisite.

 

 

sitecreator_ru_T0LTsaxE4a.jpg

 

 

 

Итак, что мы можем оптимизировать?

Ютюб-вставку и разнообразные карты (впрочем как и различные виджеты)   можно показывать пользователю тогда, когда он до них долистает и не тратить время на их загрузку до загрузки основного контента.   Это известный принцип отложенной ленивой загрузки (Lazy Load).  Это принцип применим не только к изображениям, но и к блокам iframe, которые используют как один из вариантов размещения карт, виджетов и т.д.

 

Метод Lazy Load настолько хорошо зарекомендовал себя, что актуальные версии браузеров поддерживают его уже на уровне встроенной поддержки, т.е. нативно.

 

sitecreator_ru_wVAi1lv5Ir.jpg

 

 

Разумно использовать Lazy Load для загрузки карт, виджетов, ютюб-вставок и пр. iframe и т.п.?  Разумно.   Если у вас есть иные предложения по оптимизации указанных объектов, то, милости просим, поделитесь.

 

Документация по Lazy Load:

 

от разработчиков FireFox

https://developer.mozilla.org/ru/docs/Web/Performance/Lazy_loading

 

документация от developers.google.com   (гугл для разработчиков)

Lazy Loading Images and Video

 

 

С картами и ютюбом справились. Но у нас есть еще скрипт Jovosite.

 

<script src="//code-ya.jivosite.com/widget/xxXbQf2XXX" async></script>

 

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

Логично бы сделать так чтобы он выполнялся позднее всех других скриптов на странице, а лучше после загрузки основного контента страницы.

Переместим скрипт в конец страницы?

 

<script src="//code-ya.jivosite.com/widget/XXXXXxxx" async></script>
</body></html>

 

Что мы получили от гугла в результате? блокировка уменьшилась до 670 мс против 1100, т.е. почти в два раза. Ура!?

 

sitecreator_ru_yfONh34ufa.jpg

 

 

И как же гугл оценил наши усилия по оптимизации? Что-то не очень.... Вместо 29 баллов теперь 32. Всего?  Да и параметр "время загрузки для взаимодействия" не радует.
 

Спойлер

 

sitecreator_ru_GR1MRVm4Li.jpg

 

 

 

А давайте мы отложим загрузку и загрузим сперва основной контент целиком, включая изображения и пр.  А потом уже и Jivosite отобразим.

Итак, код для эксперимента (он неидеальный, т.к. не учитывает возможные медленные соединения, но для эксперимента сойдет)

 

<script>
window.onload = function() {
			var src="//code-ya.jivosite.com/widget/XXXxxxXXX"
			var js = document.createElement("script");
			js.src = src;
			document.head.appendChild(js);
		};
</script>

 

Но гугл не оценил данные усилия и продолжает настаивать на том, что Jivosite блокирует основной поток.  Оценка, разумеется, не улучшилась.

 

sitecreator_ru_4FLGQhx37m.jpg

 

 

Что же реально может помочь изменить отношение гугла к оценке?

Попробуем отложить выполнение скрипта Jivosite на 3 сек или даже на 5 сек?  Чисто из соображений юзабилити это вполне оправданный ход.  Окошко чата вряд ли кому-то будет нужно раньше чем через 3 или 5 сек.

Гугл реагирует уже положительно прибавкой баллов за такой отложенный скрипт. Но видит ли гугл выполнение данного скрипта? Нет, не видит. Хотя гугл способен после полной  загрузки страницы и ее отображения еще несколько секунд оценивать работу JS в браузере.   Например, задержка в 1000 мс или 1500 мс обычно не поможет, т.к. гугл еще успеет поймать и оценить такой "запоздалый" скрипт.   Задержка, которую видит гугл, зависит от нескольких факторов и не может быть универсальной для всех сайтов и всех случаев. Нельзя назвать гарантированно минимальную задержку, после которой гугл не реагирует на выполнение скриптов. Задержка отсчитывается отсчитывается от события window.onload.

 

Чисто в экспериментальном плане задержка выполнения на несколько сек кода JS Jivosite показала, что гугл больше не ругается на блокировку основного потока данным скриптом. И он, действительно, не блокирует основной поток. Высказывалось мнение, что это, якобы, обман гугла. Чисто субъективное, без всяких пруфов мнение. Тут бы факты не помешали бы...

 

Со своей стороны могу сказать, что использовал метод отложенной загрузки виджетов еще 5 лет назад.  До сих пор на сайте именно так и загружаются виджеты с отсрочкой на 3... 5 сек.   Гугл и яндекс сайт любят,  т.е. никаких проблем со стороны поисковиков не возникало.

 

Если вы знаете правильный способ оптимизации загрузки виджетов вроде Jivosite , да и любых подобных (Фейсбук, В Контакте и т.п.), то, милости просим, с вашими идеями.

Если можете объяснить чем плох такой метод оптимизации загрузки JS, пожалуйста, с аргументами и фактами только.

Страшилки о том, что сайт будет работать после подобной оптимизации  настолько плохо, что "пользователи не смогут оформить покупки" или поисковики "пессимизируют сайт" хотелось бы чтобы были подкреплены какими то фактами, а не оставались просто фантазиями.  

 

Любой конструктивный диалог приветствуется.

Примеры ваших сайтов, на которых успешно работает оптимизация Jivosite также приветствуются.

 

Аргументы вроде

 

Цитата

я - самый крутой оптимизатор и я умею оптимизировать Jivosite, но не покажу для примера сайт, где это сделано потому, что это секрет и ноухау

 

не хотелось бы получать.  Если решили покритиковать, то покажите как делаете вы и объясните насколько ваша идея лучше.  Про секреты и ноухау лучше не стоит...

 

Я не выдал сразу все идеи и решения по оптимизации загрузки виджетов.  Еще вернусь к их реализации, но сперва интересно услышать мнения специалистов.

 

  • +1 2

78 Comments


Recommended Comments



Довольно забавен ответ самих www.jivosite.ru по поводу оценки гуглом фактора замедления скорости загрузки сайта скриптом Jivosite.

 

www.jivosite.ru: JivoSite и скорость загрузки сайта

 

Если коротко, ту суть их ответа такова:

Наш виджет загружается быстро, пользователи этого даже не заметят, но...

Цитата

с точки зрения бездушной машины сайт с JivoSite загружается дольше, чем без него

 

В общем, гугл все верно замеряет (и снижает баллы) по их мнению. Но мы  не можем ничем вам помочь, а потому предлагаем не обращать внимания на баллы гугла.

 

На Хабре небольшая статья с кодом JS для отложенной загрузки виджета JivoSite чтобы гугл не "ругался":

 

Ускоряем сайт с JivoSite. Отложенная загрузка онлайн-консультанта

 

А мужики то и не знают, что ждет их сайты за такой обман гугла?

 

Интересно, а чем принципиально отличается отложенный вызов окошка виджета JivoSite от вызова pop-up окошка с картинокой товара или от вызова любого другого всплывающего окошка?

Чем для гугла это может отличаться?

 

Вот случай обычного pop-up (запуск скрипта по действию пользователя):

 

sitecreator_ru_U7LmDKjj7A.gif

Link to comment

Фишка по оптимизации , которая есть только у автора @sitecreator .

Именно @sitecreator разработал с нуля код для

 

В 21.04.2020 в 16:51, sitecreator сказал:

оптимизация загрузки всевозможных Lightbox (magnific-popup, colorbox, fancybox)

 

 

Но на форуме неожиданно появился лже-разработчик, который якобы предлагает тоже самое спустя пару дней, как появилось такое предложение у @sitecreator .

Совпадение? Не думаю. (с)

 

Этот человек ворует чужие идеи и чужой код?

Или он просто пустозвон и ничего подобного не может предложить?

 

Как минимум, такой реализации конкретной задачи по оптимизации вы не найдете в интернете. Не только для опенкарт, а вообще нет.

Мне не жалко поделиться идеей. И даже кодом поделиться. Что я и сделаю немного позже.

Собственно я и создал данный блог чтобы делиться своими наработками.

 

Просто довольно мерзкая сама ситуация.

И эти люди приходят своей гоп-компанией минусовать мой блог?

Это все, на что они способны в интеллектуальном противостоянии?

 

 

 

 

sitecreator_ru_9ffQDn3A0M.jpg

Link to comment

Я недавно снес к чертям этот jivosite и перешел на другой онлайн чат, который гораздо функциональнее (все мессенджеры, включая whatsapp и instagram уже в базе), гораздо больше кастомизация и настройки. А стоит всего 4400р за год (либо 7200р за 2 года). Поток абсолютно не тормозит, его даже в этом списке нету.
Не нарадуюсь!

  • +1 1
Link to comment
26 минут назад, kolek5520 сказал:

Я недавно снес к чертям этот jivosite и перешел на другой онлайн чат, который гораздо функциональнее (все мессенджеры, включая whatsapp и instagram уже в базе), гораздо больше кастомизация и настройки. А стоит всего 4400р за год (либо 7200р за 2 года). Поток абсолютно не тормозит, его даже в этом списке нету.
Не нарадуюсь!

А что за сервис? если не секрет?

Link to comment
29 минут назад, Sergeyy84 сказал:

А что за сервис? если не секрет?

отписался в л.с.

Link to comment

 

10 часов назад, kolek5520 сказал:

отписался в л.с.

 

и мне пожалуйста 

Link to comment

Бывают такие вот сайты с низкой оценкой гугла. И с минимум рекомендаций от гугла.

Блокирующих основной поток скриптов немного и блокировка эта недолгая. Кол-во узлов DOM тоже невысокое.

А оценка крайне низкая - всего 8 баллов.

 

Особо удручает "Время загрузки для взаимодействия".

С такими сайтами тоже можно работать, но тут откладывание скриптов вроде Jivosite почти не дает никакого эффекта.

Тут нужно смотреть что за скрипты так долго работают на сайте.  И либо избавляться от таких скриптов, либо искать иные (оптимизированные) версии этих скриптов.

Бывает полезно связаться с автором скрипта и уточнить не появилась ли версия более быстрая или, как минимум, обратить внимание автора на долгую работу его творения.

 

 

sitecreator_ru_yj49dSI87u.jpg

 

sitecreator_ru_M3u275QNL3.jpg

Link to comment

В тестовой 6й версии лайтхауза есть более "понятное" объяснение в чем именно дело и более конкретные рекомендации.
Конкретно по этому сайту выше - https://prnt.sc/s9o4jn

Link to comment
Спойлер

 

 

Откладываение Jivosite дает + 20 к скорости, тестировал недавно

Link to comment

А как бороться с Устраните ресурсы, блокирующие отображение, их если отложить то картинка дергается

Link to comment

У меня твой код для ускорения Jivosite не работает. 

Я использую вот такой код.

<!-- BEGIN JIVOSITE CODE {literal} -->
<script type='text/javascript'>
(function(){ document.jivositeloaded=0;var widget_id = 'АЙДИ_ВАШЕГО_ЖИВОСАЙТА';var d=document;var w=window;function l(){var s = d.createElement('script'); s.type = 'text/javascript'; s.async = true; s.src = '//code.jivosite.com/script/widget/'+widget_id; var ss = document.getElementsByTagName('script')[0]; ss.parentNode.insertBefore(s, ss);}//эта строка обычная для кода JivoSite
function zy(){
    //удаляем EventListeners
    if(w.detachEvent){//поддержка IE8
        w.detachEvent('onscroll',zy);
        w.detachEvent('onmousemove',zy);
        w.detachEvent('ontouchmove',zy);
        w.detachEvent('onresize',zy);
    }else {
        w.removeEventListener("scroll", zy, false);
        w.removeEventListener("mousemove", zy, false);
        w.removeEventListener("touchmove", zy, false);
        w.removeEventListener("resize", zy, false);
    }
    //запускаем функцию загрузки JivoSite
    if(d.readyState=='complete'){l();}else{if(w.attachEvent){w.attachEvent('onload',l);}else{w.addEventListener('load',l,false);}}
    //Устанавливаем куку по которой отличаем первый и второй хит
    var cookie_date = new Date ( );
    cookie_date.setTime ( cookie_date.getTime()+60*60*28*1000); //24 часа для Москвы
    d.cookie = "JivoSiteLoaded=1;path=/;expires=" + cookie_date.toGMTString();
}
if (d.cookie.search ( 'JivoSiteLoaded' )<0){//проверяем, первый ли это визит на наш сайт, если да, то назначаем EventListeners на события прокрутки, изменения размера окна браузера и скроллинга на ПК и мобильных устройствах, для отложенной загрузке JivoSite.
    if(w.attachEvent){// поддержка IE8
        w.attachEvent('onscroll',zy);
        w.attachEvent('onmousemove',zy);
        w.attachEvent('ontouchmove',zy);
        w.attachEvent('onresize',zy);
    }else {
        w.addEventListener("scroll", zy, {capture: false, passive: true});
        w.addEventListener("mousemove", zy, {capture: false, passive: true});
        w.addEventListener("touchmove", zy, {capture: false, passive: true});
        w.addEventListener("resize", zy, {capture: false, passive: true});
    }
}else {zy();}
})();</script>
<!-- {/literal} END JIVOSITE CODE -->

 

Link to comment
50 минут назад, Otche94 сказал:

Откладываение Jivosite дает + 20 к скорости, тестировал недавно

 

Бывает по разному.

Но в среднем примерно так и есть.

Т.е. JIVOSITE - штука довольно тяжелая как ни крути.

 

42 минуты назад, Otche94 сказал:

А как бороться с Устраните ресурсы, блокирующие отображение, их если отложить то картинка дергается

 

смотря, что откладывать.

CSS, который участвует в построении страницы откладывать нельзя.

Повторный рендеринг приведет в таком случае к тем самым дрыганьям страницы.

А вот загрузить в самом конце CSS, например, какого-либо лайтбокса - это разумно. Зачем его грузить в начале страницы?

И загрузить такой CSS (лайтбокса) лучше асинхронно, т.е. чтобы без блокировки или почти. Особенно полезно если на странице сразу куча всяких лайтбоксов.

Встречал когда на страница по три-четыре разных скрипта лайтбоксов, и все разные.

 

owl-карусель хорошо бы отложить и выполнить уже в самом конце после завершения построения страницы.

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

Тут у меня есть некоторые наработки, но пока не придумал универсального способа на все случаи, т.к. карусели бывают всякие и разные, особенно много разных для продуктов бывает.

основная суть - это при первом построении страницы пользователю вообще не нужны стразу никакие движения вправо-влево этих каруселей. Ему бы просто страницу поскорее увидеть, а потом уже на каруселях кататься.

Link to comment
В 04.05.2020 в 16:28, sitecreator сказал:

Тут у меня есть некоторые наработки, но пока не придумал универсального способа на все случаи, т.к. карусели бывают всякие и разные, особенно много разных для продуктов бывает.

основная суть - это при первом построении страницы пользователю вообще не нужны стразу никакие движения вправо-влево этих каруселей. Ему бы просто страницу поскорее увидеть, а потом уже на каруселях кататься.

Есть вариант немного другой, скрывается карусель и отображается после того как она будут загружена, вариант тоже со своими +/- но иногда имеет место быть 

Link to comment
17 минут назад, ArtemPitov сказал:

вариант тоже со своими +/- но иногда имеет место быть 

 

да, как некое компромиссное решение может быть годным.

из минусов - возможны рывки в отображении, которые иногда все же можно сгладить.

 

В journal 3 главный баннер-карусель сделан по правильному принципу. Точнее, идея заложена верная, но несколько недоработана.

Сначала отображается одна картинка баннера, а сам скрипт смены картинок загружается потом. Причем может быть загружен самым последним уже после полной визуализации страницы, что довольно логично.  К тому же этот скрипт может быть загружен асинхронно, т.е. без блокирования основного потока. И что немаловажно, то не возникает никаких рывков, дерганий на странице в результате загрузки данного скрипта, т.к. место на странице заранее четко занято и браузеру не приходится делать рендеринг целиком всей страницы..

 

В случае же owl-carousel грузится в начале страницы (еще до начала ее формирования) сперва тяжелый скрипт, в котором нет смысла до полного формирования страницы. К тому же этот скрипт не может быть загружен асинхронно. Т.е. оптимизация изначально не продумана.

 

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

 

К сожалению, большинство шаблонов (почти все) спроектированы изначально так, что второстепенные скрипты вроде каруселей не могут быть просто так загружены асинхронно, например. Асинхронно - это довольно хорошая штука, т.к. когда загрузился, то тогда и выполнился. Никто никого не ждет пока загружается, да и загружаться могу параллельно несколько асинхронных скриптов.

В обычном случае загрузка происходит строго последовательно, да еще и с блокировкой выполнения основного потока. Т.е. пока грузится скрипт браузер дальше ничего не делает, а мог же разбирать и применять CSS в это время к странице и т.д. и т.п.

 

В journal 3:

 

ABpL5Q8.jpg

 

c9aNVdS.jpg

 

 

journal 3 , хоть и имеет кучу своих недостатков, но несомненно имеет плюсы в плане неплохих и часто удачных попыток оптимизации.  Например, страница до выполнения JS и после выглядит почти одинаково. Т.е. для первоначального отображения страницы не нужен JS вообще,  эта страница будет вполне информативна на 99%.   Скрипты подгружают лишь функционал, необходимый для последующих действий пользователя (клики, переходы), но этот функционал не нужен для первоначального просмотра.

 

Разработчикам шаблонов стоило бы взять весьма неплохую концепцию journal 3 в этом плане.

 

Link to comment

В Magento 2 отработана отложенная загрузка HTML, JS и CSS, а так же построен собственный полноценный клиентский кэш на основе хранилища данных. Причем при соблюдении фэншуя для разработчиков для Мадженто 2 эти возможности автоматом распространяются  и на модули сторонних разработчиков. Но из-за этого разработка клиентской части под Magento 2 просто катастрофа. Количество файлов в стандартном модуле по сравнению с таким же для версии 1 увеличилось практически в 2 раза.

В двойке активно используется Knockout для этих целей.

Edited by EVMedvedev
Link to comment

28 (29) мая 2020 года гугл ввел новый алгоритм оценки сайтов.  Спустя 10 дней после появления первого стабильного релиза Lighthouse 6.0.0.

 

это

Lighthouse 6

https://github.com/GoogleChrome/lighthouse/releases

 

тестировать можно также здесь помимо собственно гугла:

 

https://lh6.loading.express

 

Практически во всем интернете оценки для сайтов серьезно просели - на несколько десятков баллов в основном.

Пока не вполне понятно временное ли это явление или это новая реальность в оценке сайтов. Я склоняюсь к тому, что это новая реальность, т.е. достигнуть оценки в 90+ теперь станет довольно сложно.

 

Причем, замечу, что сильно просели показатели для десктопов.  Тут кардинально пересмотрели подход к оценке в Lighthouse 6.0.0.

 

Забавно, что теперь можно увидеть такие результаты (т.е. в одном измерении для десктопов оценка может быть ниже чем для мобильных):

 

sitecreator_ru_CgkrSXbo4x.jpg

 

sitecreator_ru_j4oj5aHul3.jpg

 

 

 

 

sitecreator_ru_klyUanNd1O.jpg

 

sitecreator_ru_MIMW4diBTn.jpg

Link to comment

Для нового алгоритма оценки гугла оказался весьма кстати разработанный мною алгоритм оптимизации с условным названием "продвинутый вариант Б".

 

sitecreator_ru_0dpokOF2mM.jpg

 

 

В случае старого алгоритма гугла он уступал по эффективности алгоритму "вариант Б" и рассматривался мною как запасной если нельзя было использовать "вариант А".

И я был ранее несколько удивлен, что он был менее эффективен чем "вариант А", хотя чисто теоретически он был в определенной степени совершеннее чем "вариант А".

 

Но вот теперь гугл вполне оценил мой "вариант Б" продвинутой оптимизации скриптов JS.

После ввода нового алгоритма гугла показатели для https://hi-optimizer.sitecreator.pro/

сначала просели на 10 баллов, т.к. работал "вариант А" оптимизации.

С переключением в режим "вариант Б" оценка гугла снова поднялась до 90+.

 

Я использую данный алгоритм в своем модуле оптимизации Hi-Optimizer:

 

 

Я попробовал переключить метод оптимизации на нескольких сайтах, которые ранее уже были оптимизированы, но с новым алгоритмом гугла оценки просели.

Оптимизация "вариант Б"  улучшила ситуацию после ввода гуглом нового алгоритма.  Не скажу, что баллы снова стали такими же как при старом алгоритме гугла, но на 10...20 баллов алгоритм "вариант Б"  работает лучше чем "алгоритм А" в новых условиях.

 

"Вариант Б" я создавал скорее как экспериментальный вариант. Развивать его не стал по той простой причине, что в условиях прежнего алгоритма гугла этот метод оптимизации не давал никаких преимуществ. Но теперь то я буду развивать и совершенствовать именно этот метод, т.к. он показал свою эффективность именно в новых условиях.

 

Неожиданно для самого себя у меня оказался уже готовый инструмент для оптимизации сайтов в новых условиях нового алгоритма гугла.

 

Я специально в своем модуле Hi-Optimizer оставлял несколько разных вариантов оптимизации, поскольку их эффективность и совместимость не могла быть одинаковой на разных сайтах.

 

Могу сказать, что по моим наблюдениям откладывание скриптов, блокирующих основной поток, по прежнему эффективно, но гугл в новых реалиях теперь не очень охотно прибавляет баллы за снятие блокировки основного потока.   Рекомендации гугла исчезают в этом плане, но баллов гугл теперь добавляет весьма жадною рукой.

Т.е. оптимизировать становится сложнее.

Раньше (два алгоритма назад) гугл весьма охотно увеличивал свою оценку при выполнении рекомендаций по оптимизации изображений, можно было легко получить прибавку в +50 баллов только лишь за оптимизированные изображения, но со сменой в свое время  алгоритма на Lighthouse 5 (это было уже давно)  гугл за оптимизацию изображений стал давать существенно меньше баллов.

 

sitecreator_ru_LtSGGxCGgg.jpg

 

 

В любом случае вес и кол-во загружаемых файлов изображений влияет на параметр "время загрузки для взаимодействия". Это важный параметр, на основании которого гугл высчитывает общую оценку для страницы сайта.  Поэтому снижение веса файлов изображений и применение lazy load для них уменьшает этот параметр и увеличивает соответственно оценку гугла.

Это касается в принципе любых загружаемых файлов. Просто изображения обычно занимают существенный вес, который можно снизить за счет формата webp, например.

 

 

 

sitecreator_ru_vmDl2qP4cC.jpg

Link to comment

Изменения в оценке гугла и работы способов оптимизации покажу на конкретном примере.

 

Старый и новый алгоритмы гугла соответственно:

 

n6639tG.jpg

 

LMJb72m.jpg

 

Как видим,   стартовать приходится уже с более низкой позиции:  с 39 баллов против 52 по старому алгоритму.

Прирост всего +34 балла (по новому алгоритму гугла) против прироста в +44 балла по старому.

 

Оптимизация стала сложнее и менее эффективная в полуавтоматическом режиме.

Но результат есть.   Особенно если учесть довольно низкую стоимость подобной услуги.

 

Если нужен непременно взлет до 90+, то тут поможет полная переделка сайта или, как минимум, кропотливая ручная работа по стоимости на порядок выше чем просто установка и настройка оптимизации за счет модуля Hi-Optimizer.

 

Link to comment

Информация для размышления.

 

 

 

Получил такие результаты после моей оптимизации:

Это мультфильмы в формате GIF

 

sitecreator_ru_R3wjaCk9hb.gif

 

 

sitecreator_ru_oB40UNu0ex.gif

 

 

а начинал с этого:

 

PNtToIX.jpg

 

 

 

Как видите, в разных замерах гугл показывает для мобильных итоговый балл либо 67, либо 97.

Картинка одна и та же отрендерилась, за одним небольшим исключением.

 

x5tGmUm.jpg

 

sitecreator_ru_bNqJbk8PKx.jpg

 

 

sitecreator_ru_vq0AeOQMot.jpg

 

 

 

Разница в виджете "Сообщение".

Прошу заметить, что гугл в одном случае отловил этот виджет и снизил оценку. А в другом случае - нет.

И данный виджет не блокирует основной поток по замерам гугла. Но как-то тормозит весь сайт.

 

sitecreator_ru_4LwB7gW1KU.jpg

 

 

 

 

 

Link to comment

sitecreator_ru_5o7CMICI7v.jpg

 

 

sitecreator_ru_yAB0bMl3xn.jpg

 

 

 

Видно, что данный виджет подключается уже в конце формирования страницы на самом последнем этапе.

И гугл иногда его захватывает для оценки, а иногда - нет.

Но на оценку появление данного виджета раньше времени влияет сильно.

 

 

Но никаких рекомендация в плане блокировки основного потока или еще что-то гугл не дает:

 

sitecreator_ru_KaMVfEcp1h.jpg

 

 

Но вы должны понимать насколько сейчас сильно зависит оценка гугла при детекте этого виджета и при отсутствии такового.

Предварительный вывод такой - виджет данного чата необходимо отложить. Нескольких секунд будет достаточно.

Link to comment

Отложил выполнение данного виджета чата.

 

результат в 95 ...97 получен для мобильных.

Вы можете отложить подключение данного виджета любым удобным вам способом.

Я делаю это легко с помощью своего модуля без всякого изменения кода и без копания в коде.

 

Тем более, что в модуль встроен анализатор кода. Он вам сам подскажет нужный кусок, который он найдет для оптимизации.

 

 

sitecreator_ru_EyEe795MTv.jpg

 

 

В итоге получил такой результат:

 

Za686iQ.jpg

 

https://lh6.loading.express/

 

поскольку гугл периодически глючил сегодня, то воспользовался альтернативной проверкой в

Lighthouse 6

по указанной ссылке.

 

 

Для страницы товар получил вообще 99 балла после откладывания виджета чата:

 

heYdIan.jpg

 

 

Для Главной с отложенным виджетом  даже 100 для мобильных и десктопов.

 

RMboHG4.jpg

 

PvlYTsn.jpg

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.