A b javascript: Math.abs() — JavaScript | MDN - Блог сумасшедшего сисадмина

Содержание

FrontFest.Mix — 7 тем о кодстайле, WebGL, A/B, RON, шаблонизации, экосистеме JavaScript и жизни программиста / Хабр

Можно не знать о модных технологиях, не думать о доступности сайтов, забивать на развитие экосистемы, но, кажется, через год-другой с таким подходом можно стать таксистом-программистом. Нам эта история не близка, поэтому на конференции FrontFest, кроме понятных всем потоков VYORSTKA и JS, мы заложили в программу поток MIX. Как ясно из названия, он для докладов, которые не вписываются в первые два потока — это выступления о кодстайле, производительности фронтенда, форматах данных, экосистеме JavaScript и развитии фронтендера как разработчика.

§ Про кодстайл

Уверены, никому не нужно объяснять, зачем нужны чистота и порядок в проекте. Но и тратить на поддержание единой стилистики в коде кучу времени тоже не дело. Антон Немцев, в своем докладе «Кодстайл и насилие», расскажет нам, как выбрать кодстайл и контролировать его использование с помощью разнообразных инструментов и толики насилия. Антон — основатель и редактор электронного журнала Frontender Magazine, спикер международных и локальных конференций и представитель Web Standards в Украине.

§ Про фреймворки, форматы данных и скиллы

Разработчики не всегда имеют достаточно опыта и/или времени для того, чтобы оценить, каких знаний им не хватает. Мы приготовили для вас доклад-лайфхак. Екатерина Пригара, менеджер продукта IDE WebStorm, уже больше четырёх лет наблюдает за экосистемой JavaScript со стороны и готова этими наблюдениями поделиться. Доклад Екатерины поможет с выбором фреймворка, суперсета языка или чем-то еще массивным.

А вот о том, как выбрать формат данных для синхронизации с сервером расскажет небезызвестный любитель холиваров Виктор Грищенко. В прошлом году на CodeFest он рассказывал, как написать свой Protobuf на JavaScript, а на FrontFest расскажет о формате RON: покажет демки, расскажет про реализацию и про свой опыт работы с этим форматом.

Два предыдущих доклада достаточно ёмкие для того, чтобы закончить этот абзац, но есть и еще одна очень важная тема — а что вообще нужно знать разработчику, если не погружаться в подробности выбора языков и форматов? У Игоря Алексеенко за плечами немало лет фронтенд-разработки: JetBrains, студия Артемия Лебедева, дизайн-бюро Артёма Горбунова.

А теперь — преподавание в HTML Academy. Спустя столько лет разработки явно появляется понимание того, а что же всё это время нужно было изучать помимо фреймворков и прочего. Об этом — в докладе Игоря.

§ Про производительность

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

Тему производительности на FrontFest привозит Martin Splitt. Он пройдёт весь путь от пиксела до DOM и CSS, а также расскажет о том, как работают Canvas и WebGL, и как выжать из сайта все 60FPS.

Доклад Мартина дополнит Антон Епрев из Booking.com. Booking.com — как раз такая компания, которая выпускает свои фичи только после A/B тестирования, на протяжении которого снимает все метрики, включая fps и даже плавность скролла. О всех тонкостях контроля производительности в своём докладе расскажет Антон Епрев.

Это только начало. Кроме секции MIX, будут секции JS и VYORSTKA, а ещё — поток квартирников и поток воркшопов. О них мы расскажем в ближайший месяц, а пока ↓

Подписывайте на нас в твитерке, фейсбуке и вконтактике, а также смотрите в инстаграм.

Приходите, будет улётно!

Розповідаємо, як стати JavaScript Developer та дійти до позиції Senior

Привіт, спільното! Мене звати Влад Балабаш, я Solution Architect та Senior JavaScript Developer в AB Soft. Прочитав статтю про те, що на ринку IT з’явилася велика кількість Junior, та хочу трохи розповісти новачкам, до чого треба бути готовим під час роботи та якими навичками володіти для підняття кар’єрними сходами.

Трохи фактів про JavaScript

JavaScript є однією з найпотужніших та найгнучкіших мов програмування. 3 цікавих фактів про JavaScript:

вона забезпечує динамічну поведінку більшості, а саме 98%, вебсайтів;
з допомогою JavaScript можна запускати та тестити код в браузері без створення унікального середовища програмування або конфігурації в текстовому редакторі;
JavaScript дозволяє програмувати без компіляції.

З такою популярністю мови та її особливостями розробники JavaScript без роботи не залишаться 😉

На разі, JavaScript вийшов лише за межі Front-End. Багато компаній переходять на Back-End архітектуру, засновану на Node.js: Netflix перейшов на JavaScript, Uber теж вибрав Node.js.

Популярність мови беззаперечна, є багато причин, чому йдуть вчитися саме на JavaScript-Dev. Але давайте розберемося, якими навичками має володіти спеціаліст.

Якими навичками треба володіти для кожного з рівнів JavaScript Developer?

Trainee: Базові знання computer science, CSS, JS, HTML.

Junior: Тверді знання computer science, CSS, JS, HTML.

Middle: Вміння самостійно розв’язувати задачі, працювати з алгоритмами. Розуміння, як ці алгоритми використовувати в різних задачах. Знання принципів роботи з парадигмами (OOP, FP) та протоколами (TCP, HTTP etс).

Senior: Має навички розв’язувати задачі та знаходити рішення різних проблем різного рівня складності. Має ідеальні знання інструментів, з якими працює: мови програмування (JavaScript та інші, з якими він працює), фреймворки, всі перелічені раніше навички, але вже на високому рівні.

Чи є життя ПІСЛЯ Senior?

Для багатьох починаючих все закінчується саме на рівні Senior. Здається, що далі вже ну йти нема куди, стелі досягнуто. Але це не зовсім вірне ствердження. В багатьох компаніях після Senior можна стати Expert або Architect.

Expert володіє концентрованими знаннями та навичками в певній сфері розвитку.

Architect — спеціаліст з глибинними знаннями у сферах своєї роботи. Наприклад, це водночас й Java, й Node.js, й JavaScript.

На які computer science новачку треба звернути увагу?

Важливо пам’ятати про те, що фундаментальні знання та розуміння CS відіграють дуже велику роль в роботі та розвитку в кар’єрі. На перших етапах важливо розуміти:

як працюють алгоритми та протоколи;

що таке структура даних;
теорію та основні методи мов програмування;
основні правила та архітектурні підходи.

Сучасні проєкти складаються з багатьох сервісів та додатків, які працюють на різних платформах та з різними протоколами. Всі проєкти розділені мінімум на 2 частини: Front-End та Back-End.

Останні декілька років ділять Front-End та Back-End на, так звані, мікросервіси. Наша задача — зв’язати всі ці маленькі частини в одне ціле, щоб користувач міг ними користуватися. Для цього використовуються протоколи зв’язку.

Тому для JavaScript Dev вкрай важливо знати, як працюють протоколи TCP/UDP, HTTP(s), protobuf, WebSocket.

Які інструменти знадобляться в роботі?

Їх можна поділити на декілька великих груп. По-перше, це Task Runners. Grunt, Broccoli.JS, Gulp. Також знадобляться інструменти для:

Контролю версій. SVN, GIT, TFC.
Бандлінгу (це процес об’єднання імпортованих файлів в один файл, зшивання коду). Це WebPack, Wite, RollUp, Parcell тощо.
Контролю синтаксису коду. EsLint/TsLint, Prettier.
Тестування версій. Jasmine, Mocha, PhantomJS, Protractor.
Безпеки. Snyk, Node Security Project, RetireJS, Gemnasium, OSSIndex.

І це тільки частина інструментів.

Soft-skills для JavaScript-розробників

Софт-скіли — важливий топік для роботи в IT. Всі, хто планує опанувати професію на рівні Senior має пам’ятати, що окрім практичних професійних навичок в нього також мають бути певні комунікаційні та особисті якості.

На першому місці — стресостійкість. Питання стресостійкості для будь-якого розробника, для будь-якого спеціаліста IT, є вкрай важливим.

По-перше, це важливо в роботі над складними або терміновими проєктами.

По-друге, це важливо для організації роботи (овертайми, особистий час, робота в умовах війни).

Все це гарний спеціаліст має вміти менеджерити.

Javascript-dev має вміти вправно комунікувати з командами, з замовником, делегувати деякі задачі, які не пов’язані з його зоною відповідальністю.

Невміння спілкування додає стресу в роботі. І знову ми повертаємося до першого пункту.

Друга важлива навичка — вміння презентувати себе, проєкти, нових членів команди. Від цього часто залежить успіх в будуванні спільноти навколо себе, в затвердженні проєктів тощо.

Як Senior, Javascript-dev має вміти вправно працювати з тайм-менеджментом: мітинги, дейлінги, планінги тощо.

Програміст — така професія, яка потребує постійного самовдосконалення. Технології з’являються кожен тиждень, а в Javascript майже кожну хвилину виходить нова бібліотека, кожен день нові фрейморки.

Вам потрібно встигати за всіма оновленнями, за роботою, за навчанням та самовдосконаленням. Тут без тайм-менеджменту буде важко.

Senior володіє дуже глибокими менеджерськими скілами та навичками team-менеджмента:

допомогти команді в момент, коли в цьому є потреба;

провести менторінг та, якщо потрібно, навчання Trainee або Junior;
показувати команді нові інструменти, демонструвати принципи їх роботи тощо.

І, найважливіше, що має бути — навичка прийняття рішень. Менеджер може приймати рішення за команду, брати на себе відповідальність за ці рішення та їхні наслідки, спілкуватися з замовником та консультувати його в прийнятті його рішень.

Коли спеціаліст володіє таким скіллом, то він гарантовано може бути тім-лідом.

Звичайно, вкрай важливим є аналітичний склад розуму, вміння розбити задачу на певні підзадачі (навичка декомпозиції), вміння пояснити алгоритм виконання певних задач. Та, звичайно, мислити нестандартно.

Як краще вивчати JavaScript?

Є два шляхи, як можна вивчати JavaScript:

Самостійно. За допомогою роботи та вивчення відкритих ресурсів.

На курсах. Вивчаючи мову за допомогою викладача, ментора, набираючись досвіду в команді однодумців.

Я вважаю, що найкраще рішення — об’єднувати ці стратегії. Тобто, навчання на курсах допоможе структурувати знання, отримату певний фундамент, розширити розуміння профессії.

Але після закінчення курсів не треба вважати, що вже все відомо та зрозуміло. Це, як я вважаю, основна помилка. Як тільки з’являється думка: «Я все знаю, більше навчатися не треба» — в цей момент наступає плато у кар’єрі.

Після закінчення курсів варто виробити в себе декілька важливих звичок:

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

Всі ці навички важливі та корисні в будуванні кар’єри. Я буду радий коментарям та обговоренню теми. Дякую за увагу!

P.S.: Ресурси, які стануть в нагоді майбутнім JavaScript-dev

Посилання на сайти:

https://www.patterns.dev

https://roadmap.sh/frontend

https://www.indeed.com/career-advice/career-development/organization-skills

https://www.youtube.com/c/ITBEARD

Посилання на канали Telegram:

https://t.me/+77JmQKiR2qk5NDky

https://t.me/forwebdev

https://t.me/front_end_dev

Якщо ви хочете поділитися з читачами SPEKA власним досвідом, розповісти свою історію чи опублікувати колонку на важливу для вас тему, долучайтеся. Відтепер ви можете зареєструватися на сайті SPEKA і самостійно опублікувати свій пост.

Спільнота JavaScript робота поради кар’єра в IT розробка Спільнота

50 UAH 150 UAH 500 UAH 1000 UAH 3000 UAH 5000 UAH

Производительность тегов JavaScript AB Tasty и анализ отчетов

Здравствуйте! Я Лео, менеджер по продукту в AB Tasty. Я отвечаю, среди прочего, за наш тег JavaScript, который в настоящее время используется на тысячах веб-сайтов для наших клиентов. Как вы можете догадаться, моя дорожная карта полна тем, касающихся сбора данных, конфиденциальности и… производительности .

В сегодняшней статье мы поговорим о производительности тегов JavaScript, мониторинге открытых данных и конкуренции. Пойдем!

- Исследование производительности
- Является ли CRO тем же, что и аналитика?
- Отчет
- Что-то не так с отчетом?
- Анализ
- Результаты
- Копаться в деталях
- Фигурки участников
- Что мы можем сделать из этого?

Исследование производительности

Поскольку производительность стала большой и горячей темой в течение последних нескольких лет, в основном благодаря инициативе Google по развертыванию их Core Web Vitals, моя команда и я уделили этому много внимания. Мы многое изменили, улучшили многие части нашего тега и достигли отличных результатов. Многие из наших пользователей выразили свое удовлетворение этим. Я уже сделал (длинную) серию статей в блоге об этом здесь. Извините, но это только на французском языке. 😊🥖

Время от времени конкуренты щекочут нас конкретным отчетом о производительности, который, судя по некоторым показателям, показывает, что мы неэффективны. Некоторые конкуренты утверждают, что они до 4 раз быстрее нас! И это правда, я имею в виду, это то, что показывает отчет.

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

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

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

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

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

CRO — это то же самое, что и аналитика?

В отчете (обещаю, я подробно расскажу об этом ниже 😄) мы сгруппированы в категорию «Аналитика». Однако Оптимизация коэффициента конверсии — это не то же самое, что Аналитика . Инструмент аналитики собирает данные только тогда, когда мы активируем кампании, запускаем персонализацию, внедряем виджеты, добавляем всплывающие окна и многое другое. В этом смысле наше влияние будет выше.

Давайте поговорим о наших конкурентах: несмотря на то, что у нас есть лучшее решение (😇), наши конкуренты делают более или менее то же самое, что и мы, используя ту же технику с теми же ограничениями и проблемами. Поэтому вполне законно сравнивать нас по одним и тем же метрикам. Возможно, мы делаем немного больше, чем они, но, в конце концов, это не должно объяснять 4-кратную разницу в нашей производительности.

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

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

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

Отчет

Отчет представляет собой набор данных, ежемесячно генерируемый HTTP-архивом. Вот цитата с их страницы «О компании»:

«Успешные общества и институты осознают необходимость записи своей истории — это дает возможность просмотреть прошлое, найти объяснения текущему поведению и выявить новые тенденции. В 1996 году Брюстер Кале осознал культурное значение Интернета и необходимость записи его истории. В результате он основал Интернет-архив, который собирает и постоянно хранит оцифрованный контент Интернета».
«В дополнение к содержанию веб-страниц важно записывать, как создается и обслуживается этот оцифрованный контент. HTTP-архив предоставляет эту запись. Это постоянное хранилище информации о веб-производительности, такой как размер страниц, неудачные запросы и используемые технологии. Эта информация о производительности позволяет нам видеть тенденции в том, как строится Интернет, и предоставляет общий набор данных, на основе которого можно проводить исследования веб-производительности».

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

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

Это то, что сделал изобретатель Google Lighthouse Патрик Халс. На своем веб-сайте GitHub он обеспечивает хорошую визуализацию этого огромного набора данных и позволяет любому углубиться в детали в нескольких категориях, таких как аналитика, реклама, социальные сети и другие. Как я уже сказал, вы найдете инструменты CRO в категории Analytics.

Исходный код сайта полностью открыт. Методология известна и доступна.

Итак, что не так с отчетом?

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

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

Одна проблема, не связанная с самим отчетом, заключается в том, что ошибка может быть вызвана усреднением . Это также то, о чем мы все знаем, но склонны забывать. Если вы возьмете 10 человек, 9 из которых зарабатывают 800 евро в месяц, а один зарабатывает 12 миллионов евро в месяц, то мы можем сделать вывод, что каждый зарабатывает 1,2 миллиона евро в месяц. Статистически правильно, но звучит немного неправильно, не так ли? Подробнее об этом через минуту.

Зная это, пришло время немного испачкать руки. Вместе с моей командой мы загрузили полный набор данных за февраль 2023 года, чтобы провести собственный аудит и понять, где у нас были утечки производительности.

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

Анализ

В этом наборе данных мы можем найти полный список просканированных веб-сайтов с AB Tasty и влияние на них нашего тега. Чтобы быть более точным, у нас есть точное измеренное время выполнения нашего тега в миллисекундах.

Вот что мы извлекли. Пиксельный столбец — это URL-адрес веб-сайта. Последний столбец — время выполнения в миллисекундах.

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

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

Среднее время выполнения

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

Средняя верхняя половина и средняя нижняя половина

Затем я разделил набор данных пополам. Если у меня 2000 строк, я создаю две группы по 1000 строк. «Выше» и «ниже». Это помогает мне получить представление о веб-сайтах, на которых мы работаем, — худших по сравнению с лучшими. Затем я вычисляю среднее значение каждой половины.

Разница между двумя половинками

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

Количество сайтов со значением выше 6k мс

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

Эволюция последнего набора данных

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

Результаты

Вот результаты, которые у нас есть:

Вот их соответствующие графики:

Это эволюция между октябрем 2022 года и февралем 2023 года:

Внимание: Логари шкала! Отсортировано по времени выполнения в феврале 2023 года слева направо.

Цифры говорят сами за себя. Но если я могу сделать глобальный вывод, так это то, что мы добились огромных улучшений за первые шесть месяцев и немного застопорились после более тонких корректировок (знаменитые 80/20 Парето).

Однако после первоначального падения важны два показателя.

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

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

Копание в деталях

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

Однако, как говорится, дьявол кроется в деталях . Давайте немного покопаемся.

Давайте сосредоточимся на веб-сайтах, на которых AB Tasty выполняется более шести секунд.

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

В отчете за февраль 2023 года их 33. Это среднее время выполнения 19877 мс. Я быстро определил, что:

27 из них от одного и того же клиента AB Tasty
Одним из них является abtasty.com, и общее исполнение ресурсов, поступающих с *abtasty.com на этом сайте, очень высокое 😊
Два других также поступают от одного единственного клиента AB Tasty

В итоге в этом списке всего 5 клиентов (но все же 33 веб-сайта, не поймите меня неправильно).

Давайте теперь попробуем сгруппировать этих двух клиентов с дубликатами, чтобы увидеть среднее влияние. У клиента с 27 дубликатами также есть веб-сайты, размер которых ниже отметки 6 КБ мс, но я пока проигнорирую это (и чтобы облегчить ситуацию).

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

Я также собираюсь удалить abtasty.com, который не актуален.

С новым списком я перешел от 1223 мс для полного среднего списка к 1005 мс . Я только что улучшил наше среднее значение более чем на 200 мс! 🎉

Подождите, что? Но вы просто удаляете худшие сайты. Очевидно, тебе становится лучше…

Да, это правда. Это точно обман! Но смысл всей этой статьи в том, чтобы продемонстрировать, что данные не говорят всего.

Давайте сначала поговорим о том, что происходит с этим клиентом, у которого есть 27 дубликатов.

Один и тот же тег был развернут более чем на 50 очень разных веб-сайтах ! Возможно, вы не очень хорошо знакомы с AB Tasty, поэтому позвольте мне объяснить, почему это проблема.

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

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

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

Примечание: Если вы начнете использовать AB Tasty, вам не будет рекомендовано это делать. Кроме того, производительность вашего тега будет намного лучше, чем у .

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

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

Цифры конкурентов

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

Повторю еще раз: я не пытаюсь сказать, что мы лучше (или хуже) любого из наших конкурентов, это не моя точка зрения. Я просто пытаюсь показать вам, почему статистика должна быть тщательно проанализирована, чтобы избежать ошибок интерпретации .

Начнем со сравнения показателей AB Tasty за февраль 2023 года с такими же показателями одного из них.

В целом они выглядят немного лучше, правда? Лучше среднее и даже средства для каждой половины лучше (и для нижней половины намного!).

Однако между двумя половинками коэффициент огромен: 24! Означает ли это, что в зависимости от вашего использования влияние их тега может увеличиться в 24 раза?

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

Но это будет интерпретация очень небольшой части того, что говорят данные .

Кроме того, у них более чем в два раза больше веб-сайтов, превышающих отметку 6k ms (опять же: эта отметка является внутренней вещью AB Tasty). И это благодаря сохранению дубликатов в наборе данных AB Tasty, о котором мы только что говорили! У них тоже есть дубликаты, но не так много, как у нас.

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

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

Из 2537 просканированных веб-сайтов 40% принадлежат одному и тому же клиенту. Это представляет 1016 поддоменов одного и того же домена.

Как это повлияет на их счет?

Ну, их клиент не использовал решение на момент сбора данных (я убедился в этом, посетив некоторые поддомены). Это означает, что тег вообще ничего не делал. Он был там, но не активен.

Среднее время выполнения этих 1016 строк в наборе данных составляет 59 мс !! 😭 Он также имеет максимальное значение 527 мс и минимальное значение 25 мс.

Мне не нужно объяснять, почему эта «аномалия» интересно снижает их средний показатель, верно?

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

Чтобы закончить, давайте сравним среднее значение двух наших наборов данных после удаления этих 1016 субдоменов.

AB Tasty находится на уровне 1223 мс (нетронутый список), тогда как этот конкурент сейчас на… 1471 мс .

Они увеличились с 361 мс лучше до 248 мс хуже. Я сказал вам, что могу позволить цифрам говорить все, что захочу. 🙂

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

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

Что мы можем сделать из всего этого?

Первое, что я хочу сказать: ПРОВЕРЬТЕ .

Наше решение очень легко реализовать. Вы просто ставите тег на свой сайт и запускаете аудит. Для сравнения, вы можете поставить тег другого инструмента на свой сайт и запустить тот же аудит. Запустите его несколько раз с одинаковыми условиями и сравните. Второй инструмент лучше на вашем сайте? Хорошо, тогда он, вероятно, будет работать лучше для вашего конкретного случая.

Случайный отчет в сети говорит о том, что одно решение лучше другого? Хорошо, это один вывод, но вы должны либо переработать данные, чтобы бросить им вызов, либо не уделять им слишком много внимания. Просто принимая цифры в том виде, в каком они отображаются (или, что еще хуже, в рекламе…), вы можете упустить большую часть истории.

У AB Tasty плохая производительность?

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

Итак, некоторые клиенты жалуются?

Да. Это связано с тем, что иногда AB Tasty может иметь более низкую производительность в зависимости от вашего использования. Но, , мы предоставляем инструменты, которые помогут вам оптимизировать все прямо с нашей платформы. Мы называем это Performance Center . Это полноценный раздел внутри платформы, посвященный тому, чтобы показать вам, какая кампания влияет на вашу эффективность и что вы можете сделать, чтобы ее улучшить. Просто следуйте инструкциям, и у вас все получится. Это очень инновационная и уникальная функция на рынке, и мы очень гордимся ею.

Тем не менее, я должен признать, что несколько клиентов (всего несколько) имеют нереалистичные ожидания относительно производительности. AB Tasty — это JS-тег, который выполняет манипуляции с DOM, асинхронные проверки, сбор данных и много всяких причудливых вещей. Конечно, это повлияет на ваш сайт больше, чем простой инструмент аналитики. Ваша цель — убедиться, что эффект от оптимизации ваших конверсий выше, чем это стоит вам с точки зрения производительности. И это будет одинаково, какой бы инструмент CRO вы ни использовали, за исключением случаев, когда вы используете инструмент на стороне сервера, например, Flagship от AB Tasty.

Я убежден, что мы должны стремиться к более быстрой сети. Я очень беспокоюсь о своем влиянии на окружающую среду и стараюсь сохранить свои устройства как можно дольше. Моему смартфону 7 лет (и сейчас я перехожу на другой, которому 10 лет), и мой ноутбук тоже не самый новый. Итак, я знаю, что медленный сайт может быть проблемой.

Заключительные замечания

Позвольте мне заверить вас, что в AB Tasty мы полностью привержены улучшению нашей работы , потому что наши клиенты ожидают, что мы это сделаем, потому что я лично заинтересован в этом, и потому что это очень весело и интересный вызов для команды (а еще потому, что меня об этом просит руководство 😅 ).

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

Хотите протестировать наш инструмент на себе? AB Tasty — это полная платформа для экспериментов, персонализации контента и рекомендаций на основе искусственного интеллекта, оснащенная инструментами, необходимыми для быстрого создания более богатого цифрового опыта для ваших клиентов. Благодаря встроенному искусственному интеллекту и автоматизации эта платформа может помочь вам добиться многоканальной персонализации и революционизировать ваш бренд и опыт работы с продуктом.

Рекомендации по A/B-тестированию для поиска | Центр поиска Google | Документация

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

Обзор испытаний

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

A/B-тестирование — это тестирование двух (или более) вариантов изменения. Например, вы можете протестировать разные шрифты на кнопке, чтобы увидеть, сможете ли вы увеличить количество кликов по кнопке.
Многовариантное тестирование — это когда вы одновременно тестируете более одного типа изменений, ищем влияние каждого изменения, а также потенциальную синергию между изменениями. Например, вы можете попробовать несколько шрифтов для кнопки, но также попробовать изменить (а не изменение) шрифт остальной части страницы в то же время. Новый шрифт легче читать и так надо везде использовать? Или преимущество в том, что шрифт кнопки выглядит иначе к остальной части страницы, помогая ей привлечь внимание?

Вы можете использовать программное обеспечение для сравнения поведения с различными вариантами ваших страниц. (части страницы, целые страницы или целые многостраничные потоки) и отслеживать, какая версия наиболее эффективным с вашими пользователями.

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

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

В зависимости от того, какие типы контента вы тестируете, может даже не иметь большого значения, будет ли Google сканирует или индексирует некоторые варианты вашего контента во время тестирования. Небольшие изменения, такие как размер, цвет или размещение кнопки или изображения или текст вашего «призыва к действию» («Добавить в корзину» вместо «Купить сейчас!»), может оказать неожиданное влияние на взаимодействие пользователей с вашей страницей, но часто практически не влияют на фрагмент результатов поиска или рейтинг этой страницы.

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

A b javascript: Math.abs() — JavaScript | MDN