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

Такой движок JS, как V8 (Chrome, Node) от Google, заточен для быстрого исполнения больших приложений. Если вы во время разработки заботитесь об эффективном использовании памяти и быстродействии, вам необходимо знать кое-что о процессах, проходящих в движке JS браузера.

Что бы там ни было — V8, SpiderMonkey (Firefox), Carakan (Opera), Chakra (IE) или что-то ещё, знание внутренних процессов поможет вам оптимизировать работу ваших приложений. Но не призываю вас оптимизировать движок для одного браузера или движка – не делайте так.

Задайте себе вопрос:
— можно ли что-то в моём коде сделать более эффективным?
— какую оптимизацию проводят популярные движки JS?
— что движок не может компенсировать, и может ли сборка мусора подчистить всё так, как я от неё ожидаю?



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

Это довольно вольный перевод статьи, которая попалась мне на просторах интернета. Её автор — TJ VanToll. Он уже много лет занимает веб-разработкой и, в частности, оптимизацией сайтов для большей производительности на мобильных телефонах. Под катом рассмотрены несколько способов оптимизации, а так же приведены результаты тестирования на различных устройствах.

Здравствуйте,

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



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

Представляем третий выпуск подкаста о технологиях, процессах, инфраструктуре и людях в IT-компаниях. Сегодня в гостях у “CTOcast” — Сергей Чернышев, один из лидеров Web Performance Optimization сообщества (Нью-Йорк).

В наше время скорость интернета довольно высока. Казалось бы, можно забыть о тех временах, когда нам приходилось ждать по 20-30 (а то и больше) секунд, чтобы веб-страница загрузилась и отобразилась на экране — теперь мы ждём отрисовки страницы в среднем около одной-двух секунд. Однако не стоит забывать, что значительная часть юзеров заходит на ваш сайт с мобильных устройств, на которых связь не всегда стабильна. В связи с этим будет совсем не лишним уделить немного внимания оптимизации вашего кода.

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

Коммуникация с пользователями важная составляющая любого проекта. Иногда нужно идти на встречу пользователям и первыми начинать диалог. Email-уведомления — идеальный способ сообщить человеку о каких-то изменениях и результатах. Это может привести к очень неожиданно приятным результатам. О том, как мы делали email-уведомления для LPCloud пойдет речь в этой статье.

Если ваш сайт медленно грузится, вы рискуете тем, что люди не оценят ни то, какой он красивый, ни то, какой он удобный. Никому не понравится, когда все тормозит. Мы регулярно добавляем в Яндекс.Почту новую функциональность, иногда — исправляем ошибки, а это значит, у нас постоянно появляются новый код и новая логика. Все это напрямую влияет на скорость работы интерфейса.



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

А вы помните свой первый компьютерный класс? Попробуем угадать: почти наверняка это было достаточно тесное помещение с плотным нагромождением парт в середине и расставленными на столах вдоль трех стен огромными ЭЛТ-мониторами и массивными «системниками». Ну и, конечно, преподаватель, который сначала со строгим видом объясняет новую тему у доски, после чего дает команду «по машинам!» и затем до конца урока бегает от одного ученика к другому, отбирая у каждого мышку для пояснений.

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

Представляем третий выпуск подкаста о технологиях, процессах, инфраструктуре и людях в IT-компаниях. Сегодня в гостях у “CTOcast” — Сергей Чернышев, один из лидеров Web Performance Optimization сообщества (Нью-Йорк).

Известный специалист по серверной и клиентской оптимизации, соавтор WebRTC, автор книги "High Perfomance Browser Networking" Илья Григорик из Google опубликовал презентацию “HTTP/2 all the things!”, в которой объясняет, как следует настраивать серверную часть под HTTP 2.0, чтобы повысить скорость загрузки страниц и уменьшить latency, по сравнению с HTTP 1.1.


Режим Connection View в браузере показывает загрузку элементов заглавной страницы Yahoo.com в HTTP 1.1

Илья начинает с того, что для современных сайтов бóльшая часть задержек приходится на ожидание загрузки ресурсов, при этом полоса пропускания не является ограничивающим фактором (синим цветом на диаграмме Connection View). По статистике, для загрузки средней веб-страницы браузер делает 78 запросов к 12 различным хостам (общий размер загружаемых файлов 1232 КБ).

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

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

Как показывает практика, бизнес-идея в большинстве случаев доходит до своего реального воплощения как минимум после значительных переработок, а зачастую – только после pivot’а – полного перезапуска стартапа, сопровождающегося радикальной сменой бизнес-модели. Связано это, в первую очередь, с тем, что на этапе формирования бизнес-модели основатель еще не знает точно, как она будет реализована в определенном бизнес-сегменте. Другими словами, если вы не работали в данной области раньше, не «погружены» в тонкости ведения бизнеса в конкретной сфере, эта самая сфера вашу бизнес-модель наверняка (и достаточно серьезно) скорректирует или вообще поставит перед фактом невозможности ведения бизнеса в такой форме, в которой он изначально задумывался.

Один из показательных примеров успешных pivot’ов: Groupon, который первоначально задумывался как альтернатива Kickstarter для некоммерческих проектов (в таком виде он не понравился инвесторам, которые не были уверены в возможности монетизации бизнеса). В качестве еще одного показательного примера часто приводят историю Twitter: прежде чем прийти к идее микроблогов его основатели разрабатывали платформу для подкастов Odeo, которая в итоге не выдержала конкуренции с iTunes.

В программе акселерации ФРИИ также принимали участие компании, которые столкнулись с подобными проблемами и с достоинством вышли из сложившейся ситуации, одна из них – стартап MoneyHero. На примере его истории мы попытаемся разобраться в том, как (на примере чужих проб и ошибок) выработать подходы, которые помогут вам оценить выбранную область бизнеса на предмет жизнеспособности вашей идеи, как можно быстрее проверить идею в деле и не совершать распространенных ошибок, сопутствующих стартапам на этом этапе.

Статья по мотивам Изображения в верстке. Хватит это терпеть. Скорее даже по мотивам комментариев к этой статье и в общем реакции хабра на призыв использования векторной графики везде, где можно и действительно нужно.

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

На текущий момент все более-менее просто. Мы можем верстать иконки с помощью SVG, создавать иконочные шрифты, ну и никуда не делась старая добрая техника с применением растра, в частности PNG. Правда добавились некоторые нюансы с появлением кучи HDPI устройств с совершенно разной плотностью пикселей.

На обучающем ресурсе Udacity запустился мини-курс по веб-производительности от сотрудника Google Ильи Григорика.

Google Pagespeed — утилита для анализа производительности клиентской части Web-приложения. Довольно обширный анализ укажет на те вещи, которые следует оптимизировать на сайте, повысив скорость и удобство для аудитории. Инструмент полезный и постоянно дополняется новыми возможностями. Проведем анализ Хабра и посмотрим на оценку и рекомендации, которые покажет нам Pagespeed.

Привет, Хабр.

В прошлый раз я рассказывал тебе, как мы написали Raw конвертер на JavaScript, а ты сказал мне, что он работает медленно. Сегодня я хочу рассказать о том, как мы ускорили наш raw.pics.io почти в 3 раза. Я не буду постить простыни кода с описанием каждого шага, постараюсь рассказать в общем виде о подходах к оптимизации, которые мы использовали. Также я решил не писать о доступе к DOM, уменьшении количества HTTP-запросов, склеивании и минификации файлов, опциях сжатия на сервере и т.д. Все это техническая работа

Мы в Яндекс.Почте совместно с командой Nginx провели исследование, чтобы на живом примере с подробностями расставить точки над «ё» в вопросе о том, насколько и за счет чего SPDY ускоряет интернет.

Про сам SPDY вы, конечно, знаете. В 2011 году несколько разработчиков компании Google опубликовали черновик нового протокола, призванного стать заменой привычному HTTP. Его основные отличия заключались в мультиплексировании ответов, сжатии заголовков и приоритизации трафика. Первые несколько версий были не вполне удачными, но к 2012 году спецификация устоялась, появились первые альтернативные (не из Google) реализации, доля поддержки в браузерах достигла 80%, вышла стабильная версия nginx с поддержкий SPDY.



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

Есть много интересных исследований вокруг SPDY, в том числе самого Google. Компания-автор протокола показывала, что в их случае SPDY ускоряет загрузку на 40%. Исследование протокола SPDY проводила и компания Opera. Но ни методик подсчета, ни примеров страниц, на которых были достигнуты столь впечатляющие результаты, в этих исследованиях не было.

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

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

• Использование CSS и переключение классов вместо перестроения DOM дерева
• Повсемнестное кеширование выборок элементов ($('div.active_part span.highlighter')), атомарные операции по изменению (вместо всеобщей перерисовки, вместо переделывания больших участков DOM дерева)
• Минимизации чтений DOM во время записи изменений состояний
• Кеширование размеров и расположения элементов (это спасает от излишнего вычисления при считывании этих значений при наличии других изменений: чтение во время изменения множества частей дерева крайне негативно сказывается на производительности)
• Аккуратное, не затягивающееся накопление изменений, необходимых произвести в DOM
• Прикрепление частей изменяющихся коллекций единовременно (когда, например, в середину списка вставляется 3 новых элемента; createDocumentFragment) в конкретное место (after, before) вместо открепления всей коллекции от DOM и повторного прикрепления (и вместо того, чтобы перерисовывать весь список)
• Прогрессивный асинхронный рендеринг: картина прорисовывается сразу с небольшим количеством деталей, затем деталей появляется всё больше
• Клонирование нодов (как часть шаблонизации)
• Кеширование и использование кеша результатов парсинга DOM шаблонов

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

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

Созданная страничка со всеми подключенными скриптами и стилями весит больше 5 Мб (около 200 файлов). Одно только сгенерированное DOM-дерево в коде HTML содержит более 500 000 байт. Работать с системой пользователь может начать не раньше, чем через 5 секунд после загрузки страницы (инициализация скриптов, ExtJS и т.п.).

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

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