Проверка HTML и время загрузки - PullRequest
1 голос
/ 15 января 2010

Влияет ли (около 100) ошибок проверки HTML на скорость загрузки моей страницы? В настоящее время ошибки на моих страницах не ломают страницу в ЛЮБОМ браузере, но я бы все равно потратил время и очистил бы их, если бы это улучшило скорость загрузки моей страницы?

Если не на настольных компьютерах, как на счет мобильных устройств, таких как iPhone или Android? (Например, N1 и Droid загружают страницы намного медленнее, чем iPhone, хотя они оба используют движок Webkit.)

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

Редактировать # 2 : я не нахожусь в режиме причуд, то есть я использую XHTML Strict Doctype, и мой исходный код выглядит великолепно и в основном он действителен, но для 100% допустимого HTML обычно требуется дизайн (или какой-либо другой вид) из) жертва.

Спасибо

Ответы [ 4 ]

4 голосов
/ 15 января 2010

Не влияет на скорость загрузки. Плохие данные передаются по проводам так же быстро, как и хорошие данные. Это влияет на скорость рендеринга, хотя (... в некоторых случаях ... ... положительно! Да, MSIE имеет тенденцию быть ужасно медленным в стандартном режиме) В большинстве случаев скорость рендеринга будет несколько медленнее из-за режима Quirks, который менее эффективный, более параноидальный и, как правило, вместо того, чтобы просто выполнять ваши данные, как хорошо написанную программу, он изо всех сил старается извлечь какой-то значимый контент из того, что по сути является супом тегов.

Некоторые ошибки проверки, такие как отсутствие ALT или отсутствие / в конце одноэлементных тегов, вообще не влияют на визуализацию, но некоторые, например, отсутствие закрывающего тега или использование устаревших устаревших параметров, могут серьезно повлиять на производительность.

1 голос
/ 15 января 2010

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

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

Я не думаю, что разница во времени между ошибками и 100 ошибками будет минимальной. Но если у вас так много ошибок, вы должны исправить свой код:)

0 голосов
/ 15 января 2010

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

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

Если вы просто используете неофициальные атрибуты (например, атрибут target в ссылках), то поддержка этого либо встроена в браузерили нет.Если браузер это понимает, он что-то с ним сделает, иначе он проигнорирует атрибут.

Одна вещь, которая увеличит ваши ошибки проверки, - это использование <br> в XHTML или <br /> в HTML.Также не следует увеличивать время загрузки (хотя <br /> занимает немного больше времени для загрузки).

0 голосов
/ 15 января 2010

Наверное, да, и вот почему.

Если ваш код действителен для используемого вами типа документа W3C, браузеру не нужно прилагать больше усилий, чтобы попытаться исправить ваш код. Это называется режимом причуд , и было бы логично, чтобы в случае проверки кода браузеру не пришлось бы пытаться собрать сайт обратно.

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

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