К какой категории вы себя относите? Вы уверены?

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

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

Предприниматели используют деньги (преимущественно не свои деньги), чтобы создать бизнес крупнее имеющегося. Предприниматели «зарабатывают», даже когда они спят. Предприниматели сосредоточены на росте и соразмерности систем, которые они создают. Чем больше, тем лучше.

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

Примечание: ниже перевод статьи Dean Edwards «Optimising Performance» с советами по написанию CSS-кода для Internet Explorer'а, который будет быстрее отрабатывать на клиенте. Мои комментарии далее курсивом.

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

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

читать дальше на webo.in →

Примечание: ниже перевод презентации «High Performance Ajax Applications», подготовленной ведущим специалистом из Yahoo (а теперь уже из Apple) Julien Lecomte. В ней автор освещает некоторые аспекты оптимизации как JavaScript-приложений, так и веб-сайтов вообще. В целом, советов много, и почти все, действительно, по делу. Однако, встречается и откровенная реклама Yahoo :) Мои комментарии далее курсивом.

Часть 1. Разработка для высокой производительности

Планируем и проектируем для высокой производительности

• Ориентируемся на производительность с самого первого дня
• Тесно работаем с дизайнерами и менеджерами продукта
• Понимаем рациональность дизайна
• Объясняем компромиссы между дизайном и производительностью
• Предлагаем альтернативы и показываем, что еще возможно (на уровне прототипа)
• Пробуем силы в реализации нетривиального дизайна (нельзя сразу говорит «нет»)
• Помогаем упростить дизайн и взаимодействие с пользователем (добиваемся компромисса)

читать дальше на webo.in →

После статьи «Разгоняем CSS-селекторы: стоит ли?» было предложено рассмотреть несколько дополнительных случаев, учитывающих транзитивность селекторов (например, насколько быстрее a c, чем a b c, или наоборот). Данное исследование посвящено как раз разбору таких случаев.

Методика

Методика и уменьшение погрешности подробно рассматривались в первой статье, на них сильно много останавливаться не буду. Скажу лишь, что при наращивании количества классов и идентификаторов Opera стала значительно медленнее (раза в 3) отображать код (при этом общий его объем увеличился примерно в 1,5-2 раза). Скорее всего, в следующую статью войдет исследование влияния количества классов/идентификаторов/размера кода на общую производительность браузера.

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

читать дальше на webo.in →

Примечание: ниже находится перевод статьи «Optimize Parallel Downloads to Minimize Object Overhead», в которой авторы рассматривают параллельную загрузку объектов, и как она влияет на производительность веб-страницы. Мои комментарии далее курсивом.

Средняя веб-страница содержит более, чем 50 объектов (Krishnamurthy и Wills 2006), при этом издержки на число объектов доминируют над всеми остальными задержками при загрузке большинства веб-страниц (Yuan 2005). Браузеры, следуя рекомендациям спецификации HTTP 1.1, обычно устанавливают не более 2 одновременных соединений (это справедливо только для IE6/7, для Firefox и Opera этот параметр настраиваемый, составляет не меньше 4, по умолчанию. Для IE8, по словам Алекса Могилевского, скорее всего, будет 6) с одним хостом. При увеличении числа HTTP запросов, требуемых для отображения страницы, с 3 до 23 время, затрачиваемое именно на «чистую» загрузку объектов, от общего времени загрузки падает с 50% до всего 14% (см. Рисунок 1).

читать дальше на webo.in →

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

Методика

Если в первых двух исследованиях ставилась под вопрос скорость распознавания браузером CSS-правил и их применение, то сейчас интересовал другой вопрос, а именно: как быстро браузер создает DOM-дерево в зависимости от наличия в нем элементов с id или class?

Для этого было подготовлено 3 набора HTML-файлов. Первый содержал 10000 элементов, у которых часть имеет id (количество именованных элементов варьировалось от 50 до 10000). Во втором HTML-файлы были, практически, идентичными, только вместо id имели атрибут class. В третьем наборе в DOM-дереве были только элементы с id (т.е. варьировалось само число элементов). Соответственно, все измерения проводились в скрытом iframe, чтобы избежать отрисовки загружаемой страницы на экране.

читать дальше на webo.in →

В очередной презентации Yahoo! о клиентской производительности был поднят вопрос о favicon.ico. Они проводили несколько интересных фактов о данном явлении и давали пару советов. Процитирую их рекомендации:

• www.example.org/favicon.ico
• Необходимое зло:
  • Браузер ее запросит
  • Лучше не отвечать 404-ошибкой
  • Будут отправлены cookie
  • Не может быть в CDN
  • Мешается в последовательности загрузки ресурсов
• Уменьшайте ее (<=1 Кб)
• Использовать анимированные иконки ни разу не хорошо
• Выставляйте заголовок Expires
• Инструменты: imagemagick, png2ico, favicon.ru
• Материал для изучения: в поиске Yahoo! favicon.ico занимает 9% всех просмотров страниц (для webo.in это 7%)

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

читать дальше на webo.in →

Несколько читателей блога webo.in просили меня выложить конфигурацию связки nginx + Apache, на которой работает сервер. Хотя это и не относится напрямую к теме клиентской оптимизации. Однако, большинству специалистов, занимающихся клиентской оптимизацией, будет интересно узнать о настройке нескольких хостов для выдачи статики и пара других трюков, связанных с балансировкой запросов.

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

читать дальше на webo.in →

Наткнулся на кучу интересных статей на webo.in и зачитался. Решил применить описанное там на реальном проекте. Вот что получилось. Проектик маленький — сайт моих друзей Bookcare. Они делают обложки для книг, а их сайт — мой «проект выходного дня».

Примечание: ниже расположен перевод заметки Image Optimization, Part 3: Four Steps to File Size Reduction от Stoyan Stefanov. В ней рассматриваются наиболее популярные консольные утилиты для минимизации изображений. Мои комментарии далее курсивом.
Об авторе: Stoyan Stefanov работает веб-разработчиком в команде Yahoo! по исключительной производительности и руководит разработкой инструмента для анализа производительности — YSlow. Он также внес значительный вклад в программы, разрабатываемые с открытым исходным кодом, выступает на конференциях и является техническим писателем: его последняя книга озаглавлена Объектно-ориентированный JavaScript.

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

• Оптимизация изображений, часть 1: важность картинок
• Оптимизация изображений, часть 2: выбираем нужный формат файлов

Текущая заметка посвящена некоторым наиболее часто используемым инструментам, которые можно применить для уменьшения размера изображений. Идея заключается в следующем: мы можем получать все изображения от дизайнера, но не оставлять их в исходном виде, а немного уменьшать в размере, используя указанные ниже инструменты. Это позволит автоматизировать процесс без необходимости глубокого анализа структуры изображения.
Читать дальше на webo.in →

Предыстория

Как известно, перед тем, как выложить сайт в нет, мы его разрабатываем. И делаем мы это, как ни странно, на машине разработчика. И давно замечено, что javascript, а в некоторых случаях и css удобнее при разработке держать в нескольких файлах.Проблема в том, что, согласно принципам, описанным в статье Best Practices for Speeding Up Your Web Site (перевод доступен на сайте webo.in), для ускорения загрузки сайта нам нужно произвести следующие манипуляции над javascript и css файлами:

1. Слить весь javascript в один файл, причем, желательно так, чтобы сохранился нужный порядок — т.е., скажем, библиотека jQuery — была ближе к началу, а функции и объекты, которые ее используют — после нее.
2. Слить весь css в один файл
3. Сжать эти большие файлы с помощью какой-нибудь утилиты вроде yui-compressor (за исключением css-файлов, название которых начинается, скажем, с префикса ie_, которые содержат data:URL, и поэтому критично относятся к переходам со строки на строку, так что их для собственного спокойствия лучше не сжимать)
4. Расположить их в таком порядке — css-файл как можно ближе к открывающему тэгу head, а js-файл — как можно ближе к закрывающему тэгу body.
5. Выставить HTTP-заголовок expires на подольше, чтобы браузер пользователя их закешировал. Ну а для того, чтобы при следующем билде у пользователя обновился js и css надо этим файлам дать какое-нибудь уникальное имя.
6. Перед отдачей файлов клиенту сжимать их с помощью gzip

К чему это я?

Пункты 5 и 6 уже подробно расписаны в других местах.
Я же хочу рассмотреть в этой статье вопрос автоматизации пунктов 1,2,3,4. А точнее, я хочу предложить инструмент, с помощью которого одним (ну, максимум — двумя-тремя :) нажатием кнопки можно выполнить пункты 1, 2, 3, 4 настоящего списка и получить готовые к заливке на сервер javascript и css файлы.

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

Сейчас многие сайты насыщены графикой в разных видах: аватары, иллюстрации к постам, галереи и тп.

Читатели блога «Клиентская оптимизация» как никто другой знают цену лишних запросов к серверу.

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

Пусть мы хотим написать свой хабрахабр с блекджеком и прочими прелестями. Страница статьи у нас стостоит из 3 объёмных блоков:
1. собственно текст статьи. меняется очень редко.
2. дерево комментариев. меняется относительно часто, но со временем всё реже и реже.
3. прямой эфир. небольшой, но меняется очень часто.

Допустим, что страница с этой статьёй доступна по адресу ?article:right.cache
Но внутрь неё мы не будем помещать никакого контента, а вынесем его в отдельные ресурсы, как это обычно делается со скриптами и стилями. Внутри ?article:right.cache будет лишь индекс подключаемых ресурсов с версиями.

?article:right.cache/content/version:123
?article:right.cache/comments/time:2010-12-01
?live/time:2010-12-01
?style:article/version:666
?script:article/version:333

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

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

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

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

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

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

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

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

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

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

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

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

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



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

Хабр уже насыщен статьями на тему «нового» формата изображений WebP (описание, сравнение с JPEG2000, сравнение с BPG, использование, подключение на сайте). К сожалению, открытыми остаются вопросы: как правильно подключить WebP на сайте, чтобы «все работало», и насколько он лучше (меньше) PNG/JPEG. В этой заметке я буду отвечать на оба вопроса.

Предполагаю, что вы уже в курсе оптимизации изображений, умеете конвертировать изображения в WebP, понимаете разницу между использованием JPEG и PNG на сайте, знаете инструменты ExifTool, jpegtran, mozjpeg, JPEGrescan, optipng, pngcrush, pngwolf, zopflipng и TruePNG, а также различаете пастеризацию молока и постеризацию изображений.

Если все так — то переходим к сути.

Как сделать сайт, который понравится пользователю? Какой он должен быть: красивый, с удобной навигацией, с запоминающимся URL? Прежде всего, сайт не должен тормозить — у пользователя должно складываться впечатление, что всё летает. Это первично. Всё остальное решается по мере разработки. О том, как воспринимают сайт пользователи, от чего это зависит и когда производительность решает, мы поговорили с Денисом Мишуновым, frontend-разработчиком (в прошлом контрибьютор в CMS Plone в составе Plone UI Team), автором статей про производительность в Smashing Magazine и активным спикером на профессиональных конференциях (среди которых From The Front, JSConf EU, JSConf Budapest, Smashing Conference, а теперь и HolyJS)



— Расскажи о себе. Какой был путь к web-разработке, почему именно она? Чем ты сейчас занимаешься?

— До того, что сейчас называют веб-разработкой, я дошёл быстро, уверенно и предсказуемо: первый компьютер, первый, никому не нужный, сайт, осознание бренности бытия. Дальше было чтение первых страниц «Программирование на Perl» Ларри Уилла и Тома Кристиансен с депрессивным верблюдом на обложке, повторное осознание бренности бытия и, как следствие, откладывание верблюдокниги. А потом я открыл для себя «Designing with Web Standards» Джеффри Зельдмана. Потом было, конечно же, «Ководство» Лебедева и много всего остального. Но книга Зельдмана была переломной. Хотелось бы сказать что-то красивое типа: «мир веба захватил меня после прочтения», но на самом деле я просто понял, что по сравнению с «конструктор электронных аппаратов» (которых из нас тщетно пытались сделать в институте), интернет-разработчик, а именно так это называлось в начале нулевых, звучит откровенно круче.