С чего начинается вебмастер? Не знаю, чему сейчас учат в школе, но как вебмастер я начался с файла index.html, который был создан на школьном компе с windows'98 в блокноте и открыт в ie6. До сих пор помню свой восторг - в том файле были описаны теги <title> и <body> - в шапке браузера появилась надпись "привет!", а в окне - "это мой сайт" :) Время прошло, я стал программистом, cms завоевали мир, а мне до сих пор приятно создать чистенький файл index.html и заполнить его.
Идею мне подал мой друг и коллега, Александр Бакаев. Он рассказывал о своём учителе информатики, у которого когда-то был сайт - каталог насосов. Сайт тот изначально был статическим и представлял собой набор html страниц, распределённых по папкам на сервере и, собственно говоря, всё. Он никогда не продвигался, никогда не оптимизировался, однако, по высокочастотным запросам в поисковых системах он выходил на первые места. Размышляя на эту тему, у меня родилась теория крутизны статических сайтов на фоне динамических, и мне захотелось реализовать полноценный сайт (позднее - блог), который будет работать без серверных скриптов и баз данных, но будет при этом удобным, максимально гибким и расширяемым.
Уважаемый читатель! Обращаю твоё внимание на слово "теория" в предыдущем абзаце. Это всего лишь теория, которую я в этот самый момент начинаю проверять экспериментально. Я ни в коем случае не пытаюсь сказать, что за статическими сайтами будущее или что на них срочно нужно всем переходить. Мне просто любопытно, используя технологии сегодняшнего дня, собрать статический ретро-блог.Преимущества статического сайта
- Безопасность - а чего там взламывать-то? Исходные коды все и так открыты, html файлы и так в публичной папке, и нет ни одного скрипта, который запускается на сервере. Если хранить доступ к серверу в надёжном месте, можете считать, что сайт неприступен.
- Быстрое открытие страниц - время уходит лишь на запрос и передачу конкретного html файла. Он уже лежит на сервере готовый, а не геренируется каждый раз заново.
- Пониженная нагрузка на сервер - в данном случае сервер выполняет лишь роль хранения и передачи данных. Никаких скриптов, никаких баз данных, никаких запросов к ним и связанных с этим нагрузок.
- Понятные адреса страниц - все системы ЧПУ в современных cms ориентированы на то, чтобы имитировать каталожную структуру хранения данных на сайте. Тут подделывать ничего не придётся, не придётся колдовать с mod_rewrite или редиректами. Документы изначально логично распределяются по директориям, что отражается и в структуре url.
- Отсутствие дублей - этот пункт вытекает из предыдущего. Любой специалист по внутренней оптимизации знает, как важно, чтобы одна и та же страница не была доступна по разным адресам. В случае со статическим сайтом это физически невозможно.
- Тонкая настройка - каждая страница - уникальна, независима и хранится в отдельном файле. Более тонкой настройки, чем в этом случае, получить вряд ли возможно.
Не всё так просто
Разумеется, я это понимаю. Если ты, читатель, мало-мальски представляешь, что такое cms, то наверняка уже думаешь о недостатках и ограничениях, которые накладывает использование статики.
- Отсутствие возможности шаблонизации - в подавляющем большинстве современных cms есть понятие шаблонов. В шаблонах содержатся элементы дизайна и разметки, повторяющиеся на разных страницах сайта. В случае со статикой их приходится многократно дублировать, а это неудобно, ненадёжно и совершенно не гибко. Чего только стоит представить ситуацию, если на сайт с несколькими сотнями статических статей, разложенных по папкам на сервере, потребуется вставить счётчик.
- Сложности навигации по сайту - менюшки, хлебные крошки, постраничная навигация. Мы ко всему этому так привыкли, что представть сайт без них - невозможно. А как добавить пункт в меню, если меню это продублировано на сотнях страниц? Как сделать список статей в категории с постраничной навигацией, если при добавлении новой статьи все элементы на всех страницах категории должны будут сместиться?
- Невозможность контроля доступа к данным - все файлы хранятся в публичной директории, а отсутствие авторизации не позволяет ограничить к ним доступ.
- Отсутствие интерактивности - пользователь ничего не может. Ну просто ничего - ни отправить комментарий, ни выполнить поиск по сайту, ни форму обратной связи заполнить.
- Сложности при наполнении - спорный вопрос, однако, для многих наличие админки с удобным интерфейсом и визуального редактора html кода является обязательным.
Вот, что в итоге получилось
| Параметр | Динамический сайт | Статический сайт |
|---|---|---|
| Безопасность | на совести программиста | гарантирована |
| Скорость работы | ниже | выше |
| Нагрузка на сервер | выше | ниже |
| ЧПУ | спляшем? | гарантируется |
| Дубли страниц | есть опасность | невозможны |
| Тонкая настройка | проблематична | не вопрос |
| Шаблонизация | возможна | невозможна |
| Навигация по сайту | удобна | ужасна |
| Ограничение доступа к данным | возможно | невозможно |
| Интерактивность | возможна | невозможна |
| Удобство заполнения | удобна многим | для крутых ребят :) |
Стоит ли побороться?
Что касается недостатков из первой колонки - разумеется, бороться стоит. Борьба с ними даёт работу многим программистам и оптимизаторам, которые достигают в ней больших успехов. А вот стоит ли бороться с недостатками из второй колонки? Оправдают ли себя достоинства? Лично я - попробую. О методах борьбы с ограничениями, которые накладывает использование статики, и будет следующая заметка.