GrAndSE's blog

Переваги блочної верстки. Продовження

Минуло не мало часу з того моменту, як я писав про історію розвитку HTML та CSS, а також переваги блочного типу верстки веб-сторінок над табличним. Ну все там написане було теоретичними оцінками, себто моїми особистими думками, які можуть нікого ні в чому не переконати. Тому в кінці тієї замітки і написав, що хочу провести деякі практичні експерименти, щоб порівняти блочну та табличну верстку в умовах наближених до практики та підтвердити сказане мною раніше. Ну що ж. Думаю, час для цього настав.

Що ми будемо робити?

Оскільки HTML та CSS - технології орієнтовані на клієнта, то слід досліджувати в першу чергу, те що отримає в результаті клієнт. Якщо допустити, що сторінки зверстані таблицями та блоками будуть виглядати абсолютно ідентично, то що залишається порівнювати? Обсяг сторінки, та швидкість обробки її браузером. Звісно, що довге завантаження сторінки та довга її побудова викликають роздратування користувача сайту

Звичайно, що обсяг сторінки важливий і для власника сайту: менші сторінки дають менше навантаження на хостинг, і менша кількість елементів на сторінці зменшує кількість символів, які необхідно набрати на клавіатурі (дуже важливий критерій звичайно ж :)) та що більш важливе - зменшує ймовірність помилок.

Отже буду я оцінювати розмір сторінки, стилів до цієї сторінки, кількість та зрозумілість написаного коду, а також час обробки отриманого результату браузером.

На чому ми будемо тестувати?

Нехай нам потрібно створити простий елемент з закругленими кутами, на зразок:

І нехай нам потрібно, щоб він містив деякий заголовок, тіло-контент та якийсь підпис внизу:

Звертаємо зображення шляхом поділу на три відповідні блоки: заголовок, тіло та підпис внизу (header, content, footer) та підкладемо кожному з них частину зображення в якості фону. Не дивлячись на всю синтетичність тесту, такий підхід до верстки подібних елементів є досить поширеним,

Таким чином, я створив аж чотири варіанти такого елементу:

Чиста таблиця

весь елемент представлено однією таблицею, а кожну частину рядком з відповідним класом

Брудна таблиця

аналогічно до попереднього варіанта, з тією різницею, що теги td та tr я не закриваю, щоб менше писати та отримати менший обсяг сторінки - таблиці допускають такий жах

Блоки

три блоки (div) з класами header, content та footet

Семантична верстка

замість div використовуються більш змістовні елементи: блок цілком залишається div, заголовок стає h2, контент p, а підвал перетворються на span

Думаю, що код для кожного з варіантів є достатньо простим, щоб його не наводити, а якщо ось не зрозуміле, то подивитись можна в архіві з вихідними матеріалами до замітки.

Оскільки отриманий код маленький і буде миттєво оброблятись браузером, передаватись мережею, то для його оцінок необхідно мені було скопіювати і щоб це не робити руками, я написав невеличкий скрипт (всього 24 рядки) мовою python, який генерує чотири html-файли, що містять по 10000 відповідних елементів. Програмний код також є в архіві.

І останнє. Для перевірки швидкості завантаження сторінки браузером, я використав невеличкий javascript:

Цей код заміряє час на початку завантаження сторінки та в кінці завантаження і через показує їх різницю. Нічого розумнішого мені в голову не прийшло і в гуглі нічого кращого не знайшлось, тому скористався тим способом, що зміг швидко вигадати та реалізувати.

Результати тестів

Почну з порівняння об'ємів файлів. Найменший CSS файл розміром аж в 312 байтів я отримав для блочної верстки, а одразу за ним йде файл для табличної верстки - 323 байти. Однак і найбільший файл (для семантичної верстки) в 379 байт не є дуже великим. Як камінь в бік табличної верстки хочу сказати, що не знаю як за допомогою CSS подолати cellspacing. Мабуть якось можна, однак шукати як я не захотів, тому таблична верстка трошки пливе.

А що до самих html-файлів, то одразу скажу, що семантична верстка значно полегшує сторінку - всього 990181 байт для отриманої сторінки, що значно менше за 1490175 байт для табличної та 1490179 для блочної верстки. Навіть позбавлення від закриваючих тегів не дало перевагу табличній верстці - 1160152 байт, що на четверту частину більше за семантичний варіант.

Знову ж нагадаю, що з sellspacing я не боровся, і оскільки зазвичай цей параметр пишуть як атрибут до тега таблиці, то для таблиць розмір мав би бути більшим.

Тепер перейдемо до кількості елементів DOM. Тут все зрозуміло: для блочної та семантичної верстки 4 елементи на один екземпляр блоку з заокругленими кутами з рівнем вкладеності 2, а для табличної аж 7 з 3 рівнями ієрархії.

Ну а тепер сама весела частина - порівняння часу обробки сторінки різними браузерами. Для тесту я обрав браузери наявні в моїй системі (Ubuntu Linux 9.04), а саме Firefox 3, Opera 9 та Konqueror(KDE4).

Оскільки час, який браузер потребує для обробки сторінки при її відкритті та оновленні відрізняється, тому наводжу обидва значення: перше - при оновленні сторінки, а друге при новому заході на сторінку. Почну з мого улюбленця - Firefox. Швидкість його роботи невисока та помітне гальмування з часом - чим більше він працює, тим більше часу витрачається на обробку сторінки. Можливо накопичується сміття в пам'яті, тому виникає гальмування. А ось і результати:

• Таблиця (не закриті теги): 5800/5500 мс. коливання близько 200 мс, а іноді і в декілька секунд (максимальний час обробки 9 досяг секунд)
• Таблиця: 5900/5800 мс. коливання близько 400 мс., і знову ж іноді помітні "провали" у швидкодії
• Блоки: 5300/5450 мс. коливання 100 мс., зменшення кількості "провалів"
• Семантична: 5300/5100 мс. коливання в 300 мс., падінь швидкодії не було

Що цікаво, Вогнелис практично завжди на великих файлах показує більшу швидкість якщо сторінку відкривати заново, а не оновлювати. Як можна побачити, час обробки сторінок з блочною та семантичною версткою на 5-10% менший ніж табличною. Opera (версія 9.64) під Linux мене розчарувала як швидкодією так і стабільністю - під час тестування вона дала випередити себе Firefox'у на табличній верстці та ще й періодично підвисала і реагувала тільки на killall. Здається під Windows вона працює краще.

• Таблиця (не закриті теги): 6200/12500 мс. коливання близько 500/1000 мс
• Таблиця: 6200/11000 мс. коливання близько 200/1000 мс.
• Блоки: 3500/5250 мс. коливання 200 мс.
• Семантична: 3300/5000 мс. коливання в 200 мс.

Зависання відбувались на всіх тестах, тому я проводив їх небагато, оскільки на кожних 10-15 оновлень сторінки Opera хоча б раз вмирала. Однак і цих результатів достатньо - перевага блочної верстки над табличною очевидна, та й працює Opera с блоками стабільніше. Ну і останнім в моєму огляді та не останнім за швидкодією є Konqueror. Він виявився найшвидшим та найстабільнішим за часом обробки сторінки.

• Таблиця (не закриті теги): 3130/3870 мс. коливання до 50 мс
• Таблиця: 3220/3960 мс. коливання до 100 мс.
• Блоки: 2250/2550 мс. коливання до 100 мс.
• Семантична: 1950/2230 мс. коливання до 50 мс.

Тут все просто та інформативно: сам браузер швидший за своїх конкурентів як мінімум в 1.5 рази, і аналогічно блочна та семантична верстка в 1.5 рази швидші ніж таблична.

Те що й треба було довести

Одразу скажу, що отримані результати саме такі, які я й прагнув отримати - блочна верстка нічим не поступається табличній, а за часом обробки є значно кращим вибором. Дозволю собі викласти свої думки стосовно причин такої поведінки браузерів. Як мої результати так і результати дослідження впливу різних факторів на швидкодію браузера від студії Лєбєдєва вказують, що кількість елементів DOM та глибина ієрархії помітно впливають на показники швидкодії браузерів. З урахуванням всього вищесказаного оптимальним варіантом мені здається верстка близька до семантичної, оскільки вона зменшує обсяг коду на сторінці, обробляється швидше та зрозуміліша для людини, а якщо вірити документації від пошукових систем, то й для їх роботів теж. Хоча останнє слово в виборі того, як Ви будете працювати залишається за Вами. Дякую за увагу!