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

Очередная глава остросюжетного триллера об оптимизации сервисов Яндекса

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

В прошлый раз мы обсуждали принудительный выбор вашей локации и соответствующий ей доступ к сервисам компании. Например, если вы определяете свое местоположение в Минске, Беларусь, то Яндекс.Маркет России вы не увидите и прицениться к товарам соседей, до которых 3-4 часа езды из столицы (для джигитов и людей, которые себя не любят, два), вы не сможете.

На этот раз Яндекс принял решение устроить этнические чистки в рядах поисковой выдачи своего сервиса Яндекс.Блоги. Все мы помним, что если что-то однажды попало в интернет, то оно остается там навсегда и это, вроде как, можно будет найти при помощи соответствующих сервисов. Но Яндекс на эту тему имеет, почему-то, иное мнение. Поисковая выдача по Яндекс.Блогам была нещадно вычищена и теперь найти можно только записи не старше двух месяцев. Все остальное — в печь мусорное ведро, по всей видимости. Теперь «вон-тот-прикольный-пост-в-ЖЖ-я-помню-пару-слов» придется искать в общей выдаче.

C апреля 2015 года Google ввёл новый алгоритм ранжирования поисковой выдачи на мобильных устройствах, который в США уже окрестили «мобайлгеддоном». Теперь ресурсы, не имеющие мобильной версии сайта, будут иметь более низкие позиции. При этом поисковик описал требования к мобильным сайтам и даже предложил инструменты для оценки качества и выявления ошибок. Такая политика IT-гиганта неслучайна: мобильные девайсы покорили мир и не сдают позиции.

Согласно исследованию, опубликованному весной 2015 года компанией Яндекс, в конце 2014 года 68% пользователей интернета в российских городах хотя бы раз в месяц выходили в сеть с помощью мобильных устройств (годом ранее – 56%). Мобильные пользователи стали значительной частью аудитории сайтов. За 2014 год доля визитов на сайты со смартфонов и планшетов выросла в полтора раза. Причём со смартфонов в конце 2014 года россияне совершали почти в два раза больше визитов, чем с планшетов, и рост активности также вырос. Если обратиться к мировым трендам, то доля владельцев смартфонов среди пользователей Интернета составляет 80% и рост продолжается.



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

В стремлении к быстрому сайту многие разработчики упускают один важный момент: клиентскую (фронтендную) точку отказа (frontend SPOF – single point of failure). Причем, почти все инструменты тестирования скорости загрузки сайта также не выявят потенциальных проблем.

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

Самая популярная категория мобильных приложений – игры. В былые времена возможности процессоров и графических ускорителей портативных устройств были весьма ограничены, что сказывалось на их производительности. В итоге большинство игр приходилось делать достаточно простыми. Сегодня вычислительные мощности смартфонов и планшетов значительно выросли, а значит, появилась возможность создавать высококачественные, ресурсоёмкие игры. Однако мобильные CPU и GPU всё еще уступают тем, которые устанавливают в персональные компьютеры.

Рост рынка мобильных приложений привёл к тому, что многие производители игр для PC теперь создают игры для мобильных платформ. Однако традиционные подходы к проектированию игр не очень хорошо работают в мобильной среде. То же самое касается и графических ресурсов PC-игр, которые слишком «тяжелы» для мобильного аппаратного обеспечения.



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

Думаю, что у каждого пользователя Android рано или поздно возникает необходимость понять, какое приложение за ночь съело всю батарею притом, что телефон лежал с погашенным экраном. Участь найденного виновника не завидна: чаще всего его просто удаляют. Итак, что же сделать, чтобы наши приложения использовали аккумулятор минимально? В статье я постараюсь дать ответ на этот вопрос и рассказать о подходах к уменьшению потребления аккумулятора, которые мне доводилось использовать.

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

Несколько слов об исходной задаче. Основная сущность у нас — профиль ICQ, у которого есть список контактов, а у тех есть сообщения. Наше приложение существует уже много лет, разрабатывалось разными людьми с разными подходами, номер версии основной БД уверенно приближался к 30. Кроме того, количество фич в продукте невозможно предсказать заранее, это тоже повлияло на архитектуру. В общем, модель данных изначально была примерно такой:

В среде веб-разработчиков все больше распространяется знание о том, что скорость важна. Многие стараются ускориться: используют сжатие gzip, минификацию, кеширующие заголовки, сокращение запросов, оптимизацию картинок и другие.

После выполнения этих рекомендаций возникает вопрос: а что именно мы оптимизируем? Оказывается, что в большинстве случаев это время полной загрузки страницы со всеми элементами. Однако, это не совсем то, что нужно. На самом деле важно время, за которое пользователь получает «первый экран» страницы с важными функциональными элементами (заголовок, текст, описание товара и т.д.) Другими словами, важен момент начала рендеринга страницы. Здесь и возникает критический путь рендеринга, который определяет все действия, которые должен выполнить браузер для начала отрисовки страницы. С этой штукой мы и будем разбираться в статье.

От переводчика: в двух словах, в декабре 2015 выйдет релиз Python 2.7.11, ускоряющий работу интерпретатора CPython до 20%. Ниже перевод статьи с LWN.net, рассказывающей о сути и процессе произошедших изменений в коде. Имена, в произношении которых я не уверен, даны в оригинальном написании. Об ошибках и неточностях перевода просьба, как обычно, сообщать в личные сообщения.

Несмотря на то, что разработка Python 2 (а конкретно ветки Python 2.7.x) находится сейчас в состоянии «никаких новых фич», которое в обычной ситуации заранее ставит крест на любых крупных изменениях, команда разработки приняла решение рассмотреть и принять backport-патч из Python 3, привносящий заметное улучшение производительности интерпретатора.

Всем доброго времени суток.

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

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

Я надеялся, что это было временно. Я надеялся, что 2015 год будет годом производительности. Я ошибался. Средний вес веб-страницы возрос на 7.5% за пять месяцев, превысив 2Mb. Для этого же потребуется три 3.5-дюймовые дискеты двойной плотности!

Согласно отчёту на HTTP Archive за 15 мая 2015, статистика, собранная на почти половине миллиона веб-страниц, такова:

Привет, Хабрахабр! За один только прошлый год мы зарегистрировали 50 миллиардов установок приложений из Google Play, и мы не намерены на этом останавливаться: за это надо сказать спасибо вам, разработчикам, создающим отличные продукты.

В феврале мы объявили, что выплатили авторам приложений более семи миллиардов долларов и расширили свой рынок за счёт таких регионов, как Индия, Южная Азия и Средний Восток, так что теперь разработчики приложений Android могут найти своих клиентов в 190 странах мира.

Мы уже рассказывали про нововведения в Android М, сегодня же поговорим о других новинках, которые мы представили на конференции Google I/O, а точнее — а новых инструментах, которые помогут вам развивать бизнес: точнее прогнозировать последствия решений, основываясь на более точных данных и эффективнее привлекать пользователей интересным контентом.

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

На днях состоялся первый релиз набора инструментов для упаковки различных веб-ресурсов в один файл — Web Bundle. Принцип его работы точно такой же, как для ресурсов, включаемых в EXE файлы — произвольные файлы упаковываются в один файл-контейнер, а на клиентской стороне доступ к ним организуется по имени файла с помощью API. Только в данном случае в качестве контейнера используется изображение в формате PNG. Клиентская часть представляет из себя небольшую JS-библиотечку, позволяющую загружать, декодировать и извлекать отдельные файлы из таких ресурсов.

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

3D-системы используются для визуализации инженерных решений (типа обучения операторов АЭС, мониторинга там же), в нефтегазовой геологоразведке (туда идут самые дорогие иммерсионные системы), для демонстрации различных товаров (от кастомных дизайнов салонов автомобилей до типа укладки товара в грузовиках), для обучения ремонтников (можно разобрать двигатель Боинга), в медицине для обучения, а также для отработки эвакуаций и ЧС на разных ответственных объектах.

Главная проблема подготовки контента — это то, что на рынке много компаний, которые говорят «Мы умеем это делать», но не имеют своего железа по факту. Без двухнедельного тестирования, без чёткого понимания ограничений железа и просто знания особенных грабель — это не «умеем и можем», а «хотим, но не получится».

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

Здравствуйте! Меня зовут Елена Толмачева. В компании «ДоксВижн» я занимаюсь разработкой пользовательской документации.

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

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

К примеру, мне потребовалось решить эту задачу при реализации JavaScript API к Comet сервису. Эта задача встречается достаточно часто и её уже рассматривали на хабре раньше здесь и здесь, но я решил написать своё решение задачи исходя из следующих требований к коду:

• Кросбраузерность
• Отсутствие зависимостей
• Минимальный размер кода
• Простота и удобство

На изображении выше многие увидят известную картину. Так выглядит большинство CSS файлов на продакшене. Мы все стараемся, чтобы наши веб-страницы загружались быстро; для достижения этой цели используем различные инструменты и техники оптимизации загрузки и рендеринга страниц. Об одном, но редко используемом методе, я бы хотел поговорить и рассказать, как мне удалось сократить размер CSS файла почты mail.ru на 180Кб.