Привет! Прошу прощения, что только сейчас дошли руки до твоего комментария, постараюсь дать ответы на все твои вопросы:
1) Не совсем понятен твой вопрос, но если я тебя правильно понял, то да - Салют Девайсы это все, что связано с умными устройствами, в том числе и с экосистемой внутри них 2) Порой одно и то же слово может иметь разные значения в зависимости от ситуации, как например слово "Драйвер" - для пк и для наушников обозначают разные вещи. В нашем случае Канвас - это aka приложения на умных устройствах 3) Clickhouse выбран потому что он имеет куда более высокую скорость чтения, лучше аггрегацию и лучше обрабатывает огромный поток данных 4) Нет, gigacode мы не мониторим 5) Грубо говоря - всё так. Если чуть более подробно, то в браузере есть PerformanceObserver - https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver, мы с помощью него (а точнее с помощью web-vitals - https://github.com/GoogleChrome/web-vitals) просто собираем метрики на стороне клиента, значения метрик и отправляем к себе в кликхаус 6) Image Size Score измеряет вес картинки на 75й перцентили, мы работаем с весом картинки 7) Под скриптами мы имеем виду файлы, которые прилетают к нам с типом "script" (это можно посмотреть во вкладке network в devtools). Тут мы тоже измеряем вес этих файлов (это просто .js файлы, а не скрипт), чтобы суммарно не пришлось долго скачивать эти файлы 8) Мы берем логнормальное распределение 9) Тут не так это работает. Speed Score - это оценка сайта, от 0 до 100, где 0 - это плохо а 100 - хорошо. Однако, если у сайта оценка 50 это не значит, что он работает "на троечку", все равно сайт работает не оптимизированно (ну а всё что ниже априори имеет очень плохие показатели и как следствие пользователям неудобно пользоваться этим сайтом), потому мы и взяли такие tresholds. Если значение выше 90, значит мы уверены, что у сайта всё супер с оптимизацией, а если 50 - значит какие-то вещи в нем хромают и пора смотреть в чём дело. В общем, Speed Score - это просто оценка, по которой легко понять "как дела" у сайта, а не среднее время работы сайта 10) Мы считаем от 2х дней и недели вплоть до нескольких месяцев 11) Всё верно, алертим раз в день. Если вышел новый релиз, то да, получим алерты по нему только на следующий день, но статистику мы можем увидеть и день-в-день, когда пользователи начнут пользоваться обновленным сайтом
Вроде на всё смог ответить, надеюсь ответил понятно и структурированно, жду фидбек!
По итогу на наших проектах мы избавились (и продолжаем избавляться) от некоторых "проблемных моментов", которые портят user experience. Например, на giga.chat у нас была проблема с каруселью, что при нажатии на кнопку прокрутка слайдов начиналась с задержкой (и из-за этого был плохой INP). Изучив flame chart после записи performance в devtools мы нашли вызовы функции, которые блокировали основной поток в тот момент, когда нужно было перелистывать слайды. При помощи requestIdleCallback мы перенесли эти вызовы на момент, когда основной поток будет свободен, тем самым карусель теперь работает отзывчивее)
Привет! Прошу прощения, что только сейчас дошли руки до твоего комментария, постараюсь дать ответы на все твои вопросы:
1) Не совсем понятен твой вопрос, но если я тебя правильно понял, то да - Салют Девайсы это все, что связано с умными устройствами, в том числе и с экосистемой внутри них
2) Порой одно и то же слово может иметь разные значения в зависимости от ситуации, как например слово "Драйвер" - для пк и для наушников обозначают разные вещи. В нашем случае Канвас - это aka приложения на умных устройствах
3) Clickhouse выбран потому что он имеет куда более высокую скорость чтения, лучше аггрегацию и лучше обрабатывает огромный поток данных
4) Нет, gigacode мы не мониторим
5) Грубо говоря - всё так. Если чуть более подробно, то в браузере есть PerformanceObserver - https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver, мы с помощью него (а точнее с помощью web-vitals - https://github.com/GoogleChrome/web-vitals) просто собираем метрики на стороне клиента, значения метрик и отправляем к себе в кликхаус
6) Image Size Score измеряет вес картинки на 75й перцентили, мы работаем с весом картинки
7) Под скриптами мы имеем виду файлы, которые прилетают к нам с типом "script" (это можно посмотреть во вкладке network в devtools). Тут мы тоже измеряем вес этих файлов (это просто .js файлы, а не скрипт), чтобы суммарно не пришлось долго скачивать эти файлы
8) Мы берем логнормальное распределение
9) Тут не так это работает. Speed Score - это оценка сайта, от 0 до 100, где 0 - это плохо а 100 - хорошо. Однако, если у сайта оценка 50 это не значит, что он работает "на троечку", все равно сайт работает не оптимизированно (ну а всё что ниже априори имеет очень плохие показатели и как следствие пользователям неудобно пользоваться этим сайтом), потому мы и взяли такие tresholds. Если значение выше 90, значит мы уверены, что у сайта всё супер с оптимизацией, а если 50 - значит какие-то вещи в нем хромают и пора смотреть в чём дело. В общем, Speed Score - это просто оценка, по которой легко понять "как дела" у сайта, а не среднее время работы сайта
10) Мы считаем от 2х дней и недели вплоть до нескольких месяцев
11) Всё верно, алертим раз в день. Если вышел новый релиз, то да, получим алерты по нему только на следующий день, но статистику мы можем увидеть и день-в-день, когда пользователи начнут пользоваться обновленным сайтом
Вроде на всё смог ответить, надеюсь ответил понятно и структурированно, жду фидбек!
По итогу на наших проектах мы избавились (и продолжаем избавляться) от некоторых "проблемных моментов", которые портят user experience. Например, на giga.chat у нас была проблема с каруселью, что при нажатии на кнопку прокрутка слайдов начиналась с задержкой (и из-за этого был плохой INP). Изучив flame chart после записи performance в devtools мы нашли вызовы функции, которые блокировали основной поток в тот момент, когда нужно было перелистывать слайды. При помощи requestIdleCallback мы перенесли эти вызовы на момент, когда основной поток будет свободен, тем самым карусель теперь работает отзывчивее)