По описанию он грузится динамически и вся дискуссия хранится где-то там за прелеами сайта.
Т.е. поисковики его не индексируют. И тогда непонятно какой смысл в борьбе со внешними ссылками?
Если я не ошибаюсь, и сильно раздражает можно просто переопределить стили и сделать внешние ссылки display:none.
Или все же ошибаюсь?
Дико извиняюсь, разве Disqus в статике работает?
Уместно только для использования на чужих сайтах.
Способ 1. write как правило используется для вставки счетчиков и баннеров в системах, в которых код написан десять лет назад и рассчитан на веб-мастеров, которым очень сложно сделать по-человечески. Для динамического создания чего-то не приспособлен. Выполняется только в момент рендеринга страницы.
Способ 2. innerHTML был введен в ie5. Много лет его никто кроме IE не поддерживал, его использование считалось дурным тоном, и упреков в сторону IE за то что отступает от стандарта. Потом обнаружилось что способ очень удобны и его стал поддерживать FireFox, затем все остальные. Недостаток - если код создан чрез innerHTML, по крайней мере в старых броузерах он может быть недоступен для дальнейших манипуляций с DOM. Т.е. с третьим и наиболее распространеным методом. Метод обычно используется когда нужно вставить большой кусок кода и забыть про него. Скорость при этом выше чем у способа 3.
Способ 3. Стандартный и универсальный. Но сейчас как правило пользуются не голым JS, а различными js-фреймворками, которые решают большинство проблем с кросброузерностью. ПО крайней мере в каждом третьем ответе вам упоминается jquery. Я к ним присоединюсь.
Судя по всему у вас будет бесконечное количество таких классов.
Как именно их объединять не зная задачи сказать нельзя
У вас два запроса в одном.
Серверная оптимизация - это одно. Клиентская - другое.
По серверной части ищите где можно кэшировать. Причем все, начиная от страницы целиком, до мелких блоков. Т.е. вы можете сжать карточки товаров и не не тратить время на лишние запросы к БД для детализации различных карточек представленных на одной странице. Есть такой механизм в ваших cms или нет не знаю.
По клиентсткой у вас, извините ,жопа. Из того что на поверхности:
1) Сжимайте JS и CSS для этого есть куча инструментария. Причем JS нужно сжимать каким-нибудь инструментом типа http://closure-compiler.appspot.com/home, независимо от того будете или не будете использовать серверное сжатие. Про серверное сжатие не скажу. Не знаю. С одной стороны снизит нагрузку за счет меньшего кэша, с другой увеличит нагрузку за счет включения механизма. Но м.б. стоит попробовать и оценить.
2) Просмотрите внимательно все ли скрипты вам нужны одновременно. Пример:
На главной странице http://sunnyvilla.ru/ я не вижу чего-то такого, для чего необходимо грузить 108К скриптов на 14 загрузок. Может я что-то пропустил? Даже если я это пропустил, то 14 загрузок - это очень круто. Должна быть одна или две. Одна общая для всех и одна для каких-то специфических функций конкретной страницы.
А вот здесь http://toprepetitor.ru/ - вы отдаете юзеру несжатый tiny_mce_src.js весом 300К на всех страницах, это в несколько раз больше веса контента на странице вместе со стилями. Подозреваю что это ошметок от бэкофиса CMS. Если я ошибаюсь и кому-то пришло в голову позволить юзерам пользоваться визивигом, оторвите эту голову. Если нет возможности оторвать голову, сделайте ее загружаемой динамически - по запросу. Когда понадобится, тогда и грузите. А пока не понадобилась никому не показываете.
В любом случае эта гадость здорово тормозит загрузку контента вашей страницы.
3) Тоже что написано выше относится и к CSS. 3-5 несжатых файлов нужно слить в один-два и сжать.
4) там выше уже написали. Все скрипты которые не влияют на дизайн (таких вообе-то не должно быть) должны быть перенесены в самый конец HTML, чтобы сначала грузился контент, а затем все прочее. В принципе то же самое можно сделать и с картинками - грузить их после того как будет загружен текст и разметка.
Делать ли то же самое со счетчикам - открытый вопрос. Я их всегда ставлю в конец. Это снижает статистику, но зато не мешает загрузке.
5) Посмотрите http://webo.in/ там был сервис, который давал подробные рекомендации по оптимизации с объяснением какой выирыш это дает. И кроме того там есть подбор литературы.
А оно интересно? О том что HTML5 не дает никаких преимущество много и давно пишет Google. Я как-то совершенно не сомневаюсь что Яндекс зачешется раньше Google и по этой части.
Задача поставлена неверно. У вас в первой строке все ячейки заполнены. Так будет работать без проверки первой строки с th
var i,empty=[]; var tr =$('table tr'); for (i=1;i<tr.length;i++){ $(tr).children().each(function(j){ empty[j]=empty[j] || $(this).html().length; }); } for (i=0;i<tr.length;i++){ $(tr).children().each(function(j){ if (!empty[j]) $(this).remove(); }); }
var empty=[]; var tr =$('table tr'); tr.each(function(i){ $(this).children().each(function(j){ empty[j]=empty[j] || $(this).html().length; }) }); tr.each(function(i){ $(this).children().each(function(j){ if (!empty[j]) $(this).remove(); }) });
А где вы видите xHTML?
Потому что стандарт HTML не регулирует как именно должны по дефолту отображаться те или иные теги. Поэтому каждый производитель броузеров делает их на свой вкус. Для кастомизации и приведению к единообразию существует стандарт CSS, который позволяет задать большинству элементов HTML внешний вид, который необходим. Исключением являются элементы форм типа select, radio.
Для того чтобы все отображалось почти одинаково в 2007 году Эрик Меер предолжил набор CSS-правил (reset.css) который обнуляет все дефолтные установки броузеров и устанавливает общие правило. Этот прием (сброс дефолтных установок) используют в работе практически все верстальщики. В том или ином виде reset.css входит в состав всех css-фреймоворков.
