Одностраничные (spa) и многостраничные (pwa) веб-приложения — SEO на vc.ru

Чем отличаются веб-приложения MPA, SPA и PWA, для каких задач подходят. Разбор преимуществ, недостатков и отличий методов разработки.

36 530
просмотров

Существует три основных подхода к разработке веб-приложений: одностраничные (SPA), многостраничные (MPA) и прогрессивные (PWA). Они выделяются среди других подходов простотой разработки, удобством для пользователей и широкими возможностями для развития бизнеса.

Рассказываем, чем отличаются компоненты MPA, SPA и PWA, какие у них преимущества и недостатки, что из них выбрать и для каких задач.

Одностраничные приложения

SPA или Single Page Application — это одностраничное веб-приложение, которое загружается на одну HTML-страницу. Благодаря динамическому обновлению с помощью JavaScript, во время использования не нужно перезагружать или подгружать дополнительные страницы. На практике это означает, что пользователь видит в браузере весь основной контент, а при прокрутке или переходах на другие страницы, вместо полной перезагрузки нужные элементы просто подгружаются.

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

Такого эффекта удается добиться с помощью продвинутых фреймворков JavaScript: Angular, React, Ember, Meteor, Knockout.

Примеры динамических приложений: Gmail, Google Maps, Facebok, GitHub, Meduza.

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

• Высокая скорость — все ресурсы загружаются за одну сессию, а во время действий на странице данные просто меняются, что очень экономит время;
• гибкость и отзывчивость пользовательского интерфейса — за счет того, что веб-страница всего одна, проще построить насыщенный интерфейс, хранить сведения о сеансе, управлять состояниями представлений и анимацией;
• упрощенная разработка — код можно начинать писать с файла file://URL, не используя сервер, не нужен отдельный код для рендера страницы на стороне сервера;
• кэширование данных — приложение отправляет всего один запрос, собирает данные, а после этого может функционировать в offline-режиме.

Недостатки

• Seo оптимизация требует решений в виде серверного рендеринга — из-за того, что контент загружается при помощи технологии AJAX, которая подразумевает динамическое изменение содержания станицы, а для оптимизации важна устойчивость;
• нагрузка на браузер — из-за того, что клиентские фреймворки тяжелые, они довольно долго загружаются;
• необходима поддержка JavaScript — без JS нельзя полноценно пользоваться полным функционалом приложения;
• утечка памяти в Java Script — из-за плохой защиты, SPA больше подвержена действиям злоумышленников и утечке памяти.

Многостраничные приложения

MPA или Multi Page Application — это многостраничные приложения, которые работают по традиционной схеме. Это означает, что при каждом незначительном изменении данных или загрузке новой информации страница обновляется. Такие приложения тяжелее, чем одностраничные, поэтому их использование целесообразно только в тех случаях, когда нужно отобразить большое количество контента.

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

• Простая SEO оптимизация — можно оптимизировать каждую из страниц приложения под нужные ключевые запросы;
• привычность для пользователей — за счет простого интерфейса и классической навигации.

Недостатки

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

• сложная разработка — требуют использования фреймворков как на стороне клиента, так и на стороне сервера, что увеличивает сроки и бюджет разработки.

SPA и MPA. Что выбрать?

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

Выбор SPA

Целесообразен, если:

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

Выбор MPA

Целесообразен, если:

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

Зачем нужны PWA

Прогрессивные приложения или Progressive Web Application взаимодействуют с пользователем, как приложение. Они могут устанавливаться на главный экран смартфона, отправлять push-уведомления и работать в офлайн-режиме.

Пример: Google Docs.

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

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

Недостатки

Не все браузеры поддерживают основные функции таких приложений (например, Firefox и Edge).

Итог

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

Single Page Application в облачном хранилище / Хабр

Мы уже писали о том, как наше облачное хранилище может быть использовано в качестве площадки для размещения статических сайтов (1 и 2). Сегодня мы расскажем о том, как на базе хранилища можно размещать современные cайты, в основе которых лежит популярный и актуальный в наши дни подход Single Page Application (SPA).

SPA как подход

Аббревиатура SPA расшифровывается как «single page application» («одностраничное приложение»). В узком смысле она употребляется для обозначения одностраничного сайта, непосредственно выполняемого на стороне клиента в браузере. В более широком смысле SPA (иногда также употребляется аббревиатура SPI — «single page interface») означает целый подход в веб-разработке, который в наши дни получает все более широкое распространение. В чем заключается смысл этого подхода и почему он становится всё более популярным?

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

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

Часто описанные проблемы решаются так: страницы всё ещё генерируются на стороне сервера, но на стороне клиента выполняются небольшие JavaScript-сценарии, с помощью которых можно, например, выполнить валидацию формы до того, как она будет отправлена на сервер. Решение на первый взгляд неплохое, но и у него есть недостатки:

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

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

С точки зрения этого подхода сайт понимается не как набор страниц, а как набор состояний одной и той же HTML-страницы. При смене состояния происходит асинхронная подгрузка нового контента без перезагрузки самой страницы.

SPA представляет собой не сайт в классическом понимании, а приложение, которое исполняется на стороне клиента, в браузере. Поэтому с точки зрения пользователя проблем со скоростью работы почти не бывает даже при медленном или нестабильном соединении с Интернетом (например, при просмотре сайта с мобильного устройства). Высокая скорость работы обеспечивается ещё и благодаря тому, что с сервера на клиента приходит теперь не разметка, а данные (в основном в формате JSON), и размер их невелик.

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

BAAS (Backend as a Service)

Технологии, позволяющие отрисовывать интерфейс на стороне клиента и взаимодействовать с сервером только путём отправки запросов без перезагрузки страницы, существуют уже давно. Например, API XMLHttpRequest появился ещё в 2000 году. Но использование этих технологий было сопряжено с трудностями: нужно было переписывать бэкенд, реализующий функции авторизации запросов и доступа к данным.

Сегодня всё стало намного проще благодаря появлению многочисленных BaaS-сервисов. Аббревиатура BaaS означает Backend as a Service. BaaS-сервисы предоставляют разработчикам веб-приложений готовую серверную инфраструктуру (расположенную, как правило, в облаке). Благодаря им можно сэкономить время (а зачастую ещё и деньги) на написание серверного кода и сосредоточиться на совершенствовании самого приложения и развития его функциональности. С помощью BaaS можно подключать к приложению или сайту любой бэкенд с любым набором функций — достаточно просто добавить на страницу соответствующую библиотеку.

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

Ещё один интересный пример — FireBase. Этот сервис представляет собой облачную базу данных и API для realtime-приложений. С его помощью можно, в частности, организовать обмен данными между клиентом и сервером в режиме реального времени: достаточно просто подключить на страницу JavaScript-библиотеку и настроить события на изменения данных. На основе FireBase легко реализовать, например, чат или ленту пользовательской активности.

В числе интересных и заслуживающих внимания BaaS-сервисов стоит также выделить:

• Backendless — платформа, предоставляющая готовую облачную серверную инфраструктуру для всех типов приложений. С её помощью на сайт можно добавить функциональность управления пользователями, хранения пользовательских данных, обмен сообщениями в режиме реального времени, рассылка уведомлений, геолокацию, управление файлами и много другое.
• Syncano — сервис, предоставляющий API для real-time приложений, близкий по функциональности к Firebase.
• QuickBlox — небезынтересный продукт от российских разработчиков (см. также подробную статью на Хабре).

С кратким обзором ВааS-сервисов можно также ознакомиться здесь.

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

При использовании хранилища в качестве внешнего бэкенда следует обратить особое внимание на два ключевых момента: аутентификация и работа с контентом. Ключ аутентификации (токен) можно получить с помощью запроса к auth.selcdn.ru.

Затем его нужно будет указывать в качестве значения заголовка X-Auth-Token во всех запросах работы с данными. Ответы на эти запросы будут включать заголовок Access-Control-Allow-Origin со значением «*», дающий возможность обращаться к хранилищу с любого внешнего домена.

В качестве примера веб-приложения, использующего API хранилища, можно привести нашу фотогалерею (о ней мы уже писали; см. также репозиторий на GitHub).

HTML5 History API

Каждая страница динамического сайта имеет cобственный URL. SPA же устроены так, что в них можно изменять состояние страницы, не изменяя при этом URL. Но в таком случае возникает проблема: пользователь не сможет сохранить ссылку и затем вернуться к посещённому ранее разделу. Решить её можно несколькими способами.

Во-первых, можно использовать хэш-фрагмент (часть ссылки, которая идёт после символа «#»). В хэш-фрагмент помещается «виртуальный» адрес страницы, по которому можно восстановить прежнее состояние. Если пользователь перезагрузит страницу, то код на JavaScript, прочитав значение хэша, загрузит нужные данные и отобразит соответствующий ему раздел. Этот вариант используется на многих сайтах, но следует отметить, что подобные URL (например, «example.com/base/#!/section1/page2») выглядят не очень естественно. Кроме того, они состоят из двух сущностей: «реальный» адрес, по которому страница запрашивается у веб-сервера и «виртуальный», который обозначает логический раздел.

Во-вторых, можно воспользоваться HTML5 History API (см. также статью на Хабре). History API позволяет полностью изменять URL страницы в пределах текущего домена без её перезагрузки. В браузерах, поддерживающих этот API, нет никаких отличий между URL, использованных при загрузке страницы и URL, заданным из JavaScript.

Вызовы функций History API также связаны с нативными браузерными кнопками «Вперёд» и «Назад» и историей: при нажатии кнопки «Назад» браузер вызовет событие popstate, которое можно обработать в JavaScript-коде и отобразить предыдущий раздел. Посмотреть, как это работает, можно, например, здесь.

Чтобы сайт использовал описанную схему URL, нужно соответствующим образом настроить веб-сервер. Необходимо сделать так, чтобы вместо несуществующих страниц отдавалась главная страница SPA — обычно это index.html. В этом случае браузер клиента загрузит JavaScript, который уже отрисует нужный файл сайта исходя из текущего адреса страницы.

В настройках nginx это прописывается так:

location / { rewrite .* /index.html; }

Если SPA размещается на сервисах типа GitHub Pages или нашего хранилища, то настройки нужно устанавливать через панель управления.

Поисковая оптимизация

Индексация SPA поисковыми системами представляет собой отдельную проблему. Если сайт полностью генерируется на стороне клиента, то индексироваться он будет плохо, хотя в последнее время и наблюдаются улучшения в этом плане: боты постепенно начинают выполнять JavaScript при индексировании.

Одним из способов решения этой проблемы заключается в следующем: генерируются снапшоты страниц специально для ботов. Генерировать страницы следует по-разному в зависимости от того, используется ли HTML5 History API или нет.

В случае использования хэш-фрагментов Google и Yandex предлагают один и тот же подход: для разделения «реального» и «виртуального» адресов следует использовать «#!» вместо «#»; поисковые боты, увидев ссылку с таким разделителем, будут использовать специальный query-параметр «_escaped_fragment_» в URL и помещать в него часть адреса, следующую после после хэша.

Веб-сервер должен специальным образом обрабатывать такие запросы и отдавать полноценные HTML-страницы, чтобы боты могли их проиндексировать. (Потребность в этом возникает вследствие того, что часть URL после «#» по стандарту не является часть HTTP-запроса.) Рекомендуется также использовать специальный метатег (см. по ссылкам выше) т.к. некоторые страницы могут не содержать ссылок с «#!».

Если же для адресации используются полноценные URL, то сделать сайт индексируемым ещё проще: достаточно генерировать соответствующую заданному адресу страницу на сервере. Бот, посетив сайт, получит страницу c содержимым и успешно её проиндексирует.

Если сайт открыт в браузере, то страница сначала будет отображена в соответствии с HTML-разметкой, а затем уже в дело вступит JavaScript; при дальнейших переходах по ссылкам страница перезагружаться не будет. Такое поведение можно реализовать, перехватывая события нажатия на ссылки и отменяя их нативное поведение. В таком случае, бот перейдет по ссылке (атрибут «href»), а мы сможем контролировать все переходы, обрабатывая событие так, как нам нужно.

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

Как сгенерировать HTML-страницу, имея в наличии только JavaScript-код, работающий напрямую с DOM? Это можно сделать несколькими способами.

Во-первых, можно установить PhantomJS (это так называемый «headless» браузер на основе WebKit, управляемый через API) и настроить его на генерацию снапшотов страниц (см. практический пример здесь).

Во-вторых, можно воспользоваться инструментом prerender или сервисом Prerenderer.io, которые основаны также на PhantomJS.

В-третьих, в некоторых современных фреймворках (например, DerbyJS и React) эта функция уже реализована (см. также пример здесь: react-server-example).

Размещение SPA

В современном Интернете есть немало площадок, на которых можно размещать SPA. Рассмотрим наиболее популярные из них.

Dropbox

Самый простой вариант — размещение SPA в Dropbox. Для этого нужно создать в публичном каталоге Dropbox каталог для SPA, поместить в него все необходимые файлы, а затем выделить файл index.html и вызвать контекстное меню, нажав на правую кнопку мыши. В меню нужно выбрать пункт «Dropbox → Поделиться ссылкой». После этого будет создана ссылка и скопирована скопирована в буфер обмена, по которой приложение будет доступно через браузер.

В последнее время предпринимаются попытки расширить возможности по размещению сайтов в Dropbox (об этом можно почитать, например, здесь). Однако главной проблемы они не решают: в Dropbox имеются довольно жёсткие (вплоть до полной блокировки) ограничения трафика по публичным ссылкам. Поэтому описываемый вариант можно рекомендовать разве что для демонстрации SPA друзьям и коллегам.

GitHub Pages

GitHub Pages представляет собой бесплатную площадку для размещения статических сайтов и SPA. Чтобы разместить SPA на GitHub Pages, нужно создать для него репозиторий на GitHub и поместить статические файлы в ветку gh-pages для Project Pages или в ветку master для User/Organization Pages. Все вносимые изменения нужно будет коммитить в этот репозиторий. Более подробная справка доступна в официальной документации.

Bit Balloon

Bit Balloon — сервис новый, но уже достаточно популярный.

Каждому зарегистрированному пользователю бесплатно предоставляется 10 Мб дискового пространства. Чтобы разместить на нём SPA, достаточно просто загрузить все необходимые файлы. Сервис автоматически минифицирует JS, HTML и CSS, а также подключит CDN.

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

Selectel Storage

Наше облачное хранилище представляет собой удобную площадку для хостинга SPA. В целом процедура размещения SPA почти не отличается от процедуры размещения статических сайтов о которой мы уже писали в одном из предыдущих постов. Она включает следующие шаги:

1. Создание публичного контейнера и прикрепление домена: по ссылке выше всё подробно описано, подробно на этом останавливаться не будем.
2. Настройка специальных страниц: процедура настройки совсем недавно была нами усовершенствована. Мы добавили ещё один вариант настройки обработки несуществующих страниц («Ошибка 404: страница»). Теперь можно указывать файл, который будет отображен при запросе несуществующей страницы, а также задавать для него код ответа (200 или 404), при этом перенаправления на другой URL не будет:

Это позволяет использовать полноценные URL (см. раздел о History API).

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

Заключение

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

Если вы уже используете наше хранилище для размещения SPA, поделитесь своим опытом и впечатлениями. Все ваши пожелания и предложения будут обязательно учтены в дальнейшей работе.

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

Динамические, SPA и статические веб-сайты

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

Но как возвращаемый HTML-код попадает на сервер? Генерируется ли он «на лету» (по запросу)? Является ли он «предварительно сгенерированным» (т. е. загружены ли готовые HTML-страницы на сервер)?

Оказывается, есть три основных варианта рендеринга веб-сайтов (и требуемого HTML-кода):

#1. Динамические страницы

HTML-страницы создаются динамически, на сервере — с помощью серверного языка программирования и, как правило, также «механизма шаблонов»

Подробнее

#2.

Одностраничные приложения

Сервер возвращает одну предварительно сгенерированную HTML-страницу, которая, в свою очередь, содержит код JavaScript, который динамически изменяет страницу в браузере (такой подход известен как «Одностраничное приложение» 9).0012 или «СПА» )

Подробнее

#3. Статические страницы

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

Узнать больше

Связанные премиум-курсы

• Изучение Node.js от А до Я

  Node.js — один из самых важных языков программирования, которые вы можете изучать прямо сейчас. Не пропустите в 2019 годуи не только!

• Погрузитесь в React.js

  Работаете над пользовательским интерфейсом? React.js является обязательным для изучения в 2019 году и в последующие годы!

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

Особенно современные веб-сайты и веб-службы (например, Netflix, Twitter) используют эти новые подходы.

Но давайте сделаем шаг назад: что такое «Динамические веб-сайты»?

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

Рассмотрим свой профиль пользователя на amazon.com.

Он включает в себя личные данные, такие как ваше имя и историю заказов. Очевидно, что Amazon не пишет HTML-код для этой страницы вручную. Тем не менее, если вы просмотрите исходный HTML-код этой страницы, вы найдете там свои личные данные.

Это означает, что HTML-код был динамически сгенерирован на сервере с помощью используемого там серверного языка.

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

Для этого можно использовать серверные языки, такие как Node.js, обычно в сочетании со специальными расширениями, упрощающими динамическое создание HTML-кода. Эти расширения также называются «движками шаблонов».

Если вам интересно: наш полный курс Node.js не только обучает Node от А до Я, но также включает раздел о механизмах шаблонов и о том, как отображать динамические веб-страницы.

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

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

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

Кроме того, еще одним недостатком может быть то, что разработчикам, создающим динамические страницы, нужны знания как для внешнего интерфейса (HTML + CSS + JS), так и для внутреннего интерфейса. По крайней мере, в определенной степени. Работа по развязке и разделению, безусловно, возможна, но зависимость немного выше.

Одностраничные приложения (SPA) представляют собой другую крайность: в них все генерирование HTML происходит в браузере. Сервер возвращает только одну базовую HTML-страницу для всех входящих запросов (независимо от URL).

Но эта единственная HTML-страница содержит много кода JavaScript (обычно выделенного в отдельные файлы), который отвечает за изменение кода HTML (технически DOM).

Поначалу это звучит странно, правда?

Разве сервер не извлек данные из базы данных для последующего создания HTML-кода? Клиент (браузер) теперь делает это (подключается к базе данных)?

Важно понимать, что в SPA по-прежнему задействован сервер. Ваш код JavaScript на стороне клиента будет , а не подключаются к базе данных. Это было бы очень небезопасно, поскольку учетные данные доступа были бы раскрыты. Вы не можете скрыть свой внешний код JavaScript!.

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

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

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

React.js, Angular или Vue.js — самые популярные варианты.

Разработка СПА кажется вам интересной? Помимо трех рамочных курсов, связанных в предыдущем абзаце, вы также можете ознакомиться с моим подробным сравнением трех альтернатив!

SPA находятся на подъеме, потому что они обеспечивают удивительное и быстрое взаимодействие с пользователем.

Но обработка всех обновлений пользовательского интерфейса и рендеринг контента в браузере также имеет свои недостатки.

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

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

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

Помимо «проблемы» SEO, стоит также упомянуть, что увеличение объема работы в браузере также означает необходимость загрузки дополнительного кода JavaScript . И весь этот код должен быть проанализирован + выполнен, что, конечно же, влияет на производительность веб-сайта во время выполнения.

Таким образом, на более медленных устройствах и/или в более медленных сетях SPA может очень долго загружаться или ощущаться «зависающим».

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

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

А теперь самое интересное: даже страницы с динамическим содержимым можно преобразовать в статические страницы. Эта страница (academind.com) является примером — на самом деле это статическая страница.

Как это работает? Пишем ли мы весь HTML-код для всех наших страниц вручную? Мы копируем и вставляем код со страницы на страницу?

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

Вместо этого мы используем генератор статических сайтов, если быть точным, мы используем Gatsby.js.

#Как это работает?

Генератор статических сайтов позволяет вам определять контент в упрощенной форме — часто в виде документа с уценкой.

Например, вот как выглядел черновик статьи, которую вы сейчас читаете:

Затем генератор статического сайта берет этот контент и преобразует его в код HTML + CSS в соответствии с вашими инструкциями.

Каждый генератор работает по-своему, Gatsby. js на самом деле использует приложение React, которое он в основном создает локально, а затем «посещает» каждую страницу, которая существует в SPA. Снимки этих страниц затем сохраняются в виде HTML-файлов — и это окончательный результат. Куча HTML-файлов, которые обычно генерируются React в браузере.

Затем мы просто загружаем эти файлы HTML на наш сервер.

#К чему все эти хлопоты?

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

Но лучше всего то, что некоторые статические страницы (включая эту) после загрузки превращаются в SPA.

Таким образом, вы получаете все преимущества SPA (быстрые обновления, мгновенные изменения), как только пользователь загрузит первую страницу. Но для этой первой страницы вы получаете преимущества статической или динамической веб-страницы. Довольно мило! 🙂

Итак… статическая страница (созданная с помощью генератора статических сайтов, который также дает SPA) лучше всего, верно?

Нет, это не так просто!

Нет лучшего или худшего подхода!

Все подходы могут быть хороши — это зависит от того, что вы строите.

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

A SPA в целом часто является достойным выбором — он особенно хорош для веб-приложений, которые на самом деле не нуждаются в сканировании поисковыми системами.

Вы всегда можете создать свои целевые страницы (которые должны быть найдены) удобным для SEO способом (например, статические страницы) и создать остальную часть приложения как SPA.

Прекрасная реактивность и UX делают SPA отличным выбором для таких браузерных приложений, как Google Docs, лента Twitter или Netflix.

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

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

Для всех трех типов веб-сайтов изучение Node.js с помощью нашего полного курса является хорошей отправной точкой. Поскольку он использует JavaScript, вы также получаете отличную синергию с интерфейсными фреймворками и библиотеками, такими как React.js, Angular или Vue.js.

Почему и когда следует выбирать SPA вместо статического веб-сайта

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

Введение в одностраничные приложения (SPA)

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

В более традиционной архитектуре веб-страниц страница index.html может ссылаться на другие html-страницы на сервере, которые браузер загружает и отображает с нуля.

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

Кроме того, API истории HTML5 позволяет нам изменять URL-адрес страницы без перезагрузки страницы, что позволяет нам создавать отдельные URL-адреса для разных представлений.

Как динамически обновлять содержимое?

Находясь внутри SPA, приложение может динамически получать содержимое с сервера с помощью запросов AJAX или веб-сокетов.

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

Если вы когда-либо запускали поисковый запрос и во время ввода под формой ввода появлялись промежуточные результаты, значит, вы были свидетелем динамических запросов, происходящих в фоновом режиме, которые обновляли эти элементы DOM.

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

Чтобы привести пример подхода SPA в действии по сравнению с традиционным подходом, на панели слева мы вставляем iframe с традиционным подходом HTML-страницы, а справа мы вставляем панель с тем же содержимым, которое динамически обслуживается путем объединения наше приложение JavaScript с HTML и CSS, необходимыми для отображения элементов страницы.

Попробуйте перейти по разным ссылкам на каждом из них.

Вы заметите, что новый контент справа отображается, как только на него нажимают, в то время как контент слева требует извлечения html и перезагрузки в браузере.

Живой пример статического веб-сайта

Пример SPA в реальном времени

Отлично, не нужно перезагружать страницу!

Но мы должны пожертвовать временем загрузки, требуя, чтобы браузер нашего посетителя загрузил и интерпретировал JavaScript, прежде чем показывать что-либо на странице, верно?

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

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

Это обеспечивает лучшее из обоих миров: быстрое время начальной загрузки и быстрое обновление страницы или «перезагрузку».

Когда использовать одностраничное приложение, а когда нет?

Когда следует рассмотреть возможность использования одностраничного приложения?

Во-первых, если вы хотите более богатого взаимодействия между пользователем и вашим приложением, SPA почти необходим.

Такие приложения, как Google Maps, широко используют этот подход для предоставления изменений в представлении в реальном времени при прокрутке от одного места к другому или щелчке маркеров места для просмотра фотографий определенного места.

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

Стоит ли вообще избегать использования СПА?

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

This entry was posted in Популярное