2.04. Сайты и веб-сайты

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ

Всем

Сайт и веб-сайт

1. Сущность и принципы функционирования

1.1 Что такое «сайт»

Термин «сайт» (от англ. site — «место», «локация») впервые вошёл в русскоязычную техническую лексику в середине 1990-х годов и с тех пор закрепился как обобщённое обозначение любого ресурса, доступного в сети Интернет по уникальному адресу. В строгом смысле, сайт и веб-сайт являются синонимами: оба указывают на совокупность взаимосвязанных ресурсов — прежде всего, веб-страниц, — объединённых общей тематикой, функциональной логикой и доменным именем.

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

Веб-сайт — это логическая структура данных, реализованная с использованием протоколов, программного обеспечения и аппаратных ресурсов. Он существует в двух проекциях одновременно:

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

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

1.2 Клиент-серверная модель

Функционирование любого веб-сайта базируется на модели взаимодействия клиента и сервера, стандартизированной в рамках протокола HTTP (Hypertext Transfer Protocol) и его защищённой версии HTTPS. Эта модель предполагает чёткое распределение ролей:

Клиент — программа, инициирующая запрос. В подавляющем большинстве случаев это веб-браузер (Chrome, Firefox, Safari и др.), но клиентом может быть и мобильное приложение, скрипт, поисковый робот или IoT-устройство.
Сервер — программно-аппаратная система, принимающая запросы, обрабатывающая их и возвращающая ответ. Сервер может быть физическим компьютером, виртуальной машиной или контейнером в облачной инфраструктуре; на нём запущено специализированное ПО (например, веб-сервер Nginx или Apache), а также прикладной код (бэкенд-логика).

Процесс взаимодействия происходит по следующему сценарию:

Пользователь вводит URL (например, https://example.com/about) или кликает по гиперссылке.
Браузер разрешает доменное имя в IP-адрес с помощью DNS-сервиса.
Устанавливается TCP-соединение между клиентом и сервером (на порту 80 для HTTP, 443 для HTTPS). При использовании HTTPS дополнительно происходит согласование TLS-сессии для шифрования трафика.
Клиент отправляет HTTP-запрос: метод (GET, POST и др.), путь ресурса, заголовки (User-Agent, Accept, Cookie и др.), а при необходимости — тело запроса (например, данные формы).
Сервер обрабатывает запрос:
- анализирует путь и метод;
- проверяет авторизацию (при наличии);
- выполняет бизнес-логику (чтение из БД, вычисления, вызов внешних API);
- формирует HTTP-ответ: статус-код (200 OK, 404 Not Found и др.), заголовки (Content-Type, Set-Cookie) и тело ответа (обычно — HTML-документ или JSON-структура).
Клиент получает ответ и интерпретирует его:
- при получении HTML — парсит разметку, загружает связанные ресурсы (CSS, JS, изображения), строит DOM-дерево, применяет стили, выполняет скрипты, отрисовывает страницу;
- при получении JSON — передаёт данные в JavaScript-логику для обновления интерфейса без полной перезагрузки (в случае SPA).

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

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

1.3 Сайт как информационная система

С технической точки зрения веб-сайт — это реализация информационной системы, соответствующей общим принципам проектирования ИС:

Входные данные: пользовательские запросы (GET/POST), загружаемые файлы, события (клик, прокрутка), внешние сигналы (вебхуки, API-вызовы от сторонних сервисов).
Процесс обработки: преобразование входных данных в соответствии с заданной логикой (валидация, маршрутизация, выполнение бизнес-правил, интеграция с внешними системами).
Выходные данные: отрендеренная страница, JSON-ответ, перенаправление, файл для скачивания, событие в потоке (SSE, WebSockets).
Хранилище: базы данных (реляционные и документные), кэши (Redis, Memcached), файловые системы (локальные, облачные бакеты), индексы (Elasticsearch).

Различия между статическими, динамическими сайтами и веб-приложениями (о которых речь пойдёт далее) обусловлены степенью сложности и локализацией этих компонентов:

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

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

2. Классификация сайтов

2.1 Статические сайты

Определение. Статический сайт — это набор предварительно сформированных HTML-, CSS- и JavaScript-файлов, хранящихся на сервере и возвращаемых клиенту без изменений при получении запроса. Никакой логики обработки запроса на стороне сервера не происходит: веб-сервер (например, Nginx) лишь читает запрошенный файл с диска и отдаёт его по HTTP.

Архитектурные особенности.

Отсутствие серверной логики: нет прикладного кода (на C#, Python, PHP и др.), выполняемого при каждом запросе.
Отсутствие базы данных в runtime: данные интегрируются в HTML на этапе сборки (build-time).
Минимальная атакуемая поверхность: нет динамической обработки входных данных → снижена уязвимость к инъекциям, XSS (если контент доверенный), DoS через тяжёлые вычисления.
Высокая производительность: отдача файлов — одна из самых лёгких операций для сервера; возможен эффективный кэширование на CDN.

Сборка и развёртывание.
Современные статические сайты редко создаются вручную. Используются генераторы статических сайтов (Static Site Generators, SSG): Jekyll, Hugo, Eleventy, Astro, Docusaurus. Они принимают исходные материалы (Markdown, JSON, YAML, шаблоны) и на их основе компилируют готовый набор HTML-страниц. Процесс сборки — это запуск консольной утилиты (например, hugo build), после которого получается каталог с файлами, пригодными к размещению на любом хостинге (вплоть до GitHub Pages).

Типичные сценарии применения.

Сайты-визитки компаний и частных специалистов.
Документация (как, например, ваш проект «Вселенная IT» — Docusaurus как раз генерирует статический сайт).
Блоги и портфолио.
Лендинги с фиксированным контентом и ограниченной интерактивностью (формы отправляются через сторонние сервисы: Formspree, Netlify Forms, или через API-эндпоинт на внешнем сервере).

Ограничения.

Невозможность персонализации контента без JavaScript: один и тот же HTML возвращается всем пользователям.
Обновление контента требует повторной сборки и деплоя — вручную или через CI/CD.
Отсутствие встроенных механизмов авторизации, управления пользователями, обработки платежей.

Примечание: «статичность» относится к серверной части. Клиентская логика (JavaScript) может быть весьма сложной — например, SPA, собранный как единый index.html со встроенным маршрутизатором, технически является статическим файлом, но ведёт себя как динамическое приложение. Это плавный переход к следующему типу.

2.2 Динамические сайты

Определение. Динамический сайт — это система, в которой HTML-контент генерируется на лету (at request time) сервером в ответ на каждый запрос. Структура и наполнение страницы зависят от множества факторов: параметров URL, данных пользователя (куки, сессия), состояния базы данных, внешних API.

Архитектурные особенности.

Серверная логика обязательна: приложение (на PHP, Java, C#, Node.js, Python и др.) загружается в память сервера и обрабатывает каждый входящий HTTP-запрос.
Наличие базы данных: реляционной (PostgreSQL, MySQL) или документной (MongoDB), используемой как основное хранилище изменяемого контента.
Шаблонизация: HTML формируется путём подстановки данных в заранее заготовленные шаблоны (Jinja2, Razor, Thymeleaf, Handlebars).
Поддержка пользовательских сессий: аутентификация, авторизация, персональные настройки, корзина покупок.

Жизненный цикл запроса (типичный пример: просмотр статьи в CMS).

Пользователь переходит по ссылке /article/123.
Веб-сервер (например, Apache с mod_php) передаёт запрос приложению.
Приложение:
- извлекает из URL идентификатор статьи (123);
- выполняет SQL-запрос SELECT * FROM articles WHERE id = 123;
- проверяет права доступа (требуется ли авторизация);
- формирует объект данных (например, DTO в C# или dict в Python);
- рендерит HTML, подставляя данные в шаблон article.html;
- добавляет в ответ куки сессии (если пользователь вошёл).
Сервер возвращает сгенерированный HTML.
Браузер отображает страницу; при необходимости — загружает дополнительные ресурсы (CSS, JS, изображения).

Типичные сценарии применения.

Новостные порталы и издания (контент постоянно обновляется).
Интернет-магазины (каталог, фильтрация, корзина, заказы).
Корпоративные порталы (внутренние документы, HR-системы).
Форумы и блоги с комментариями.

Преимущества перед статикой.

Гибкость контента: изменения в БД мгновенно отражаются на сайте без пересборки.
Персонализация: контент адаптируется под роль, предпочтения, историю пользователя.
Интерактивность «из коробки»: формы, авторизация, администрирование.

Недостатки.

Более высокая нагрузка на сервер: каждый запрос требует вычислений и обращений к БД.
Сложность масштабирования: при росте трафика требуется оптимизация запросов, кэширование, горизонтальное масштабирование.
Повышенные требования к безопасности: защита от SQL-инъекций, XSS, CSRF, неправильной обработки загрузки файлов.

Современные гибридные подходы.
Чтобы сохранить преимущества динамики, но улучшить производительность, применяются:

Серверный рендеринг (SSR): HTML генерируется на сервере (как в классике), но после загрузки страницы передаётся управление JavaScript-фреймворку (Next.js, Nuxt.js), обеспечивая SPA-поведение.
Инкрементальная статическая регенерация (ISR): часть страниц генерируется статически при сборке, часть — динамически по мере необходимости, с фоновым обновлением кэша (Next.js, Remix).
Edge-side rendering: рендеринг происходит не на origin-сервере, а на CDN-нодах ближе к пользователю (Vercel, Cloudflare Workers).

Эти методы стирают грань между статикой и динамикой и формируют основу следующего типа — веб-приложений.

2.3 Веб-приложения (Web Applications, SPA)

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

Архитектурные особенности.

Разделение на клиент и API: сервер предоставляет только данные (в формате JSON или XML) через чётко определённые эндпоинты; рендеринг полностью на клиенте.
Единая точка входа: все маршруты обрабатываются одним HTML-файлом (index.html), внутри которого JavaScript-роутер (например, React Router) решает, какой компонент отобразить.
Управление состоянием: данные, полученные с сервера, хранятся в клиентском хранилище (Redux, Zustand, Vuex, MobX или встроенные хуки), что позволяет избежать повторных запросов при навигации.
Богатая клиентская логика: валидация форм, анимации, drag-and-drop, offline-режим (с использованием Service Workers и IndexedDB).

Жизненный цикл (пример: отправка сообщения в чате).

Пользователь вводит текст и нажимает «Отправить».
JavaScript перехватывает событие submit, предотвращает стандартную отправку формы.
Валидирует введённые данные (длина, запрещённые символы).
Формирует JSON-объект: { "text": "Привет!", "userId": 42, "timestamp": "2025-11-20T10:00:00Z" }.
Отправляет POST-запрос на /api/messages через fetch().
Сервер:
- проверяет JWT-токен в заголовке Authorization;
- сохраняет сообщение в БД;
- возвращает JSON с подтверждением ({ "id": 101, "status": "delivered" }).
Клиент получает ответ, обновляет локальное состояние (добавляет сообщение в список), отображает его в интерфейсе — без перезагрузки страницы.

Технологические стеки.

Frontend: React, Angular, Vue.js, Svelte, SolidJS.
Backend (API): REST, GraphQL, gRPC-over-HTTP; фреймворки — Express.js (Node.js), ASP.NET Core (C#), Spring Boot (Java), FastAPI (Python).
Инфраструктура: отдельные домены для статики (static.app.com) и API (api.app.com); CORS-политики; токены аутентификации (JWT, OAuth 2.0).

Типичные сценарии применения.

Почтовые клиенты (Gmail, Outlook Web).
Графические редакторы (Figma, Canva).
Управленческие системы (Trello, Notion, Jira).
Мессенджеры и конференц-зоны (Slack, Discord Web).
Сложные SaaS-продукты (CRM, ERP, BI-панели).

Преимущества.

Высокая отзывчивость интерфейса: действия пользователя мгновенно отражаются в UI.
Гибкость дизайна: отсутствие привязки к HTML-шаблонам сервера позволяет создавать нестандартные интерфейсы.
Чёткое разделение ответственности: frontend и backend команда могут работать параллельно по контракту API.

Недостатки и вызовы.

Сложность SEO: поисковые роботы могут не дождаться выполнения JavaScript; требуются SSR или prerendering.
Увеличенный объём начальной загрузки: нужно скачать и выполнить фреймворк, библиотеки, приложение.
Повышенные требования к качеству клиентского кода: утечки памяти, гонки состояний, ошибки в асинхронной логике.
Проблемы с доступностью (a11y): динамическое обновление контента требует явной поддержки ARIA-атрибутов и announce-уведомлений для скринридеров.

2.4 Гибридные архитектуры

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

Сайт с динамическим ядром и статическими поддоменами: основной контент — динамический (магазин), а блог и документация — статические (собираются через Hugo и деплоятся на отдельный субдомен).
SPA с SSR для критических маршрутов: главная страница и страницы товара отдаются с сервера (для SEO и скорости FCP), а после гидратации интерфейс «оживает» как SPA.
Микрофронтенды: разные разделы сайта реализованы разными командами на разных фреймворках (React для админки, Vue для публичной части, Angular для старого модуля), но интегрированы в единый shell.
JAMstack с API-слоем: статический фронтенд + сторонние API (Auth0 для аутентификации, Stripe для платежей, Algolia для поиска) + serverless-функции (на AWS Lambda, Vercel Functions) для выполнения логики, требующей приватного кода.

Такой подход позволяет оптимизировать проект под конкретные метрики: время загрузки, конверсию, стоимость инфраструктуры, скорость разработки.

3. Структура сайта

3.1 Клиентская часть (Frontend)

Frontend — это совокупность всех ресурсов и логики, выполняемых в пользовательском браузере. Его задача — преобразовать технические данные (HTML, CSS, JS) в воспринимаемый человеком интерфейс и обеспечить предсказуемое, отзывчивое взаимодействие. Frontend состоит из трёх слоёв, каждый из которых решает отдельную задачу, но функционирует в тесной связке.

3.1.1 HTML

HTML (HyperText Markup Language) — язык разметки. Он определяет структуру и смысл контента.

Например:

<h1>–<h6> — заголовки иерархии, а не просто «большой жирный текст».
<article> — самостоятельная, логически завершённая единица контента (статья, пост).
<nav> — набор навигационных ссылок.
<time datetime="2025-11-20">20 ноября 2025</time> — машинно-читаемое и человеко-ориентированное представление даты.

Семантическая разметка критична для:

Поисковой оптимизации (SEO): поисковые системы анализируют структуру DOM, чтобы понять тему и важность контента.
Доступности (a11y): скринридеры используют семантику для построения логического дерева навигации.
Сопровождаемости: разработчики читают код как документ — main > section > article > p понятнее, чем div > div > div > span.

HTML — это «сырой» интерфейс. Без CSS он отображается в браузере по умолчанию (стили user agent), без JavaScript — статичен. Но именно HTML задаёт фундамент: если структура неверна, никакие стили и скрипты не исправят фундаментальные проблемы.

3.1.2 CSS

CSS (Cascading Style Sheets) управляет внешним видом и компоновкой элементов. Он накладывает правила отображения на уже существующую структуру.

Современный CSS решает задачи, выходящие за рамки «цветов и отступов»:

Адаптивный дизайн: с помощью медиавыражений (@media (max-width: 768px)) интерфейс перестраивается под разные экраны — от мобильных устройств до 4K-мониторов.
Гибкая компоновка: Flexbox для одномерных макетов (строки, колонки), CSS Grid — для двумерных (сетки, сложные панели).
Анимации и переходы: плавные изменения свойств (transition) или ключевые кадры (@keyframes) без JavaScript.
Темизация: кастомные CSS-свойства (переменные) позволяют динамически менять палитру, шрифты, размеры — например, для тёмного режима.
Оптимизация производительности: will-change, contain, content-visibility дают браузеру подсказки для эффективной перерисовки.

CSS-правила каскадируются — отсюда название. Приоритет определяется специфичностью селектора (inline > id > class/attribute > tag) и порядком в файле. Это требует дисциплины в написании стилей: BEM, CSS Modules, CSS-in-JS — попытки структурировать этот процесс.

3.1.3 JavaScript

JavaScript — единственный язык, нативно исполняемый в браузере. Его роль — наделить интерфейс динамическим поведением. Современный фронтенд-код редко пишется «всухую»: используются фреймворки (React, Vue, Angular), которые абстрагируют от низкоуровневых операций с DOM и предоставляют декларативную модель управления состоянием.

Ключевые задачи JavaScript на клиенте:

Обработка событий: клики, нажатия клавиш, прокрутка, изменение размера окна.
Асинхронное взаимодействие: отправка форм без перезагрузки (AJAX), опрос сервера (polling), потоковое обновление (Server-Sent Events, WebSockets).
Манипуляция DOM: добавление/удаление элементов, изменение атрибутов, динамическая загрузка контента (ленивая подгрузка изображений, пагинация).
Хранение данных на клиенте: localStorage, sessionStorage, IndexedDB — для кэширования, offline-режима, персонализации.
Интеграция с устройством: геолокация, камера, микрофон, push-уведомления (Web Push API).

Критически важно: JavaScript не должен использоваться для обеспечения базовой функциональности. Принцип progressive enhancement требует, чтобы сайт работал на уровне HTML/CSS даже при отключённом JS: формы отправлялись, ссылки вели к цели, контент был доступен. JS лишь улучшает опыт — ускоряет, добавляет анимации, делает интерфейс богаче.

3.2 Серверная часть (Backend)

Backend — это «мозг» веб-сайта: он хранит данные, выполняет правила бизнес-логики, обеспечивает безопасность и масштабируемость. В отличие от frontend, backend недоступен пользователю напрямую — он взаимодействует с клиентом только через чётко определённые интерфейсы (HTTP-запросы, WebSockets).

3.2.1 Веб-сервер

Веб-сервер (Nginx, Apache, Caddy) — это первая точка соприкосновения с внешним миром. Его задачи:

Принимать TCP-соединения и разбирать HTTP-запросы.
Обслуживать статические файлы (изображения, CSS, JS, HTML) с максимальной эффективностью.
Проксировать динамические запросы к приложению (например, location /api/ { proxy_pass http://localhost:3000; } в Nginx).
Обеспечивать TLS-шифрование (HTTPS), сжатие (gzip, Brotli), кэширование.
Ограничивать нагрузку: rate limiting, защита от DDoS.

Важно: веб-сервер не выполняет бизнес-логику. Он — трафик-менеджер. Само приложение (на C#, Java, Python и др.) запускается отдельно (как отдельный процесс или контейнер) и общается с веб-сервером через FastCGI, reverse proxy или напрямую (например, Kestrel в ASP.NET Core может работать standalone).

3.2.2 Прикладная логика

Бэкенд-приложение — это программный код, реализующий функциональность сайта. Его архитектура определяется парадигмой:

Монолит — единый процесс со всеми модулями (авторизация, каталог, оплата). Прост в разработке и деплое, но сложен в масштабировании и сопровождении при росте.
Микросервисы — набор независимых сервисов, каждый со своей БД и API. Позволяет масштабировать отдельные компоненты, использовать разные стеки, но вводит сложность в оркестрации, согласованности данных и мониторинге.
Serverless — логика выносится в функции (AWS Lambda, Azure Functions), запускаемые по событию. Нет управления серверами, оплата за время выполнения, но возможны «холодные старты» и ограничения по времени выполнения.

Независимо от архитектуры, бэкенд решает типовые задачи:

Маршрутизация: сопоставление URL и HTTP-метода с конкретной функцией-обработчиком.
Валидация входных данных: проверка типов, форматов, диапазонов — до попадания в логику.
Авторизация и аутентификация: проверка учётных данных, выдача токенов, управление сессиями.
Работа с БД: выполнение запросов с защитой от инъекций (параметризованные запросы), транзакции, кэширование.
Интеграция с внешними системами: платежные шлюзы, SMS-провайдеры, CRM, федеральные реестры.
Логирование и мониторинг: сбор метрик, трассировка запросов, алертинг.

3.2.3 Базы данных

База данных — это упорядоченное хранилище, обеспечивающее целостность, надёжность и эффективный доступ к данным. Выбор СУБД определяется требованиями:

Реляционные (SQL): PostgreSQL, MySQL, SQL Server. Обеспечивают строгую схему, ACID-транзакции, мощный язык запросов. Идеальны для финансовых операций, учёта, систем с чёткими связями («один ко многим»).
Документные (NoSQL): MongoDB, Firebase Firestore. Хранят данные в виде JSON-подобных документов. Гибкая схема, горизонтальное масштабирование «из коробки». Подходят для контента, логов, персонализированных профилей.
Ключ-значение: Redis, Memcached. Используются в основном как кэш: хранят часто запрашиваемые данные в оперативной памяти для снижения нагрузки на основную БД.
Поисковые: Elasticsearch, Meilisearch. Оптимизированы для full-text search, агрегаций, аналитики.

Важный принцип: не все данные требуют БД. Кэш — в Redis, статические файлы — в объектном хранилище (S3, Yandex Object Storage), логи — в централизованный сборщик (Loki, ELK).

3.2.4 API

API (Application Programming Interface) — это формализованный способ взаимодействия между компонентами. В вебе это, как правило, HTTP-интерфейс с чёткой спецификацией:

REST (Representational State Transfer) — архитектурный стиль, использующий HTTP-методы семантично:
- GET /users — получить список;
- POST /users — создать пользователя;
- GET /users/42 — получить конкретного;
- PUT /users/42 — обновить полностью;
- PATCH /users/42 — обновить частично;
- DELETE /users/42 — удалить.
  Ответы стандартизированы: JSON, статус-коды, заголовки Content-Type, ETag, Link (для пагинации).
GraphQL — язык запросов, позволяющий клиенту самому определять структуру ответа:
```
query {
  user(id: 42) {
    name
    email
    posts(first: 5) { title, createdAt }
  }
}
```
Преимущество — минимизация over-fetching (получения лишних данных). Недостаток — сложность кэширования и защиты от тяжёлых запросов.

API — это не просто техническая деталь. Это юридический и организационный контракт: его изменения требуют согласования, версионирования (/api/v1/...), документирования (OpenAPI/Swagger).

3.3 Элементы веб-страницы

Веб-страница — система интерфейсных элементов, каждый из которых решает конкретную задачу. Удобно классифицировать их по функциональной роли:

3.3.1 Навигационные элементы

Глобальное меню — доступ к основным разделам из любой точки сайта.
Хлебные крошки — отображение иерархии (Главная > Каталог > Электроника > Ноутбуки). Помогает пользователю понять, где он находится, и вернуться на уровень выше.
Поиск — поле ввода с автодополнением, фильтрацией, подсказками. Критичен для крупных сайтов с тысячами страниц.
Ссылки пагинации — переход между страницами списков («1 2 3 … 15» или «Пред. / След.»).

3.3.2 Контентные элементы

Текстовые блоки: заголовки (структурируют), абзацы (основной контент), цитаты, выделения.
Медиа: изображения (с альтернативным текстом alt), видео (встроенные через <video> или iframe), аудио.
Таблицы — для структурированных данных (не для вёрстки макета!).
Списки — нумерованные (алгоритмы, шаги), маркированные (перечисления), вложенные.

3.3.3 Интерактивные элементы

Формы: поля ввода (<input>, <textarea>, <select>), кнопки отправки, чекбоксы, радиокнопки. Требуют валидации (на клиенте — для UX, на сервере — для безопасности).
Кнопки действий: «Купить», «Подписаться», «Редактировать» — триггеры бизнес-процессов.
Виджеты: автономные компоненты с логикой — калькулятор кредита, календарь выбора даты, карта (через API Яндекс.Карт или Google Maps).
Модальные окна — временные панели поверх контента для подтверждения действий, показа деталей.

3.3.4 Технические элементы (невидимые, но критичные)

Метатеги: <meta name="description">, <meta name="viewport">, Open Graph-теги для соцсетей.
Скрипты и стили: подключение внешних ресурсов (<link rel="stylesheet">, <script src="...">).
Структурированные данные: JSON-LD или микроразметка (Schema.org) — помогают поисковикам понять суть контента («это рецепт», «это организация»).
Атрибуты доступности: aria-label, aria-expanded, role="navigation" — для скринридеров.

4. Этапы создания сайта и его состав как сложной системы

4.1 Жизненный цикл сайта

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

4.1.1 Анализ и постановка задач

Этот этап определяет цель и ограничения проекта. Он включает:

Определение целевой аудитории: кто будет пользоваться сайтом? Какие у них устройства, уровень технической подготовки, потребности? (Например, сайт для пенсионеров требует крупного шрифта и минимума интерактивности; для разработчиков — API-документацию и примеры кода).
Формулирование бизнес-целей: информирование, привлечение клиентов, продажи, автоматизация процессов, повышение лояльности. Цели должны быть измеримы (KPI: конверсия, время на сайте, количество регистраций).
Анализ конкурентов и аналогов: какие решения уже существуют? Какие сильные и слабые стороны можно использовать или избежать?
Юридический аудит: какие нормативные акты применимы? (ФЗ-152 «О персональных данных», 187-ФЗ «О безопасности критической информационной инфраструктуры», ГОСТ Р 57700.11-2017 «Доступность веб-контента»).

Результат этапа — техническое задание (ТЗ) или product backlog, содержащее:

Описание пользовательских сценариев (user stories: «Как покупатель, я хочу отфильтровать товары по цене, чтобы быстрее найти подходящий»);
Требования к функционалу, дизайну, производительности, безопасности;
Ограничения по бюджету, срокам, используемым технологиям.

4.1.2 Проектирование

На этом этапе формируется архитектура и интерфейс будущего сайта.

Информационная архитектура (IA) — структура контента:
- Карта сайта (sitemap): иерархия страниц, их взаимосвязи.
- Система навигации: глобальное меню, хлебные крошки, поиск.
- Таксономия: правила категоризации (рубрики, теги, атрибуты).
UX-дизайн (User Experience) — проектирование пользовательских потоков:
- Сценарии использования: последовательность действий для достижения цели («Выбор товара → Добавление в корзину → Оформление заказа → Оплата»).
- Каркасные макеты (wireframes): чёрно-белые схемы расположения элементов без деталей оформления. Проверяют логику, а не эстетику.
- Прототипы: интерактивные макеты (в Figma, Adobe XD), позволяющие «прокликать» основные сценарии до написания кода.
UI-дизайн (User Interface) — визуальное оформление:
- Гайдлайн (style guide): палитра, типографика, компоненты (кнопки, поля ввода), анимации.
- Адаптивные макеты: от мобильного (320px) до десктопного (1920px+) разрешения.
Техническое проектирование:
- Выбор архитектуры (статика, динамика, SPA, гибрид);
- Определение стека технологий (фронтенд, бэкенд, БД, инфраструктура);
- Проектирование API-контрактов (OpenAPI-спецификация);
- Моделирование данных (ER-диаграммы для SQL, документные схемы для NoSQL).

Важно: проектирование — итеративный процесс. Прототипы тестируются с реальными пользователями (юзабилити-тестирование), и на основе фидбэка вносятся правки до начала разработки.

4.1.3 Разработка

Этап реализации проекта по утверждённым спецификациям. Он делится на параллельные потоки:

Frontend-разработка:
- Верстка: превращение макетов в валидный, семантический HTML/CSS.
- Программирование: реализация интерактивности на JavaScript/TypeScript с использованием фреймворков.
- Интеграция API: подключение к бэкенду, обработка ответов, управление состоянием.
Backend-разработка:
- Реализация бизнес-логики: обработка запросов, валидация, транзакции.
- Работа с БД: создание схемы, миграции, оптимизация запросов.
- Настройка инфраструктуры: веб-сервер, reverse proxy, балансировщик нагрузки.
Контент-наполнение:
- Подготовка текстов, изображений, видео в соответствии с ТЗ.
- Структурирование данных (например, загрузка товаров в CSV/JSON для импорта).
- Оптимизация медиа: сжатие изображений (WebP, AVIF), транскодирование видео.

Ключевые практики:

Версионирование кода (Git), ветвление (Git Flow, trunk-based development);
Code review и статический анализ (SonarQube, ESLint);
Автоматизация сборки (Webpack, Vite, MSBuild);
Написание unit- и интеграционных тестов.

4.1.4 Тестирование

Тестирование — непрерывный процесс, интегрированный в разработку. Типы тестирования:

Функциональное: проверка соответствия требованиям (ручное и автоматизированное — Selenium, Cypress).
Юзабилити: наблюдение за реальными пользователями при выполнении задач. Выявляет неочевидные проблемы («Где кнопка «Купить»?»).
Кросс-браузерное и кросс-платформенное: корректность отображения в Chrome, Firefox, Safari, Edge, на iOS, Android, Windows.
Производительности (нагрузочное): проверка устойчивости при высокой нагрузке (JMeter, k6). Измеряются: время отклика, RPS (запросов в секунду), потребление ресурсов.
Безопасности: сканирование на уязвимости (OWASP ZAP, Burp Suite), проверка на XSS, SQLi, CSRF, неправильную настройку CORS.
Доступности (a11y): проверка по стандарту WCAG 2.1 (инструменты: axe, Lighthouse).

Результат — отчёт с дефектами, приоритезированными по критичности. Блокирующие ошибки (например, невозможность оформить заказ) должны быть исправлены до релиза.

4.1.5 Деплой и запуск

Развёртывание сайта в рабочей среде — ответственная операция, требующая планирования:

Подготовка инфраструктуры:
- Выбор хостинга: shared hosting (для статики), VPS (для динамики), облачные сервисы (AWS, Yandex Cloud), serverless-платформы (Vercel, Netlify).
- Настройка DNS: привязка домена к IP-адресу сервера (записи A, CNAME).
- Настройка HTTPS: получение и обновление сертификатов (Let’s Encrypt через certbot или автоматически в облаке).
Процесс деплоя:
- CI/CD-конвейер: автоматическая сборка, тестирование, доставка на сервер (GitHub Actions, GitLab CI, Jenkins).
- Blue/Green deployment или canary-релизы — для минимизации рисков: новая версия запускается параллельно, трафик переключается постепенно.
- Откат: возможность быстрого возврата к предыдущей стабильной версии при сбое.
Запуск:
- Уведомление поисковых систем (sitemap.xml, Google Search Console);
- Настройка аналитики (Яндекс.Метрика, Google Analytics);
- Финальная проверка в продакшене.

4.1.6 Эксплуатация и поддержка

Сайт после запуска не «застывает» — он входит в фазу активного сопровождения:

Мониторинг:
- Доступность (uptime — UptimeRobot, Pingdom);
- Производительность (Lighthouse CI, New Relic);
- Ошибки (Sentry, ELK-стек);
- Безопасность (регулярные сканирования, обновление зависимостей).
Поддержка контента:
- Обновление информации (акции, новости, цены);
- Модерация пользовательского контента (комментарии, отзывы);
- Работа с CMS (если используется): обучение редакторов.
Развитие:
- A/B-тестирование интерфейсов;
- Добавление новых функций по обратной связи;
- Рефакторинг устаревшего кода.
Юридическое сопровождение:
- Обновление политики конфиденциальности при изменении обработки ПДн;
- Публикация пользовательского соглашения;
- Реакция на запросы субъектов ПДн (доступ, удаление).

В конце жизненного цикла — архивация или миграция. Сайт может быть:

Переведён в режим «только чтение» с редиректом на новый проект;
Экспортирован в статический архив (например, через HTTrack);
Полностью закрыт с уведомлением пользователей.

4.2 Состав сайта

Сайт — это совокупность артефактов, распределённых по средам и ответственности:

Категория	Компоненты	Ответственный	Примечание
Исходный код	HTML-шаблоны, CSS, JavaScript, бэкенд-логика, тесты	Разработчики	Хранится в Git, версионируется
Контент	Тексты, изображения, видео, товарные карточки	Контент-менеджеры, редакторы	Часто в CMS или headless-хранилище
Конфигурация	`.env`, `nginx.conf`, `docker-compose.yml`, CI/CD-скрипты	DevOps, архитекторы	Критична для воспроизводимости
Метаданные	`sitemap.xml`, `robots.txt`, Open Graph, JSON-LD	SEO-специалисты, разработчики	Управляют индексацией и внешним видом
Документация	ТЗ, API-спецификации, руководства администратора	Технические писатели, аналитики	Обеспечивает сопровождаемость
Лицензии и юр. документы	Пользовательское соглашение, политика конфиденциальности	Юристы	Обязательны при сборе ПДн

Особо выделим доменное имя — это юридический актив, регистрируемый на физическое/юридическое лицо. Его стоимость, срок регистрации, настройки DNS (записи MX для почты, TXT для верификации) напрямую влияют на работоспособность сайта.

4.3 Функционал

Функциональность сайта формируется иерархически — от must-have к nice-to-have.

4.3.1 Базовый функционал (обязателен для любого сайта)

Навигация: пользователь всегда должен понимать, где он находится и как перейти в другие разделы.
Доступность контента: текст читаем, изображения имеют alt, интерфейс работает без JavaScript на базовом уровне.
Обратная связь: форма «Контакты» или email для связи с владельцем.
Юридическая информация: реквизиты владельца, политика конфиденциальности (при сборе данных).

4.3.2 Расширенный функционал (зависит от типа сайта)

Для информационных ресурсов: поиск, фильтрация, подписка на обновления, социальные кнопки.
Для интернет-магазинов: каталог с фильтрами, корзина, личный кабинет, оплата, доставка, отзывы.
Для SaaS-продуктов: авторизация, управление подпиской, интеграции (API, вебхуки), аналитика использования.
Для сообществ: профили пользователей, лента активности, чаты, уведомления, модерация.

4.3.3 Технический функционал («невидимый», но критичный)

Защита от ботов: reCAPTCHA, rate limiting, анализ поведения.
Кэширование: на уровне CDN, сервера, браузера — для снижения нагрузки и ускорения загрузки.
Логирование и аудит: фиксация действий администраторов, ошибок, доступа к ПДн.
Резервное копирование: регулярное сохранение БД и файлов с проверкой восстановления.

Перспективы развития веб-технологий

5.1 Эволюция сетевого уровня: от HTTP/1.1 к HTTP/3 и QUIC

Производительность веба ограничена клиентским кодом, серверной логикой и фундаментальными свойствами протоколов передачи данных. Исторически HTTP/1.1 страдал от:

Head-of-line blocking: при потере одного пакета TCP все последующие запросы в том же соединении блокировались до повторной передачи.
Ограничения на параллелизм: браузеры открывали не более 6 соединений на домен, что замедляло загрузку страниц с множеством ресурсов.

Решения пришли последовательно:

HTTP/2 (2015): мультиплексирование запросов в одном TCP-соединении, сжатие заголовков (HPACK), server push (предварительная отправка ресурсов). Однако проблема HOL blocking на уровне TCP осталась.
HTTP/3 (2022, RFC 9114): отказ от TCP в пользу QUIC (Quick UDP Internet Connections) — транспортного протокола поверх UDP. QUIC реализует управление потоками, шифрование (TLS 1.3 «из коробки») и контроль перегрузок на уровне приложения. Это устраняет HOL blocking на уровне соединения: потеря пакета в одном потоке не влияет на другие. В 2025 году HTTP/3 поддерживается всеми основными браузерами и CDN (Cloudflare, Google Frontend, Yandex CDN), и его доля в трафике превышает 60%.

Практическое значение: сайты, оптимизированные под HTTP/3, показывают на 15–30% меньшее время до интерактивности (TTI) при нестабильном соединении (мобильные сети, спутниковый интернет). Для разработчика это означает:

Отказ от «хаков» вроде domain sharding (размещения ресурсов на поддоменах для обхода лимита соединений);
Больший вес приобретает оптимизация количества запросов, а не их размера — QUIC эффективен даже для множества мелких запросов.

5.2 Смещение вычислений к границе сети: Edge Computing

Традиционная модель — клиент ↔ origin-сервер — неэффективна при глобальном охвате: запрос из Владивостока к серверу в Москве проходит тысячи километров, накапливая задержку (latency). Edge computing переносит логику ближе к пользователю — на серверы CDN, расположенные в десятках точек присутствия (PoP) по всему миру.

Современные edge-платформы (Cloudflare Workers, Vercel Edge Functions, AWS Lambda@Edge) позволяют выполнять:

Edge-side rendering: генерация HTML на ближайшем узле CDN. Это сочетает преимущества SSR (SEO, скорость FCP) и CDN (низкая задержка).
A/B-тестирование и персонализацию: выбор варианта интерфейса на основе геолокации, устройства, cookies — без задержки на round-trip до origin.
Безопасность: WAF-правила (защита от DDoS, SQLi), rate limiting, геоблокировка — на уровне edge, до попадания трафика в приложение.
API-агрегацию: объединение данных из нескольких источников (внутренних и внешних) за один запрос к клиенту.

Ограничения: время выполнения функции ограничено (обычно 5–30 мс), объём памяти — 128–512 МБ, отсутствует долгоживущее состояние. Но для задач маршрутизации, модификации заголовков, простой обработки — этого достаточно. Тенденция ясна: origin-сервер становится хранилищем данных и тяжёлой логики, а edge — слоем оркестрации и адаптации.

5.3 Веб как полноценная платформа приложений

Раньше веб считался «облегчённой» альтернативой нативным приложениям. Сегодня эта граница стирается благодаря трём технологиям:

5.3.1 Progressive Web Apps (PWA)

PWA — набор практик, позволяющих веб-приложению вести себя как нативное:

Работа в оффлайне: Service Worker перехватывает сетевые запросы и отдаёт закэшированный контент.
Установка на устройство: manifest-файл (manifest.json) позволяет добавить ярлык на домашний экран с собственным иконкой и splash screen.
Push-уведомления: через Web Push API и сервис-воркер, даже при закрытом браузере.
Доступ к устройству: геолокация, камера, Bluetooth (Web Bluetooth API), USB (WebUSB — для специализированных задач).

Ключевое преимущество: единый код для всех платформ, мгновенное обновление (без app store review), низкий порог входа («посетил — установил»). Примеры: Twitter Lite, Starbucks, Pinterest — все они заменили или дополнили нативные приложения PWA с сопоставимой производительностью.

5.3.2 WebAssembly (Wasm)

JavaScript — высокоуровневый, динамически типизированный язык. Для вычислительно тяжёлых задач (видеокодеки, игры, CAD, ML-инференс) он неэффективен. WebAssembly — бинарный формат низкоуровневого кода, исполняемый в браузере со скоростью, близкой к нативной.

Как это работает:

Алгоритм пишется на языке с низким уровнем контроля (C/C++, Rust).
Компилируется в .wasm-модуль.
Модуль загружается в браузер и выполняется в изолированной песочнице.
JavaScript вызывает функции Wasm, передавая данные через shared memory.

Сценарии применения:

Фоторедакторы (Figma использует Wasm для рендеринга векторной графики);
Игры (Doom 3, Unity-проекты);
Шифрование (в клиентской части для end-to-end security);
Научные вычисления (биоинформатика, симуляции).

5.3.3 WebGPU и новые API для медиа

Для доступа к GPU ранее использовался WebGL (основан на OpenGL ES). WebGPU — новый стандарт, предоставляющий более низкоуровневый, эффективный и безопасный доступ к графическим и вычислительным возможностям GPU. Он поддерживает:

Параллельные вычисления (GPGPU) для ML, физических симуляций;
Современные шейдеры (WGSL — WebGPU Shading Language);
Эффективное управление памятью и синхронизацией.

Сочетание WebGPU + Wasm открывает путь к:

Браузерным CAD- и 3D-редакторам промышленного уровня;
Онлайн-рендерингу фильмов и игр;
Клиентскому ML-инференсу (например, распознавание объектов в реальном времени без отправки данных на сервер — повышает приватность).

5.4 Этические и регуляторные вызовы

Технологический прогресс сопровождается ростом ответственности. Веб-разработка больше не ограничивается «сделай и запусти».

5.4.1 Приватность и регулирование

Снижение поддержки third-party cookies: Safari и Firefox уже блокируют их по умолчанию; Chrome завершит поддержку в 2024–2025. Это вынуждает пересматривать модели аналитики и таргетинга — в пользу first-party данных, контекстной рекламы, Privacy Sandbox API (Topics, FLEDGE).
Согласие на обработку ПДн: требования GDPR, CCPA, ФЗ-152 обязывают получать явное, информированное согласие перед загрузкой скриптов аналитики, чатов, карт. Это ведёт к распространению consent management platforms (CMP) и «ленивой» загрузке сторонних виджетов.
Ответственность за контент: DSA (Digital Services Act) в ЕС и аналогичные инициативы в других странах требуют от платформ (включая крупные сайты) модерации незаконного контента, прозрачности алгоритмов рекомендаций.

5.4.2 Доступность как норма, а не опция

WCAG 2.2 (2023) вводит новые критерии:

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

Доступность перестаёт быть «галочкой для госзаказов» — это требование рынка: 16% населения мира имеют инвалидность, и игнорирование их — потеря аудитории и репутационные риски.

5.4.3 Экологичность (Green Web)

Веб-инфраструктура потребляет ~2% мировой электроэнергии — сопоставимо с авиацией. Оптимизация ради скорости теперь идёт в паре с оптимизацией ради эффективности:

Энергоэффективный код: минимизация перерисовок, отказ от «тяжёлых» анимаций на слабых устройствах.
Адаптивная доставка: отправка изображений в формате AVIF/WebP с учётом поддержки браузера; динамическое качество видео по скорости сети.
Учёт времени суток: в регионах с «зелёной» энергетикой (ветер, солнце) можно планировать тяжёлые задачи (рендеринг, резервное копирование) на дневные часы.

Инструменты: Website Carbon Calculator, EcoPing, Green Web Foundation API.

Сайт и веб-сайт​

1. Сущность и принципы функционирования​

1.1 Что такое «сайт»​

1.2 Клиент-серверная модель​

1.3 Сайт как информационная система​

2. Классификация сайтов​

2.1 Статические сайты​

2.2 Динамические сайты​

2.3 Веб-приложения (Web Applications, SPA)​

2.4 Гибридные архитектуры​

3. Структура сайта​

3.1 Клиентская часть (Frontend)​

3.1.1 HTML​

3.1.2 CSS​

3.1.3 JavaScript​

3.2 Серверная часть (Backend)​

3.2.1 Веб-сервер​

3.2.2 Прикладная логика​

3.2.3 Базы данных​

3.2.4 API​

3.3 Элементы веб-страницы​

3.3.1 Навигационные элементы​

3.3.2 Контентные элементы​

3.3.3 Интерактивные элементы​

3.3.4 Технические элементы (невидимые, но критичные)​

4. Этапы создания сайта и его состав как сложной системы​

4.1 Жизненный цикл сайта​

4.1.1 Анализ и постановка задач​

4.1.2 Проектирование​

4.1.3 Разработка​

4.1.4 Тестирование​

4.1.5 Деплой и запуск​

4.1.6 Эксплуатация и поддержка​

4.2 Состав сайта​

4.3 Функционал​

4.3.1 Базовый функционал (обязателен для любого сайта)​

4.3.2 Расширенный функционал (зависит от типа сайта)​

4.3.3 Технический функционал («невидимый», но критичный)​

Перспективы развития веб-технологий​

5.1 Эволюция сетевого уровня: от HTTP/1.1 к HTTP/3 и QUIC​

5.2 Смещение вычислений к границе сети: Edge Computing​

5.3 Веб как полноценная платформа приложений​

5.3.1 Progressive Web Apps (PWA)​

5.3.2 WebAssembly (Wasm)​

5.3.3 WebGPU и новые API для медиа​

5.4 Этические и регуляторные вызовы​

5.4.1 Приватность и регулирование​

5.4.2 Доступность как норма, а не опция​

5.4.3 Экологичность (Green Web)​

Сайт и веб-сайт

1. Сущность и принципы функционирования

1.1 Что такое «сайт»

1.2 Клиент-серверная модель

1.3 Сайт как информационная система

2. Классификация сайтов

2.1 Статические сайты

2.2 Динамические сайты

2.3 Веб-приложения (Web Applications, SPA)

2.4 Гибридные архитектуры

3. Структура сайта

3.1 Клиентская часть (Frontend)

3.1.1 HTML

3.1.2 CSS

3.1.3 JavaScript

3.2 Серверная часть (Backend)

3.2.1 Веб-сервер

3.2.2 Прикладная логика

3.2.3 Базы данных

3.2.4 API

3.3 Элементы веб-страницы

3.3.1 Навигационные элементы

3.3.2 Контентные элементы

3.3.3 Интерактивные элементы

3.3.4 Технические элементы (невидимые, но критичные)

4. Этапы создания сайта и его состав как сложной системы

4.1 Жизненный цикл сайта

4.1.1 Анализ и постановка задач

4.1.2 Проектирование

4.1.3 Разработка

4.1.4 Тестирование

4.1.5 Деплой и запуск

4.1.6 Эксплуатация и поддержка

4.2 Состав сайта

4.3 Функционал

4.3.1 Базовый функционал (обязателен для любого сайта)

4.3.2 Расширенный функционал (зависит от типа сайта)

4.3.3 Технический функционал («невидимый», но критичный)

Перспективы развития веб-технологий

5.1 Эволюция сетевого уровня: от HTTP/1.1 к HTTP/3 и QUIC

5.2 Смещение вычислений к границе сети: Edge Computing

5.3 Веб как полноценная платформа приложений

5.3.1 Progressive Web Apps (PWA)

5.3.2 WebAssembly (Wasm)

5.3.3 WebGPU и новые API для медиа

5.4 Этические и регуляторные вызовы

5.4.1 Приватность и регулирование

5.4.2 Доступность как норма, а не опция

5.4.3 Экологичность (Green Web)