Практичный веб-дизайн - ускори свой сайт

Я думаю, мне всегда нравились простые вещи: функция над формой, производительность над эстетикой и тому подобное. Когда я был крошечным парнем, мы с отцом приняли участие в «Дерби из соснового леса» — соревновании, спонсируемом новичками-скаутами, чтобы выяснить, кто сможет вырубить самую быструю гоночную машину из соснового бруса размером с предплечье. В день гонки вы и ваши люди (как правило, включая одного очень конкурентоспособного отца, который сделал большую часть работы за вас) привезут ваше резное создание на место гонки. Вы бы поставили своего гонщика на верхнюю часть слайда рядом с множеством произведений других детей о гоночном искусстве, а когда свистнул, вы бы их отпустили. Они катятся, или скользят, или спотыкаются, по наклонной ипподрому, надеясь на победу, и в этот момент твой папа сует свой кулак в потные лица отцов неудачников, и ты будешь стараться не выглядеть смущенным.

Я рано решил, что мой гонщик будет простым, аэродинамичным и функциональным. Никаких спойлеров, дуддов или причудливых работ по покраске, чтобы мешать — всего несколько унций гладко вырезанного дерева, которое скользило бы как ветер. Итак, мы вырезали и вырезали («Дай мне этот нож, сынок, ты порежешь себя»), и мы подстригли и отшлифовали, пока у нас не появилась шелковисто-гладкая пуля в форме пули, которая гарантированно заставила остальных детей споткнуться. дом в слезах. Это было просто, ничто необычное, чтобы препятствовать его пути вниз по дорожке. Это, вероятно, победило бы, если бы мы не склеили колеса клеем так сильно, что они едва поворачивались. Мы не приехали последними, но это было потому, что гонщик другого участника упрямо сидел в стартовом парашюте и вообще отказывался сдвигаться.

… что подводит меня к теме сегодняшней колонки. Если бы Энди Кинг делал гоночные автомобили «Пайнвуд», он сделал бы их простыми, изящными, аэродинамическими и функциональными — и его колеса могли бы правильно вращаться. Вместо этого он делает сайты. Он также основал и пишет для Webreference и JavaScript.com , двух сайтов, которые любой веб-дизайнер, достойный его или ее внимания, должен регулярно посещать. Энди работает над методами оптимизации веб-сайтов вскоре после появления World Wide Web. Другими словами, он знает, о чем говорит.

Недавно Энди опубликовал книгу « Ускорьте свой сайт: Оптимизация веб-сайтов» ( New Riders Publishing , 2003), в которой на простом и понятном английском языке рассказывается, как сделать ваш сайт быстрее и быстрее. Мне посчастливилось попросить обзорную копию у New Riders, и после прочтения книги я понял, что должен поделиться с вами некоторыми идеями Энди. Мне вдвойне повезло получить помощь самого Энди; он дал мне разрешение поделиться некоторыми материалами своей книги с аудиторией SitePoint (естественно, в рамках ограничений авторского права) и даже ответил на несколько вопросов, которые я задавал ему о содержании и сфере применения книги. Вы не могли бы попросить больше сотрудничества.

Я даже не собираюсь пытаться подвести итог этой книги, и при этом я не собираюсь пытаться охватить все в ней. Большая часть работы Энди предназначена для более искушенного создателя веб-сайтов — то есть методов оптимизации DHTML, JavaScript и CSS-кода, оптимизации графики и мультимедийных презентаций, поисковой оптимизации и так далее. Эта колонка написана больше для любительского или непрофессионального веб-дизайнера, поэтому я буду придерживаться этого в своем обзоре. Но имейте в виду, что я освещаю менее эзотерические вещи. Книга Энди идет туда, где эта колонка не осмеливается идти!

Пока ваша копия не появится на вашем столе, вы можете взглянуть на дополнительный сайт WebSiteOptimization.com . Многие из методов, представленных в книге, объясняются и расширяются здесь.

Обзор и обоснование: скорость загрузки

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

Одна статистика, использованная для создания кейса, довольно неплохо суммирует: если ваша страница не загрузилась (по крайней мере, достаточно, чтобы ее использовать) за 8 секунд или меньше, средний посетитель выручит и уйдет в другое место. Это достаточно плохо для среднего «хобби» или личной страницы, или для некоммерческих сайтов. Но для коммерческого сайта это важная информация, которая должна определять философию дизайна всего сайта.

Вы никогда не задумывались, почему Yahoo! самый известный и наиболее используемый поисковый каталог / каталог в Интернете? Это не самый всеобъемлющий или даже самый простой в использовании (хотя, безусловно, удобный); однако он абсолютно надежен в отношении времени загрузки. Вы нажимаете на Yahoo! и появляется каждый раз, в обязательном порядке, обычно в течение 2-3 секунд. Энди подробно рассказывает о том, почему Yahoo загружается так быстро, но мы должны помнить, что он загружается быстро и надежно каждый раз. Наши сайты должны загружаться так быстро.

«Пользователи связывают медленно загружаемые страницы с некачественными продуктами и услугами, скомпрометированной безопасностью и низким уровнем доверия. Низкая удовлетворенность пользователей может привести к заброшенным веб-сайтам и корзинам». — Кинг, р. 25

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

Есть, конечно, исключения: «художественные» страницы, на которых много большой, сложной графики; страницы с большим количеством потокового аудио и других мультимедийных функций; страницы, демонстрирующие самые современные эффекты веб-дизайна; и сайты, которые не предназначены для общего пользования, например сайты «хранения», используемые для размещения .PDF, PowerPoint и других файлов. Но даже сайты с большим количеством графики могут загружаться быстро, если дизайнеру потребуется время и усилия, чтобы это произошло.

На двух из моих любимых графических сайтов, « Цифровое богохульство» Райана Блисса и мой бюджетный дизайн моего друга Робби, есть домашние страницы, которые загружаются (для меня) менее чем за 5–6 секунд. Оказавшись там, вы знаете, что нажатие на большую графику займет некоторое время, и это нормально. Вы попали туда без неоправданной задержки.

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

Это также хорошая идея, чтобы ваши страницы оставались неизменными во время загрузки. Если ваша домашняя страница загружается в течение нескольких секунд, то же самое следует делать и с остальными страницами, если только нет явной и основной причины, по которой они не должны этого делать. Загрузка вашей домашней страницы — это первый шаг к удержанию посетителя на вашей странице, но радость от быстрой загрузки домашней страницы быстро исчезнет, если каждая другая страница будет загружаться медленно. Не изменяйте свою домашнюю страницу и не позволяйте остальному контенту скользить; если вы собираетесь оптимизировать, делайте это по всему сайту.

«Ключевым атрибутом [для оптимизированного сайта с хорошим« потоком »] является то, что он должен быть вначале очень удобным для пользователя и прозрачным, но нужно сразу же найти в нем сложность, чтобы быстро найти нужный уровень возможности для «действий», которые соответствуют вашим навыкам. Эти «проблемы» включают визуальный аспект, а также содержание ». — Mihaly Csikszentmihalyi, цитируемый King, p. 34

Несколько элементов способствуют открытому, легкому «потоку» вашего сайта. Скорость загрузки — первый элемент, но не единственный. Простота навигации — ключ к хорошей работе вашего сайта; это включает в себя предоставление «указателей — таких как карты сайта, следы хлебных крошек и ориентиры« вы здесь »» (стр. 36), чтобы помочь вашим посетителям легко и интуитивно перемещаться по вашему сайту. Быстрая и четкая обратная связь — это еще одна важная составляющая хорошего потока сайта: четкие внутренние и внешние ссылки, навигационные инструменты и отображение переменных производительности, таких как индикаторы уровня прогресса, отображаемые размеры загружаемых файлов и т. Д.

Ваша страница должна быть оптимизирована для уровня навыков и знаний ваших пользователей: стоит предложить «адаптируемый / настраиваемый интерфейс, который дает пользователям контроль над сложностью среды, соответствующей уровню их навыков» (стр. 36). Простота компоновки и функций стоит больше, чем демонстрация ваших передовых навыков кодирования. Помните, что идея заключается в том, что ваш посетитель должен запустить ваш сайт, пролистать его как можно проще и приятнее и уйти с желанием скоро вернуться.

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

Засучить рукава: оптимизировать код

Вот где мы входим в ловкость оптимизации вашего сайта для максимальной эффективности. Энди дает много конкретной информации о настройке и сокращении вашего HTML; Я расскажу о некоторых основных моментах.

Минимизация HTTP-запросов

Я задал Энди следующий вопрос: «Какие методы вы бы порекомендовали любителям и / или некоммерческим веб-дизайнерам? Как насчет веб-дизайнеров, которые не очень много работают с CSS (либо по выбору, либо из-за отсутствия понимания того, как использовать это?) Он ответил: «Минимизируйте HTTP-запросы, уменьшив количество объектов на вашей странице, и объедините соседнюю графику. Это, вероятно, самый важный метод».

Каждый раз, когда вы включаете объект — графику, Java-апплет, внешнюю таблицу стилей, кусок JavaScript — страница должна «вызывать» сервер для доставки объекта. В идеале на вашей оптимизированной веб-странице должно быть как можно меньше обращений к серверу. По словам веб-гуру Якоба Нильсена, одного из самых влиятельных людей Энди, для завершения каждого «звонка» требуется от 0,5 до 2 секунд. Таким образом, вы должны учитывать каждый «звонок», который должна сделать ваша страница: это необходимо? Можете ли вы заставить свою страницу выполнять свою функцию без этого конкретного объекта?

Энди приводит нам реальный пример — прототип домашней страницы производителя веб-рекламы Elivad.com . На исходной домашней странице было семь графических изображений с ролловерами, всего 14 вызовов на сервер и 6 других вызовов для таблиц стилей, сценариев JavaScripts и самой страницы. Страница заняла около 15 секунд, чтобы загрузить на 56k.

После оптимизации — преобразования изображений и JavaScript-ролловеров в текст с использованием CSS-ролловеров, преобразования кнопок в текстовые ссылки с цветным фоном, консолидации и оптимизации изображений, а также оптимизации JavaScript и таблиц стилей — страница смогла сократить свои запросы к серверу. 20 до 6, ускоряя время загрузки до 6 секунд на модеме 56k. Благодаря исключению кода смены кода JavaScript, сам код HTML был уменьшен на 41%, даже с учетом немного большего размера кода CSS (из-за добавления ролловеров CSS к панели навигации). Страница такая же функциональная, и, поскольку она загружается в два раза быстрее (в среднем 6 секунд на модеме 56 Кб), она привлечет и удержит значительно больше посетителей (см. Стр. 50-53).

Но, вы говорите, моя страница имеет несколько десятков обращений к серверу, и загрузка не занимает 15 секунд! Может и нет, но ты уверен? Вы тестируете свою страницу по коммутируемому соединению 56k, или вы предполагаете, что все используют широкополосное соединение или соединение T1, которое вы используете? И мы знаем, что современные браузеры и серверы могут отправлять несколько одновременных запросов для ускорения времени загрузки для каждого вызова. Но помните: «даже с поддержкой HTTP каждое обратное путешествие добавляет больше времени, потому что сообщение должно проходить через Интернет от клиента к серверу и обратно» (стр. 53).

Эта концепция вдвойне важна при рассмотрении внешних файлов в <HEAD> вашего документа. Любые таблицы стилей и JavaScript в <HEAD> страницы должны быть обработаны, прежде чем что-либо отобразится визуально; страницы с несколькими файлами CSS и JavaScript могут обрабатываться ужасно долго, и все время, пока посетители вашего сайта сидят и тушатся, ожидая чего-то — чего угодно — случится.

Очистка кода

Я предполагаю, что никто из вас не использует одно из специальных предложений BloatCode, такое как главная страница Microsoft, для создания своих страниц. Если да, то вы так далеко за пределами, что эта статья не может вам помочь.

Все, что я могу вам сказать, это то, что в течение короткого времени я был нанят командой веб-дизайнеров крупной корпорации, чтобы помочь оптимизировать и стандартизировать их внутренние страницы технической помощи. Половина моего времени была потрачена на доставку мачете на страницы, созданные в Front Page. Мне обычно удавалось избавиться от 50-80% кода, не влияя на отображение страницы на йоту (хотя мне сказали, что FP2000 и более поздние выпуски гораздо менее подвержены вздутиям). Другими словами, если вы используете старую копию MSFP (или другой BloatCode Special — их много) для создания своих страниц, найдите другую альтернативу!

Подавляющее большинство посетителей не умеют читать HTML и не имеют понятия, хороший код или плохой, они просто заинтересованы в хорошем контенте и навигации. — Эндрю Старлинг

Одна из самых больших критических замечаний по поводу некоторых методов оптимизации, предлагаемых Энди, заключается в том, что тем, кто просматривает исходный код, трудно его прочитать и изменить. Правда, но почему бы не оптимизировать и не оптимизировать ваш код? Большинство посетителей вашего сайта не собираются смотреть на ваш код — им наплевать. Что касается ваших коллег-дизайнеров, им просто придется смириться и разобраться с этим — это стоит минимального дополнительного ухудшения для более низкой пропускной способности и более низких скоростей.

Удаление возврата строки

Вот прекрасный пример отказа от эстетически приятного кода в пользу эффективности. Браузерам все равно, есть ли у вас возврат после каждой команды или нет; удаление строки может значительно уменьшить размер файла. Вот пример со страницы 48:

 <TABLE>  <TR>  <TD>speed</TD>  </TR>  <TR>  <TD>me</TD>  </TR>  <TD>up</TD>  </TR>  </TABLE>

будет выглядеть так:

 <TABLE><TR><TD>speed</TD></TR><TR><TD>me</TD></TR>  <TD>up</TD></TR></TABLE>

давая вам 11% сокращение размера файла. Это не так красиво, но выглядит точно так же, когда отображается. Стоит ли жертвовать этим в эстетике кода? Вам решать.

Выбор правильного DOCTYPE: Строгий и Причудливый

HTML-страница, использующая стандарт «Строгий», будет анализироваться быстрее, чем страница, использующая стандарт «Переходный», и намного, намного быстрее, чем страница, использующая более старый стандарт или вообще без DOCTYPE. См. Мою предыдущую статью для SitePoint, Основы веб-дизайна , для более подробного объяснения DOCTYPES, и посетите страницу Mozilla DOCTYPE Sniffing для получения подробной информации о различных стандартах и о том, как браузеры, такие как Mozilla, решают, какой DOCTYPE используется.

Конечно, страница, использующая строгий стандарт, должна быть написана в строгом HTML 4.01 — без устаревших элементов. Страница, написанная в строгом HTML 4.01 со всеми используемыми закрывающими тегами, будет отображаться быстрее, чем аналогичная страница с использованием устаревших элементов и «причудливого» HTML, так как браузер должен выполнять меньше работы — даже если он будет немного больше из-за использования всех закрывающие теги (подробнее об этом позже). Хорошая вещь об этом — то, что это также приближает нас на один шаг к тому, чтобы быть совместимым со стандартами XHTML… который является совершенно другой темой.

Пробелы

«Пробелы» в HTML-коде — отступы, пропущенные строки и т. П. — предназначены исключительно для удобства использования дизайнером и странной птицей, которая просматривает код. Это никак не влияет на способ отображения кода и может фактически замедлить время загрузки. Вот простой пример из с. 53-4. Приготовьтесь удивляться тому, насколько уменьшен размер кода.

 <TABLE   ID='whitespace-repository'   WIDTH="800">  <TR>    <TD>speed</TD>    <TD>me</TD>    <TD>up</TD>  </TR>  <TABLE>

становится

 <TABLE ID='whitespace-repository' WIDTH="800">  <TR>  <TD>speed</TD>  <TD>me</TD>  <TD>up</TD>  </TR>  <TABLE>

или еще лучше:

 <TABLE ID='whitespace-repository' WIDTH="800"><TR>  <TD>speed</TD><TD>me</TD><TD>up</TD></TR><TABLE>

В этом последнем примере экономится более 50% размера файла по сравнению с оригиналом.

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

Атрибуты, разделенные запятыми

Несколько тегов, чаще всего <KEYWORDS> META, атрибут координат <MAP> и <STYLE> , позволяют использовать списки, разделенные запятыми. Браузеры и поисковые системы игнорируют пробелы после запятых. Вы можете сохранить драгоценный размер файла, исключив пробелы. Опять же, это не так легко для глаз, кто просматривает код, но все остальные получат выгоду.

Вот пример, извлеченный из pgs. 54-55:

 <STYLE TYPE="text/css">  <!--  body {  font-family: arial, helvetica, sans-serif;  font-size: 1.1em;  }  -->  </STYLE>

будет выглядеть так:

 <STYLE TYPE="text/css">  <!--  body{  font-family:arial,helvetica,sans-serif;  font-size:1.1 em;  }  -->  </STYLE>

или даже:

 <STYLE TYPE="text/css"><!-- body {font-family:  arial, helvetica, sans-serif;font-size:1.1 em;}--></STYLE>

Еще одно приятное уменьшение размера файла для небольшой потери в эстетике.

Отдел резервирования Отдел

Вы будете удивлены тем, сколько тегов и атрибутов являются избыточными и могут быть устранены, не влияя на работу кода. Устаревшие теги, такие как <FONT> и <BASEFONT> , <CENTER> , <STRIKE> и <U> могут обрабатываться более эффективно с помощью таблиц стилей. Как и многие другие атрибуты <BODY> — ALINK , VLINK , LINK , ALINK , VLINK и т. Д. Чем больше вы полагаетесь на таблицы стилей, тем больше вы также поддерживаете XHTML.

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

Вы можете использовать это:

 <TABLE>  <TR>    <TD ALIGN="right">tastes great</TD>    <TD ALIGN="right">less filling</TD>    <TD ALIGN="right">burma shave</TD>  </TR>  </TABLE>

но это работает лучше:

 <TABLE>  <TR ALIGN="right">  <TD>tastes great</TD>  <TD>less filling</TD>  <TD>burma shave</TD>  </TR>  </TABLE>

Еще больше места можно сэкономить следующим образом:

 <style type="text/css">  <!--  table.tr.right{text-align:right;}  -->  </style>  ...  <TABLE><TR CLASS="right"><TD>tastes great</TD>  <TD>less filling</TD><TD>burma shave</TD>  </TR></TABLE>

Вы можете написать еще дюжину таблиц на этой странице, используя ту же таблицу стилей.

Устранение необязательных цитат

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

Так что это работает:

 <IMG SRC="t.gif" WIDTH=1 HEIGHT=1>

но это не так:

 <TABLE WIDTH=100%>

Yahoo !, самый загруженный сайт в сети, пропускает цитаты из тегов ссылок. Другие сайты полностью опускают кавычки, нарушая стандартные рекомендации HTML, но в любом случае доверяют отдельному браузеру. Обычно это работает … обычно (с. 57).

Пропуск необязательных закрывающих тегов

Хорошо, вот тот, который сохраняет несколько байтов, но нарушает стандарты XHTML, которые требуют, чтобы все теги были закрыты, а атрибуты были полностью квалифицированы. Если вас это не касается, тогда эти теги не нужно закрывать: <P> , <LI> , <OPTION> и даже <BODY> и <HTML> . Вы также можете опустить закрывающие теги для тегов <TR> и <TD> , но Netscape 3 не будет правильно отображать таблицы без этих закрывающих тегов.

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

Комментарии

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

Свернуть раздел <HEAD>

В разделе <HEAD> мета-теги, таблицы стилей и JavaScript занимают много места. Чем меньше вы в состоянии ладить, тем быстрее загружается ваш сайт. Помните, что все в вашем разделе <HEAD> должно быть проанализировано до загрузки остальной части вашей страницы.

Мета-теги часто используются слишком часто. Хотя в некоторых случаях они необходимы — спецификация ключевых слов для некоторых поисковых систем, определение сценариев по умолчанию, языков таблиц стилей и наборов символов, расширение заголовков HTTP, отправляемых с сервера, и т. Д., Многие из них либо избыточны, либо не нужны. В самом строгом смысле единственные теги META, которые вам абсолютно необходимы, — это теги KEYWORDS и DESCRIPTION. Остальные излишни или лучше обрабатываются настройками сервера (для получения дополнительной информации об использовании мета-тегов см. Мой столбец «Практический веб-дизайн», 15 лучших хитростей мета-тегов ).

Оптимизация таблиц

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

Как можно больше рассказывать браузеру о структуре и сложности таблицы, а также, по возможности, уменьшать сложность таблиц — это путь к максимальной эффективности. Упростите, когда сможете. Используйте CSS для стилизации таблиц. Используйте цвета фона вместо фоновых изображений. И если вы действительно хотите ускорить процесс, полностью избавьтесь от таблиц и выложите свою страницу, используя различные элементы <DIV> и CSS2 (Энди дает совет в другой главе по этой конкретной теме).

Одна вещь, которую мы все можем сделать, это дать браузеру достаточно информации о таблице, чтобы иметь возможность визуализировать таблицу постепенно, вместо того, чтобы ждать, пока все загрузится заранее. Вы можете использовать элементы COL и COLGROUP чтобы указать браузеру, сколько столбцов вы используете и их ширину (в пикселях, процентах или относительной ширине). Это позволяет браузеру сделать один проход за столом вместо двух (первый находит количество столбцов) перед рендерингом. Если таблица не имеет фиксированной ширины, браузер должен получить каждый байт данных, прежде чем они смогут изменить размер таблицы.

Вы также можете сгруппировать строки таблицы в разделы THEAD , ноги и тела TFOOT , TBODY элементы THEAD , TFOOT и TBODY . Энди хорошо говорит: «Вы можете отформатировать эти группы по отдельности и использовать их для печати более длинных многостраничных таблиц, когда вы хотите, чтобы информация на верхнем и нижнем колонтитулах печаталась на каждой странице» (стр. 69).

Многие сайты (включая мой) используют одну всеобъемлющую таблицу, чтобы выложить большую часть или всю страницу. Часто это означает, что браузер должен загрузить все в этой таблице, прежде чем он сможет отобразить ее. Страница, которая сидит и сидит, кажется, ничего не делая, а затем внезапно отображает все сразу, вероятно, выложена таким образом. Зачем заставлять свою аудиторию так ждать? Вместо этого, слой ваших таблиц. Начните свою страницу с небольшой быстро загружаемой таблицы, которая содержит что-то полезное, например окно поиска, панель навигации или, по крайней мере, изображение заголовка, чтобы вознаградить усилия ваших посетителей и убедить их, что ваша страница, действительно, спускаясь на щуку. Таблица «выше сгиба» позволяет загружать дополнительный контент сразу после первой таблицы, давая вашим посетителям что-то, с чем можно бороться, пока загружается остальная часть вашей страницы. Даже если вся ваша страница загружается медленнее, чем раньше, стоит дать своим посетителям что-то, с чем можно немедленно поработать (и нет, объявления, которые появляются первыми, не учитываются. Посетители не заходили на ваш сайт, чтобы посмотреть объявления) ,

Если вы работаете строго с браузерами, совместимыми с CSS2, вы можете использовать свойство TABLE-LAYOUT для ускорения рендеринга таблиц. Это свойство позволяет нам контролировать алгоритм, используемый браузерами для размещения ячеек, строк и столбцов таблицы.

Конечные косые черты в URL

Некоторые люди не думают, что есть разница между этими двумя URL-адресами:

http://www.mysite.com и http://www.mysite.com/

но есть. Конечная косая черта сообщает браузеру, что URL указывает на каталог, и в результате браузер не должен решать, указывает ли URL каталог или файл. Вы можете ускорить время отклика URL, добавив косую черту за списком каталогов (не файл — не делайте этого: http://www.mysite.com/index.html/).

Использование CSS для работы

Я позволю вам купить книгу, чтобы узнать подробности об этой области оптимизации, но вкратце, использование CSS для замены ролловеров изображений и дизайнов на основе таблиц вполне стоит того времени и усилий, которые потребуются вам для преобразования. Поскольку все больше и больше пользователей переходят на современные браузеры, такие как IE 5+, Netscape 6+ и Mozilla, у вас будет меньше проблем с пользователями, браузеры которых отказываются поддерживать CSS.

Вывод

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

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

Тем не менее, стремление к эффективности Интернета не является «дополнительным», которое можно отложить на задний план, а «когда мы обойдем это». Это то, что должно решаться с самого начала создания новой страницы, и то, что должно учитываться для любой уже созданной страницы. Если эти методы могут помочь пользователям вашего сайта получать больше удовольствия и больше использовать свои посещения вашей страницы, то они заслуживают рассмотрения. Подумайте о них, прежде чем уволить их из-под контроля, потому что это не то, к чему вы привыкли — их преимущества могут значительно перевесить затраты на «эстетику HTML».