Является ли HTML слишком много текста для быстрой сети?

Question

Кто-нибудь знает что-нибудь об эффективности HTML как передаваемого языка разметки? Мне кажется, что закрытие тегов, а не просто закрывающая фигурная скобка (или просто </>) добавляет много текста в файл. Полоса пропускания является ценным ресурсом, и когда миллиарды (триллионы?) Файлов HTML постоянно передаются по всему миру, те закрывающие теги складываются.

Вопрос в том, достаточно ли они составляют достаточно, чтобы иметь серьезные последствия. С более кратким закрывающим тегом будет заметное увеличение скорости загрузки страниц?

Answer 1

Ваша точка действительна, но по сравнению с такими мультимедийными материалами, как аудио, видео и изображения, «потерянное пространство» незначительно.

HTML, являющийся языком разметки, является подробным; но если вы уберете часть этой многословия, с ней будет работать гораздо труднее.

Answer 2

No.

Если вы хотите скачать меньшие размеры, настроить веб-сервер автоматически gzip -compress все text/html ответов.

Answer 3

№ Относительно изображений (и видео!) HTML по-прежнему крошечный. Бросьте при сжатии, и она становится более, (особенно повторяющиеся строки (например, имена тегов) сжимаются.

Увеличение затрат на техническое обслуживание будет более чем компенсировать экономию полосы пропускания.

Answer 4

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

Если вы действительно обеспокоены этим, вы всегда можете настроить свой веб-сервер для применения сжатие до содержимого html при его обслуживании.

Answer 5

В гене al, разметка HTML не является ограничивающим фактором в отношении полосы пропускания. Две основные причины:

1. HTML - текст, что означает, что он сильно сжимается с использованием HTTP compression.
2. Полоса пропускания, используемая HTML, чрезвычайно мала по сравнению с пропускной способностью, используемой графикой/видео.

Answer 6

HTML не эффективен, и каждый признак указывает на то, что он станет менее эффективным.

Взгляните на следующий пример:

<b>some bold text</b> 

против

<span class="boldText">some bold text</span> 
.boldText {font-weight:bold;} 

Ok - его небольшой пример, но он иллюстрирует мою точку зрения.

Назад в дни модемов 56k, я использовал для написания функций Javascript на стороне клиента, а затем использовал Ajax (до того, как он был вызван ajax), чтобы передать только значения (а не описание), а затем использовать клиентскую сторону для создавая элементы в DOM, это оказалось на 20% более эффективным, но оставило меня в голове, если кто-нибудь придумает HTML-стенографию. Никто не делал, и вместо этого мы только что обновили наши соединения, и вы правы - мы бросаем кучу бит, которые не обязательно должны быть там.

Но кому это нужно?

Answer 7

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

http://code.google.com/speed/articles/optimizing-html.html