Предисловие

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

1. Память
2. Оптимизация операций
3. Выделение критических участков
4. Циклы и объектные свойства
5. Немножко о DOM
6. DocumentFragment как промежуточный буфер
7. О преобразованиях в объекты
8. Разбитие кода
9. События перетаскивания
10. Другие советы

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

Память

Хоть это и не должно волновать клиентского программиста, но не забываем, что память всё-таки не бесконечна и когда-нибудь может закончиться, например, когда запущено несколько массивных программ: офис, графический редактор, компиляция большой программы и др. Несмотря на то, что приведенный пример тривиален, у меня действительно такое случилось, хоть и не из-за браузера, но он тоже сыграл свою роль: 1,3 Гб оперативы (отладчик, около 30 вкладок), начались тормоза по перегрузке страниц ОП в файл подкачки.
Чтобы уменьшить расход памяти, я предлагаю несколько способов:

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

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

Здравствуй Хабр!



После нескольких месяцев работы над исправлением ошибок и добавлением новых функции на суд общественности выношу новую версию Image Catalyst 2.1. В новой версии были сделаны ряд ключевых изменений.

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

Вместе с ростом мобильного интернета растёт и необходимость оптимизации скорости работы мобильных сайтов. Даже самые современные смартфоны на Android, iOS, WebOS, BlackBerry OS и др. обладают процессорами с частотой не более 1Ghz, а скорости 3G можно считать достаточно медленными (скорость загрузки в 3 раза меньше DSL).

Мобильные устройства унаследовали проблемы “больших” машин: от количества http-запросов до эффективности работы JavaScript.

Особенности мобильных устройств

Кроме того, что они часто помещаются в карман и их легче потерять, существует несколько ключевых отличий мобильных устройств по отношению к десктопам:

• маленькое разрешение экрана;
• медленные соединения;
• ограниченный размер кэша;
• много различных устройств и форм-факторов;
• низкая мощность процессоров;
• широкая поддержка HTML5;
• относительно новые браузеры (в этом мире не знают о IE6).

Введение

Предлагаю Вашему вниманию обзор посвященный оптимизации изображений формата PNG и JPEG без потери качества. Под «без потери качества» подразумевается, что визуально оригинальные и оптимизированные изображения ни чем не будут отличаться. Я читал на Хабре довольно много статьей посвященных данному вопросу, но скажу, большая часть — полная чушь, в них констатируются факты, а не причины. Данный обзор посвящен людям, которые имеют базовые знания об оптимизации изображений.

Храните мелкие картинки, которые нельзя засунуть в спрайты, в data:image base64 в CSS — это экономит кучу запросов к вебсерверу.

Да, инструменты для создания CSS спрайтов существуют. Я даже сделал один такой сервис. Но они время от времени ломаются (как сейчас, мой). Но и командная многого стоит, и imagemagick. Давайте посмотрим, как мы можем создавать CSS спрайты только из командной строки.

Создание картинки

Начнем с того, что у нас есть список отдельных файлов:

$ ls

1.png  2.gif  dot.png  phoney.gif  tw.gif

• — 1.png
• — 2.gif
• — dot.png
• — phoney.gif
• — tw.gif

Сделаем из них спрайт:

$ convert *png *gif -append result/result-sprite.png

Да, это все. Смотрим результат.

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

Пусть мы хотим написать свой хабрахабр с блекджеком и прочими прелестями. Страница статьи у нас стостоит из 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

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

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

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

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