Оптимизация JavaScript и jQuery из-под HTML и CSS при разработке сайта

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

Спасибо за статью, не знал про margin. На счет селекторов стоит изучить эту страничку.
На собственном опыте убедился, что $(document.getElementById('foo')) гораздо лучше чем $('#foo')
Так же просто спасительным для меня решением в проекте с CSS анимацией стала такая оптимизация:

-webkit-transform: translate3d(100px, 100px, 0px);
-webkit-transition: -webkit-transform 0.5s ease;

в таком случае включается аппаратное ускорение, это в разы лучше чем анимировать любыми способами атрибуты top и left. К тому же дивы можно еще и плавно уменьшать или поворачивать.

необходимо использовать либо margin, либо padding, либо left

Быстрее всего это делать трансформациями (CSS transform translate). В старых MSIE не работает, конечно.

Недавно наткнулись на одну особенность jQuery, он добавляет временный id при выборках. Это сделано для исправления багов при работе document.querySelectorAll. В нормальных браузерах, ничего плохо не происходит, но в Opera < 15 и Safari это приводит к нежелательным reflow, поэтому мы запилили свой jquery.fn.find. А так т.к. мы не используем каскад при выборке, он ещё и быстрей.

Все хорошо, но позволю себе вставить свое слово.

Вставка JS кода в head да, «блокирует» дальнейшую обработку файлов до полной загрузки скрипта. Это верное утверждение.
Но современные браузеры стали умнее (и коварнее). Они точно знают, что можно грузить данные в несколько потоков.
Это означает, что JS файлы будут грузиться синхронно с страницей\другими файлами. Поэтому такая критичность в размещении «вставок» является попросту лишней. А размещение js в одном месте — удобство и эстетика.

Чтобы предотвратить споры как лучше — ссылочка на веб-стандарты

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

Если уж разговор зашел об оптимизации кода, в том числе и с целью увеличения производительности, тот вот эта ссылка просто бесценна:

http://shichuan.github.io/javascript-patterns/

Многочисленные паттерны (и антипаттерны для сравнения) написания оптимальных конструкций с обоснованием.

Один из примеров:

// antipattern
// create and append your element
$(document.body).append("<div class='baaron' />");
// requery to bind stuff
$("div.baaron").click(function () {...});


// preferred
// swap to appendTo to hold your element
$("<div class='baaron' />")
    .appendTo(document.body)
    .click(function () {...});

В оптимизации кода на jWhatever все должно сводится к минимизации использования библиотеки.

Для выбора первых, последних или определённых элементов используйте .first(), .last(), .eq( index )

Недавно выяснил, что $('.class:first-child') работает заметно быстрей чем $('.class').first()

Когда создатель сайта помещает скрипты перед «</body>», то показывает элементы сайта быстрее, но зато дольше показывает их непроскриптованными.

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

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

> Inline JavaScript в HTML коде
> Во-первых, это некрасиво, неуклюже и со старта похоже на костыль.
Это не совсем так.
Если мы уж заговорили об оптимизации, то часто выгоднее иметь весь js код инлайном внутри страницы нежели ссылку, пусть даже на единственный агреггированный js файл. Пример — главная страница google где почти 80% кода страницы именно inline js.

>И наконец, эти скрипты не могут быть автоматически минифицированы и сжаты (gzip), что скажется на производительности продакшн сервера.
Этот тезис не очень понял. Отдаваемый html код, со всеми inline скриптами точно так же может быть сжат.

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

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