Станислав Тельнов Дебютант

Каким должен быть код интернет-страниц? Читабельность vs размер. Часть 1. HTML

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

Никогда не получится сделать всё так, как хочется… Это, конечно, немного несправедливо, но это факт — идеальных сайтов не бывает, да и никогда не будет! Постоянно приходится выбирать: оригинальность навигации и дизайна или юзабилити, оптимизированный или интересный читателю контент, небольшие и легкие скрипты или безопасность, устойчивость сайта к взлому. И ведь это далеко не все — этот список можно продолжать до бесконечности!

Вот именно об одной такой дилемме и хочу сегодня порассуждать. Думаю, что многие сайтостроители при разработке своих творений сталкивались с такой вот проблемой: что же предпочесть? Что будет лучше для сайта, посетителей и самого разработчика? Читабельный и лёгкий в понимании код или же небольшой размер страниц и, следовательно, и более высокая скорость загрузки?
Вообще это вопрос вечный! Почему? А потому что всегда придётся чем-то пожертвовать!

Многие, к сожалению, делают однозначный выбор в пользу скорости загрузки и пишут код чуть ли не в одну строчку. Поначалу я тоже так делал, но со временем мой код стал более читабельным. В чисто html страницах можно довольно быстро разобраться с кодом, т.к. легче понять, что куда, нет никаких переменных, циклов и т. д. И можно пожертвовать читабельностью, писать на одной сточке тег table, tr и td… И кажется, что всё понятно: вот таблица, вот строка, вот столбец. Однако задача сильно усложняется при сильно нагруженном коде и вложенных таблицах (причём неоднократно вложенных), да при этом ещё в одной таблице такой CSS стиль, в соседней другой CSS стиль, а если при этом части страницы находятся в разных файлах (те, кто программирует на php, думаю, поймут, как и зачем располагать половину html кода страницы в одном файле, а половину в другом). И вот тут вы уже навряд ли быстро разберётесь даже в своём собственном коде. Поясню на личном примере.

На моем сайте был такой глюк: в Опере и IE всё нормально, а в Мозилле почему-то страницы «прыгали». В частности, правый столбец вытягивался сильно в высоту, а центральный и левый из-за этого находились где-то в середине.
Я почти два дня искал ошибку! Так и не нашёл! Это осложнялось как раз тем, что html код был довольно большим и нагруженным. Потом я плюнул и решил сделать прежде всего-навсего код читабельным, т.к. в своё время много его изменял, добавлял вложенные таблицы, убирал одни, добавлял третьи, переносил из одного места в другое четвёртые и т. п. А потом потратить минут 20−30, чтобы сделать код читабельным, добавлять лишние пробелы и перевод на новую строку, где это нужно — мне было неохота.

И вот я просто сделал код читабельным! Размер страниц при этом у меня увеличился аж почти на 21 килобайт. При том, что уже почти 75 она весила до этого.
И в результате всего за полчаса нашёл ошибку! Просто в одном месте у меня высота была указана в процентах, а именно в этом месте нужно было в пикселях. Перепутал, думал, что этот tr принадлежит к одной таблице, а оказалось, к другой! Как видите, ошибка была элементарной и её было тяжело найти только лишь из-за нечитабельного кода!
Да, я понимаю, что код постоянно изменяется, что-то дополняется, что-то убирается, но не ленитесь при этом делать код читабельным! Каждый раз, после каждой модификации.

Т.к. мы говорили только про html код — то это были ещё цветочки, а про ягодки смотрите вторую часть.

Обновлено 2.10.2007
Статья размещена на сайте 3.09.2007

Комментарии (31):

Чтобы оставить комментарий зарегистрируйтесь или войдите на сайт

Войти через социальные сети:

  • 5!
    Мне интересно всё на эту тему - сайтостроение.
    Поэтому - спасибо!
    И буду все статьи подобные скачивать и внимательно изучать. И комментарии к ним тоже.

    Оценка статьи: 5

  • Я всегда выбираю читабельность.
    1. Все стоны по поводу больших файлов HTML решаются элементарно: либо хостинг должен поддерживать GZIP (это сжатие страниц перед передачей получателю в браузер, которых их разожмет перед показом), либо воспользуйтесь специальным сервисом для этого.
    Поскольку форматирование - это табуляции или пробелы, то сжимается это очень здорово.
    2. По поводу PHP вообще зря упомянули, т.к. этот скрипт вообще отрабатывает на веб-сервере, а клиенту летит результат. Поэтому то, как отформатирован скрипт на PHP, вообще никого не волнует.

    • Насчёт второго вашего замечания - не могу полностью согласится... Ведь php код исполняется сервером. И если на сервере этот код будет исполняться 5 секунд, то и данные в браузер начнут поступать только через 5 секунд, независимо от качества соединения. А если php код исполняется за 0.1 секунды, то через это же время и данные начнут поступать. Конечно скрипты исполняющиеся 5 секунд это невообразимая редкость, но всё же при больших и длинных скриптах разница может быть довольно существенной. Да, я соглашусь, что в php коде форматирование играет гораздо меньшую роль и довольно слабо влияет на скорость обработки сервером.

      А вообще, про php код я упомянул главным образом для начинающих веб-программистов, которые пишут скрипты «а лишь бы как», а потом сидят ночами и разгребают, чего же это они там понаписали…

  • Ворчания, ворчания.

    За всю мою 20-ю карьеру программиста разработка сайта вызвала второй раз в жизни чувство глубокого неудовлетворения, как-будто меня обманули (первый - когда связался с разработкой баз и оказалось, что для разных СУБД должны быть разные по синтаксису SQL запросы одной версии - что противоречит декларациям о назначении SQL).

    По поводу сайтостроительства - я молчу о несовместимости существующих браузеров (это диверсия - разрабатывать несовместимые браузеры и т.Сталин в 32 году поставил бы их к станке как саботажников). Про требуемые ресурсы - тоже ( оптимизация там и рядом не валялась). На этом фоне - экономить что-то на форматировании- просто смешно. И показательно - что действительно в канал можно гнать неформатированную (сжатую, прекомпилированную...) инфу - до этого просто не додумались. Просто стоит вспомнить - кто разработал концепцию HTML (не IT-шник) и для каких целей. К счастью развитие техники и технологий в большинстве перекрывает требования по ресурсам.

    В общем - экстенсивный путь развития, господа.

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

      И показательно - что действительно в канал можно гнать неформатированную (сжатую, прекомпилированную...) инфу - до этого просто не додумались.
      что Вы подразумеваете под фразой: "до этого просто не додумались", уточните, пожалуйста

  • ещё советую почитать про рефакторинг.. например, в книге у Фаулера (на рсдн-е есть описание его книги) или на его официальной странице, посвящённой этому вопросу (но на "буржуйском" языке)

  • Читабельность кода хороша только разработчику. Дома можно делать его читабельным, а в инет выкладывать 1ой строчкой. Ведь довольно много идей можно попросту украсть с сайта, при этом особо не вникая.
    Что касается простого пользователя ему до фени код. Большинство и не догадывается, что его вообще можно посмотреть.

    А еще лучше будет делать несколько версий, у каждой будут свои особенности.

    Насчет разных браузеров. Каждый поддерживает как хочет разметку. Есть стандарты, но они порой поразному интерпретируются. Именно поэтому зачастую внизу можно увидеть: оптимизировано под ***

    • А еще лучше будет делать несколько версий, у каждой будут свои особенности.
      согласен, про это я упоминал выше

      Ведь довольно много идей можно попросту украсть с сайта, при этом особо не вникая.
      вспоминается один разработчик Andy Dufilie.. был скрипт (под mIRC) игры танчики, в оригинале выглядел так (я привожу очень маленькую часть, просто для примера):
      alias -l tanks.alias.mkey {
      if ($mouse.key & 2) || ($mouse.key & 4) && ($istok(tanks.button.up tanks.button.down tanks.button.left tanks.button.right,$1,32)) return $1 $iif(%tanksinc == 1,5,1)
      return $1 %tanksinc
      }

      но автор закодировал часть исходного скрипта в такой вид:
      alias -l O00OOO00 {
      if ($mouse.key & 2) || ($mouse.key & 4) && ($istok(O000000O O0000OOO O000O00O O000O0O0,$1,32)) return $1 $iif(%tanksinc == 1,5,1)
      return $1 %tanksinc
      }

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

      • Чтобы это работало, необходимо чтобы программы-обработчики понимали что они делают. Таким образом ничего зашифровать практически нельзя, либо можно расшифровать. Есть великая вещь: дизасемблер

        • необходимо чтобы программы-обработчики понимали что они делают
          естественно, Вы думаете, хороший разработчик будет натравливать на свой код "левый" транслятор? если не найдёт подходящего, то свой напишет, в большинстве случаев, это не настолько то и сложно, главное синтаксис языка/языков с которого на который транслировать будут знать

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

          Есть великая вещь: дизасемблер
          а причём тут он?
          речь идёт о скриптах, которые выложены публично в открытом виде, как есть, они не компилируются в исполняемые файлы (которые кое как можно дизасемлировать) и чтобы запутать чтение таких публично выложенных файлов иногда применяются трансляторы, запутывающие код.. либо трансляторы, которые омгут соптимизировать код скрипта. уменьшив его объём, в ущерб читабельности

  • Честно говоря, мне как посетителю, на читаемость кода до лампочки. А вот то, что время загрузки увеличилось чуть ли не в полтора раза - вот это существенно. Так что, уважаемые сайтописатели, лучше думайте об удобстве пользователя, а не о собственном.
    Путь к удобству сайтописателя лежит через применение программных средств, которые, оставляя исходный текст нетронутым, создают "легкую" рабочую версию.

    Оценка статьи: 4

    • Да согласен что для посетителя в первую очередь - это быстрота загрузки и пользователю до фени на код. Но вот сколько я лично видел внутренних кодов сайтов, 95% из них имеют нечитабельный и далеко не самый практичный код. Взять даже например страницу моего акка на ШЖ https://shkolazhizni.ru/authors/antiKILLER/.
      Код очень читабельный. Всё без труда понятно где находится и за что отвечает...но 1568 строк конечного кода (причём последняя строчка пустая) - это слишком. Просто я не разу не видел чтобы кто-то пользовался такими програмками, да и очень многие выбирают что либо одно.

    • Путь к удобству сайтописателя лежит через применение программных средств, которые, оставляя исходный текст нетронутым, создают "легкую" рабочую версию.
      правильно
      если в курсе, может оставите для справки в комментариях ссылки на подобные утилитки (которые позволяют "скормить" файл удобночитаемый и получить трудночитаемый меньшего размера)?

  • с одной стороны подмечено правильно.. код должен быть удобночитаемым, а то затраты на исправление недочётов и расширение функциональности будут велики..
    но! кто мешает писать полностью отформатированный, удобночитаемый текст, сохранить его, далее прогнать этот текст через специальную программу (я сайтостроительством не занимаюсь, потому не могу посоветовать конкретных приложений, но уверен на 99%, что такие программы уже есть) и получить трудночитаемый текст, но занимающий меньший объём? в итоге будет две версии исходного кода: debug и release (из аналогии с программированием на компилируемых языках).. debug - версия до сжатия, пользуетесь ей, до тех пор пока не получили стабильную версию, как только версия стабильная етсь, можно делать release версию и использовать её.. "и волки сыты, и овцы целы" ©

  • Мдяяяяя... Конечно же читабельность важнее. Краткость - сестра таланта.

    PS: а твой вмзар это пирамида, это ж кидалово всегда)))

    • Илья, по поводу З.Ы.:
      И почему же опять кидалово... Ну назовите мне обьективную причину почему мне выгодно обманывать пользователей.
      Да, к сожалению сейчас довольно много мошенников, но у меня всё честно. Иначе обматые давно бы пожаловались в Арбиртраж вебмоней и как минимум мой сайт прикрыли бы.

  • Это будет интересно массовому читателю?

  • Нужно взять на заметку.

  • Я тоже люблю читабельный код - с ним легче работать.

    Оценка статьи: 5