Как стать автором
Обновить

Комментарии 39

Google Speed это, конечно, мило и здорово, но грошь цена вашим разработкам, если этот треклятый живосайт специально дожидается клика пользователя по странице, чтобы не просто ВНЕЗАПНО выскочить поверх всего, но ещё и издать звук.

Ну он же и так выскакивает). Тут вопрос в приоритетах на конкретном проекте. У нас поставлен вот такой приоритет. Что лучше пользователю 1 раз в сессии пострадать, чем просадка -10)

Лучше убрать или спрятать его до востребования самим пользователем.

Сейчас бы для каждой строчки писать

<?php .... ?>

И мои супер любимые конструкции вида

<?php } ?>

Что же вы так не любите всех, кто после вас будет работать с кодом?

Просто внутри будет Javascript) мне показалось так читабельнее написать.

  1. А зачем делать clearTimeout в обработчике setTimeout?
  2. Зачем вообще ради какой-то пузомерки заставлять пользователей страдать еще дольше, так как теперь мало дождаться загрузки страницы, она ведь еще будет "лагать" какое-то время (те самые 1,46 секунды из отчета PSI/Lighthouse) после первого скролла (причем не сразу, а через 1 секунду, см. setTimeout).

clearTimeout - очищаю инициализатор. А так можно и не чистить конечно.

А по поводу страданий пользователя - тут конечно каждому своё). На моём проекте приоритет отдается скорости Google Speed. Ну а так кому как конечно. Если важно прогружать чат сазу - то так не пойдет.

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

Вы, наверное, путаете setTimeout и setInterval, т.к. первый никогда не будет вызван дважды (поэтому результат setTimeout нужно сохранять только в одном случае: если нужно будет отменить таймер до того, как он будет вызван). Если же цель в том, чтобы удалить переменную, которую непонятно зачем создали в объекте window, то для этого есть оператор delete. Как-то так.

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

Автор изобрёл клоакинг, поздравляю.

Он ведь не вредит никому, при том один раз в сессию. Это мизер неудобств.

Он ведь не вредит никому

Мне, например, такая подлянка с чатом вредит, вплоть до отвращения к сайту и ухода с него. Следовательно, ваше утверждение ложно. Но 10 долларов попугаев Google speed - это 10 попугаев...

Вы же бездействуете на сайте пару секунд. Если не знать о lazy чата, то разница на мой взгляд несущественна. Наоборот, вы зашли и ничего не выскакивает, поскролили - высочило. При том такая прогрузка лишь при первом визите.

Но кому как. Я не настаиваю на абсолютной целесообразности способа. Просто когда мобила всего 20, 10 попугаев уже играет роль, когда заказчику это важно.

зашли и ничего не выскакивает, поскролили - высочило

Вот это и убивает напрочь.

Pagespeed это просто тест. Данные о скорости сайта есть синтетические и реальные полевые. Поисковик собирает данные по реальным. Об этом написано в описании Pagespeed например. Если есть субъективные факторы понижения баллов именно в тесте, стоит ли так гнаться за синтетикой? Всё равно скорость будет фиксироваться по Network браузера каждого посетителя, а у каждого своё железо и свой канал. Может стоит таки читать описание теста?)

Не всегда можно не делать то, что просят сделать). У меня была конкретная задача, подтянуть Google Speed.

Мы вертелись как могли XD)

И продолжаете писать тут что Pagespeed так важен. Надо объяснять же тем кто не понимает, что Pagespeed просто образец синтетик проверки, которая не зависит зачастую от скорости сайта как её измеряют поисковики. Люди понятно что им проще глянуть 1 тест цифры, чем хотя бы прочесть описание теста, но надо объяснять, а не культивировать дальше мифы.

Я в первую очередь написал это для тех, кому это нужно. Даже на сайте Jivosite описана данная проблема. У меня она также возникла, нашел решение. А в СЕО я слаб, не могу проанализировать с этой стороны. Была задача. Вот решение. Плохое или хорошее решать вам. На проекте всех устроило. Поэтом решил поделиться здесь.

Это не SEO - это описание теста Pagespeed. Полевое и синтетическое исследование. Бьётесь за то, за что бороться не стоит. Ибо вместо цифр синтетики в тесте смотреть надо Network - чтобы понимать тормозит Jivosite сайт или нет.

Вы предлагаете в этом случае не делать задачу?) я и не говорил про тормоза сайта, я говорил про проседания г. спид. Может еще кому-то надо за счет jivo её поднять. Если не надо, то и не надо. Чат для пользователя не влияет на скорость погрузки информации.

Вот стоило бы замерить скорость именно, а не баллы за синтетик оценку, показать заказчику, дать почитать описание Pagespeed - документация. То что вы сделали хорошо, но бесполезно в плане скорости.

Почитайте что такое фасады

clearTimeout(window.jivoLazyTimeout);

Лишняя конструкция

document.getElementsByTagName('body')[0]

Можно просто `document.body`

if ( typeof window.addEventListener === 'undefined' ) {
	elm.addEvent(event, jivoAsync);
} else {
	elm.addEventListener(event, jivoAsync, false);
}

IE8 поддерживаете?

В этом же фрагменте не увидел как вы снимаете листенер. Получается, он у вас на каждый скролл, клик и движение мышкой отрабатывает, но потом выходит из функции jivoAsync на строчке `if ( typeof window.jivoLazyReady === 'undefined' )`. Не идеально.

Лучше так (с учетом предыдущего замечания):

var eventTypes = ['mouseover', 'click', 'scroll']

function listener() {
  var target = this
  
  jivoAsync()
  
  eventTypes.forEach(function(eventType) {
    target.removeEventListener(eventType, listener)
  })
}

events.forEach(function(eventType) {
  var elm = event === 'click' ? document.body : window

  elm.addEventListener(eventType, listener)
})

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

Также, поскольку код виджета был предназначен для использования внутри `<script>`, оборачивать код инициализации виджета в функцию нет смысла.

function jivoAsync() {
  setTimeout(function() {
  	var widget_id = '#widgetID#';
    var d = document;
    var w = window;

    function l() {
        var s = document.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);
    }
    if (d.readyState == 'complete') {
        l();
    } else {
        if (w.attachEvent) {
            w.attachEvent('onload', l);
        } else {
            w.addEventListener('load', l, false);
        }
    }
  }, 1000)
}

Поскольку у нас на момент таймаута страница уже загрузилась, то код инициализации виджета можно сильно сократить. Также, нет никакого смысла выискивать первый скрипт на странице, можно просто вставить в конец body:

function jivoAsync() {
  setTimeout(function() {
    var widget_id = '#widgetID#';
    var s = document.createElement('script');
    s.type = 'text/javascript';
    s.async = true;
    s.src = '//code.jivosite.com/script/widget/' + widget_id;
    document.body.appendChild(s)
  }, 1000)
}

Это то что в глаза бросилось

С removeEventListener спасибо. Надо будет допилить)

Но, позвольте, разве removeEventListener не удалит чужие экшны? Это здесь код чистый. А на реальном проекте 100500 скриптов. Т.к. window, body общие для всех элементы, разве это безопасно?

Нет. Ровно тот «слушатель», который вы навесили, вы и удаляете.

Спасибо, прокачали мне знания)

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

Про картинки - так и делают) называется ленивая загрузка.

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

как 500ая ошибка может появиться из-за большого кол-ва кук?

Если на сайте много кук, и их общий вес слишком большой, то да, в этом случае выскакивает у пользователя 500.

куки не хранятся "на сайте", куки хранятся только в браузере пользователя

Куки отправляет из браузера на сервер. Если их вес слишком велик, сервер выдает 500

а насколько "большие" должны быть куки, чтобы сервер выдал 500?

в вашем случае достаточно было добавить 1 куку - jivoLazy=ready

Кука да куки, 2 куки) дело не в том, что она маленькая, дело в экономии. На боевом сайте с метриками и прочим, очень много кук. И экономия, как по мне, не лишнее.

Чтобы выдало 500 зависит от настроек сервера. По-моему размер буфера для клиента. Возможно ошибаюсь, но чаще всего он 8кб-16кб, можно ручками расширить, если позволяет хостинг.

ни разу не встречал такого размера кук

и как-то странно "экономит"ь 16 байт из 8кбайт, храня что-то дополнительно в сессии (а она как раз на сервере хранится)

Дело вкуса)

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

P.S. И сюда бы ещё завернуть всякие всякие метрики и аналитиксы. Только наверно поведенческие факторы у сайта понизятся.

По сути setTimeout в 1с и говорит о завершении скролла.

По метрикам. аналитике - да, точность упадет.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории