Комментарии 39
Сейчас бы для каждой строчки писать
<?php .... ?>
И мои супер любимые конструкции вида
<?php } ?>
Что же вы так не любите всех, кто после вас будет работать с кодом?
- А зачем делать
clearTimeout
в обработчикеsetTimeout
? - Зачем вообще ради какой-то пузомерки заставлять пользователей страдать еще дольше, так как теперь мало дождаться загрузки страницы, она ведь еще будет "лагать" какое-то время (те самые 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 её поднять. Если не надо, то и не надо. Чат для пользователя не влияет на скорость погрузки информации.
Почитайте что такое фасады
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кб, можно ручками расширить, если позволяет хостинг.
Я бы стал грузить код не сразу при скролле, а по завершении первого скролла при остановке. Тогда, для пользователя по ощущениям "тормозов" должно быть меньше.
P.S. И сюда бы ещё завернуть всякие всякие метрики и аналитиксы. Только наверно поведенческие факторы у сайта понизятся.
Jivosite больше не снизит Google Speed