Клиентская оптимизация *

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

Привет, Хабр! Меня зовут Слава Волков, и я фронтенд-разработчик в Badoo. Сегодня я хотел бы немного рассказать про сбор статистики с фронтенда.

Мы знаем, что аналитика позволяет оценить эффективность работы любого веб-сайта, улучшить его работу, а значит, повысить уровень продаж и усовершенствовать взаимодействие пользователей с сайтом. Проще говоря, аналитика – это способ контроля над процессами, происходящими на веб-сайте. В большинстве случаев для обычных сайтов достаточно установить Google Analytics или «Яндекс.Метрику» – их возможностей вполне достаточно.

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

• На 14% меньше, чем WebP, без потерь
• На 22% меньше, чем BPG, без потерь
• На 33% меньше, чем сжатый через ZopfliPNG PNG-файл
• На 43% меньше, чем обычные PNG-файлы
• На 46% меньше, чем оптимизированные по Adam7 чересстрочные PNG-файлы
• На 53% меньше, чем JPEG 2000, без потерь
• На 74% меньше, чем JPEG XR, без потерь

Каждый раз начиная писать React приложение, вы так или иначе выберите какой-то вариант:

• копи-паст вашего предыдущего проекта
• какой-то бойлерплейт или даже генератор (типа Yeoman)
• готовый фреймворк не требующий конфигурации
• пишете сами все с нуля

Каждый из способов имеет свои сильные и слабые стороны, как на длинной, так и на короткой дистанции.

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

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

И тогда приходит он, рефакторинг платежного процесса. Но мы решили сделать процесс еще интереснее, добавив к рефакторингу идеи IDEF-0.

В прошлом году Яндекс провел образовательный экспериментальный проект, который получил название «Мобилизация». Наша цель была в том, чтобы участники поработали в настоящей команде и создали настоящий продукт — причём продукт мобильный. «Мобилизация» объединила Школу мобильной разработки, Школу менеджеров, Школу мобильного дизайна и Школу разработки интерфейсов.

Мы пригласили 126 студентов из 25 городов; 91 участник успешно завершил программу. Первый этап состоял из лекций, второй — из той самой командной работы. Обычно студента окружают люди той же специализации, что и он сам: менеджеры учатся вместе с менеджерами, дизайнеры — с дизайнерами и т. д. Но в реальности вам нужно хотя бы по одному представителю нескольких профессий. В каждую команду вошли студенты разных школ: дизайнер, менеджер и один-два разработчика.

Лекции студентам читали сотрудники Яндекса, которые каждый день сталкиваются с реальными задачами и делают приложения для миллионов пользователей. Специально для читателей Хабра мы собрали полную программу курса по мотивам лекций «Мобилизации».

Анатолий Орлов ( anatolix ), Денис Нагорнов ( Яндекс )

Думаю, все уже знают, что современные браузеры умеют рисовать некоторые части страницы на GPU. Особенно это заметно на анимациях. Например, анимация, сделанная с помощью CSS-свойства transform выглядит гораздо приятнее и плавнее, чем анимация, сделанная через top/left. Однако на вопрос «как правильно делать анимации на GPU?» обычно отвечают что-то вроде «используй transform: translateZ(0) или will-change: transform». Эти свойства уже стали чем-то вроде zoom: 1 для IE6 (если вы понимаете, о чём я ;) для подготовки слоя для анимации на GPU или композиции (compositing), как это предпочитают называть разработчики браузеров.

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

Борис Каплуновский (BSKaplou)

Андрей Ситник (Iskin, Злые марсиане)