что такое single page application
Что такое SPA или одностраничный портал
В этой статье речь пойдет о Single Page Application (SPA). Будут рассмотрены плюсы и минусы web-приложения построенного по принципам одностраничного сайта (SPA)
Что такое SPA
Single Page Application – сокращенно SPA, в переводе на русский язык означает “Приложение одной страницы”. Другими словами SPA – это web-приложение, размещенное на одной web-странице, которая для обеспечения работы загружает весь необходимый код вместе с загрузкой самой страницы. Приложение такого типа появились сравнительно недавно, с началом эры HTML5 и SPA является типичным представителем приложений на HTML5.
Если приложение достаточно сложное и содержит богатый функционал, как например, система электронного документооборота, то количество файлов со скриптами может достигать нескольких сотен, а то и тысяч. А “…загрузка всех скриптов…” никоим образом не означает, что при загрузке сайта будут загружены сразу все сотни и тысячи файлов со скриптами. Для решения проблемы загрузки большого количества скриптов в SPA призван API под названием AMD. AMD реализует возможность загрузки скриптов по требованию. То есть, если для “главной станицы” одностраничного портала потребовалось 3 скрипта, они будут загружены стразу перед стартом программы. А если пользователь кликнул на другую страницу одностраничного портала, например, “О программе”, то принцип AMD загрузит модуль (скрипт + разметка) только перед тем как перейти на эту страницу.
Получается немного скомкано: “Одна страница.. другая станица, третья страница… одностраничный портал”. Расставим все точки над “Ё”. Страница сайта, на котором размещены все ссылки на все CSS, и ссылки на скрипты, необходимые для работы SPA мы назовем “Web-страница”. Файл с такой странице обычно называется “index.html” (в ASP.NET MVC может быть index.cshtml или index.vbhtml или даже index.aspx) А страницы, которые переключает пользователь внутри одностраничного портала назовем “модули”.
Давайте рассмотрим плюсы и минуты данного подхода. Зачем всё это нужно и почему SPA так популярен?
SPA: Плюсы
SPA: Минусы
Если вы программируете на C#, то единственным минусом SPA является необходимость изучения JavaScript. Во всяком случае, других глобальных проблем мне выяснить не удалось.
Составляющие SPA
Принципы любого фреймворка (о них поговорим позже), который реализует парадигму SPA должны придерживаться следующих понятий и определений:
Шаблоны SPA (SPA templates)
Как вы уже наверное догадались, SPA – это абстрактное понятие. Это принцип архитектуры приложения. Давайте поговорим с чего начать при разработке сайта по принципам SPA.
Существует большое количество базовых библиотек (фреймворк – от английского слова framework – “основа, структура, каркас”), которые реализуют принцип Single Page Application. Что дают эти фреймворки:
Так как я уже много лет работаю на платформе NET, то я буду рассматривать шаблоны Single Page Application на основе ASP.NET. Давайте рассмотрим следующую сравнительную таблицу.
Сравнение возможностей шаблонов SPA
В таблице приведены наиболее распространённые шаблоны для как основа построения Single Page Application приложения. Обратите внимание, синим фоном выделены базовые кирпичики для построения полноценного фреймворка, таких как DurandalJS и HotTowel, которые выделены зеленым цветом.
Итак, следуя данным предоставленных в таблице вы можете создать Single Page Application приложение используя “голый” ASP.NET и KnockoutJS. Однако, реализацию работы с данными (DAL) вам придется писать самостоятельно, впрочем, как и управление навигацией и историей навигации в том числе.
С другой стороны, вы в праве выбрать Ember или BreezeJS, или даже AngularJS от Google как основу своего сайта или даже как основу своего собственного фреймворка, факт остается фактом, недостающие принципы составляющие концепцию SPA вам придется реализовывать самостоятельно.
Альтернативой предыдущему решению может послужить выбор уже готового полноценного фреймворка (помечены в таблице зеленым фоном). У каждого варианта существуют свои “плюсы” и “минусы”.
Заключение
Примеров приложений построенных по принципам Single Page Application очень много. Одним из самых мощных и общеизвестных является GMail – почтовый сервис компании Google.
Я же хочу привести, как пример, сервис чтения RSS-каналов SilverReader по одной простой причине: этот сервис сделан с использованием фреймворка DurandalJS. И именно этот фреймворк я использовал для построения своего сайта “Что значит имя”.
Одностраничные (spa) и многостраничные (pwa) веб-приложения
Чем отличаются веб-приложения MPA, SPA и PWA, для каких задач подходят. Разбор преимуществ, недостатков и отличий методов разработки.
Существует три основных подхода к разработке веб-приложений: одностраничные (SPA), многостраничные (MPA) и прогрессивные (PWA). Они выделяются среди других подходов простотой разработки, удобством для пользователей и широкими возможностями для развития бизнеса.
Рассказываем, чем отличаются компоненты MPA, SPA и PWA, какие у них преимущества и недостатки, что из них выбрать и для каких задач.
SPA или Single Page Application — это одностраничное веб-приложение, которое загружается на одну HTML-страницу. Благодаря динамическому обновлению с помощью JavaScript, во время использования не нужно перезагружать или подгружать дополнительные страницы. На практике это означает, что пользователь видит в браузере весь основной контент, а при прокрутке или переходах на другие страницы, вместо полной перезагрузки нужные элементы просто подгружаются.
В процессе работы пользователю может показаться, что он запустил не веб-сайт, а десктопное приложение, так как оно мгновенно реагирует на все его действия, без задержек и «подвисаний».
Такого эффекта удается добиться с помощью продвинутых фреймворков JavaScript: Angular, React, Ember, Meteor, Knockout.
Примеры динамических приложений: Gmail, Google Maps, Facebok, GitHub, Meduza.
MPA или Multi Page Application — это многостраничные приложения, которые работают по традиционной схеме. Это означает, что при каждом незначительном изменении данных или загрузке новой информации страница обновляется. Такие приложения тяжелее, чем одностраничные, поэтому их использование целесообразно только в тех случаях, когда нужно отобразить большое количество контента.
Тесная связь между бекендом и фронтендом, поэтому их не получается развивать параллельно;сложная разработка — требуют использования фреймворков как на стороне клиента, так и на стороне сервера, что увеличивает сроки и бюджет разработки.
При выборе типа веб-приложения нужно ориентироваться на то, зачем именно вы его создаете. Многостраничный сайт подойдет интернет-магазину с большим количеством товаров и услуг, а если у вас, к примеру, инфобизнес, где можно изложить всю информацию в рамках сжатого веб-пространства — подойдет одностраничный сайт.
Прогрессивные приложения или Progressive Web Application взаимодействуют с пользователем, как приложение. Они могут устанавливаться на главный экран смартфона, отправлять push-уведомления и работать в офлайн-режиме.
Пример: Google Docs.
Не все браузеры поддерживают основные функции таких приложений (например, Firefox и Edge).
SPA и PWA — это веб-сайты, которые постепенно смещают со своих позиций классические MPA. Так происходит из-за того, что они более простые в разработке, быстрее работают и нравятся пользователям. Однако у них есть слабое место — SEO-оптимизация. Пока еще не все браузеры могут с ними нормально работать, поэтому, чтобы сделать такие приложения дружественными для сео, нужно прибегать к ряду ухищрений. MPA-сайты в этом плане более простые и надежные.
А если же использовать SPA + SSR, то MPA приложения проигрывают по производительности практически во всех аспектах.
Так же, с помощью SSR мы можем реализовывать следующую технику: загружать только те части js / css, которые необходимы для работы конкретного компонента, т.е. представьте, что у нас есть страница каталога с закрытой картой и с закрытыми фильтрами. Когда мы загружаем эту страницу, то у нас не подгружаются компоненты, связанные с картой и фильтрами (т.к. она закрыты) => размер страницы будет крайне мал, а когда человек включает карту или (и) фильтры, то у нас динамически со стороны сервера подгружаются эти самые компоненты (Code Splitting), крч мы подгружаем компоненты только тогда, когда в них есть необходимость.
И дополню, что Code Splitting работает не только для отдельных компонентов, но и для целых страниц, что очень сильно облегчает размер бандла => скорость отдачи web-приложения на сторону клиента.
3) Утечка памяти: если над SPA приложением работает (ют) квалифицированные разработчики, то я на 99.8% уверен в том, что подобной проблемы не возникнет, т.к. методы / тулзы для профилирования (анализа работы приложения) уже давным-давно вышли на новый уровень и сейчас не эпоха ie6, где люди дебажили (искали баги / ошибки) с помощью alert’s. И непонятно, почему этот пункт отнесся именно к SPA, ведь в любом приложении, где есть хоть какая-то логика, может возникнуть подобная ситуация, ни?
5) Про PWA / TWA даже писать не буду, т.к. для этого нужно писать отдельную статью о том, что в этой статье не так.
Для frontend developer’ов: я постарался выражаться не с точки зрения программиста, а с точки зрения «обывателя», чтобы всем было понятно, о чем я говорю, поэтому примите и простите.
Как не потерять поисковый трафик, внедряя технологии SPA
Одностраничные приложения (SPA, single page application) быстро становятся стандартом веб-разработки. На эту технологию переводят свои ресурсы такие техногиганты, как Facebook, Google, Яндекс, Mozilla, Netflix. Она подходит для интернет-магазинов, СМИ, корпоративных порталов и большинства других типов сайтов. От лица агентства-интегратора MST сегодня расскажем про достоинства и недостатки этой технологии и разберем несколько кейсов.
SPA — это одностраничный сайт, на котором контент подгружается без перезагрузки страницы, в ответ на какое-либо действие пользователя. У таких сайтов много достоинств:
Конечно, идеальных технологий не существует, и у SPA есть свои минусы.
Перед внедрением любой технологии важно проводить оценку рисков и мероприятия по их минимизации.
Зайдя с мобильного браузера, пользователь увидит предложение «добавить приложение на главный экран» и в дальнейшем сможет работать с ним в оффлайн-режиме. Приложение имеет свой собственный кэш на устройстве, где после первоначальной загрузки хранятся ресурсоемкие элементы (дизайн, статичный контент, офлайн скрипты), что ускоряет дальнейшее взаимодействие с сайтом.
Еще одной важной фишкой является работа форм офлайн. Введенные в форму данные сохраняются и отправляются на сервер при подключении к интернету. Больше не будет обрывов конверсионной воронки из-за слепой зоны в метро или в лифте.
PWA наиболее актуальны для тех компаний, у которых основная масса клиентов активно используют сайт с мобильных устройств.
Самая главная проблема SPA, из-за которой при неправильной реализации можно потерять большую долю органического трафика на сайт, состоит в том, что одностраничные JS-приложения не индексируются большинством поисковых систем. Роботы Яндекса работают на основе устаревшего движка Chromium 41, который не поддерживает технологию CSR (Client-Side Rendering, рендеринг на клиенте). Именно эта технология обеспечивает «сбор» страницы в браузере пользователя. Заходя на сайт, робот поисковой системы видит лишь белый экран.
Выход в том, чтобы проводить рендеринг заранее, до обращения браузера к серверу, напрямую на сервере. Для этого используется технология SSR: Server-Side Rendering, (серверный рендеринг). На сервере эмулируется браузер, поддерживающий CSR, в нём рендерится HTML-страница и отдается в браузер пользователю, а также индексирующему роботу.
К сожалению, при использовании полного SSR существенно снижается скорость загрузки относительно «чистого» CSR. Обеспечить комфортную для пользователей скорость работы сайта поможет только кропотливая работа по разбору страниц на блоки, их анализу и оптимизации.
«Тяжелые» динамичные блоки дизайна можно оставить рендериться на стороне клиента, а самые важные блоки с текстовым контентом и инфографикой нужно максимально облегчить и рендерить на сервере. Внешние скрипты тоже придётся оптимизировать: часть запускать асинхронно, часть кешировать на сервере, какие-то объединить по возможности.
CSS-стили разносятся по разным файлам в зависимости от важности и выстраиваются в очередь загрузки. Для подгрузки изображений первого экрана и другого мультимедиа-контента лучше использовать CDN (сontent delivery network, распределённая сетевая инфраструктура для доставки контента, которая берет на себя оптимизацию доставки файлов), а также подключить сервисы автоматического сжатия изображений по форматам, размерам, качеству и весу.
Для оптимизации остальных изображений лучше использовать технологию lazyload. «Ленивую подгрузку» контента поисковые системы рекомендуют использовать только для контента, который не понадобится пользователю в настоящий момент. Например, если он не доскроллил до конца страницы, изображения в самом низу загружать не требуется. Внедряя технологию, важно соблюдать требования поисковых систем, описанные в документации для разработчиков.
Поисковики знают о проблемах с SPA-сайтами. И хотя Google утверждает, что научился их индексировать, а у Яндекса есть специальные метки в URL и мета-теги в коде страницы, которые помогают боту узнать о существовании ее HTML-версии, рисковать и полагаться на это пока не рекомендуется. Слишком часто встречались случаи некорректного индексирования материала, даже при соблюдении всех требований поисковых систем.
Сотрудники Яндекса не скрывают, что их поисковые роботы пока так и не подружились с SPA.
Заказчик, представляющий банк «Уралсиб», пришёл к нам с жалобой на падение трафика из поисковых систем почти вдвое после работы предыдущего подрядчика. Их SPA-сайт вообще не индексировался Яндексом, а Google индексировал его с задержками и не полностью. В первую очередь мы настроили серверный рендеринг страниц, продумав баланс между количеством индексируемого контента и скоростью рендеринга.Затем исправили ошибки HTML и CSS-кода, устранили все битые ссылки и 301-редиректы, навели порядок в мета-тегах. Выстроили систему rel=«canonical» на всех html страницах (закрыв дублирующиеся разделы сайта). Настроили главное зеркало сайта и убрали дубли главной страницы. Мы составили семантическое ядро и разработали на основе него новую структуру сайта в виде гигантской mind-карты. Тексты оптимизировали под продвигаемые запросы. Проверили внешние ссылки, избавились от некачественных, договорились о гостевых постах с авторитетными новостными ресурсами. Уже в течение первого месяца работы, после устранения основных проблем удалось не только остановить падение трафика на сайт, но и получить получить рост. Дальнейшие работы вывели сайт на лучшие показатели за все время существования.
У провайдера Дом.ru сложная сеть сайтов и сервисов: 2 основных домена, 54 региональных поддомена и множество технических ресурсов. Сеть построена на нескольких самописных движках на нескольких языках программирования. В ней множество независимых элементов управления, связанных между собой с помощью микросервисов.
Над поддержкой сайта работают несколько команд разработчиков из разных агентств, в том числе клиентский отдел разработки. Каждый участник процесса может внести в сеть доработки, не всегда согласовывая их с остальными. Нашей главной задачей стало оперативное отслеживание таких изменений и адаптация новых технологий под требования поисковых систем.
Мы cтали одной из первых команд, которая переработала под SPA огромный сложный портал в нише телекоммуникаций. Наличие на сайте множества разнообразных интеграций с внешними сервисами, квизами, аналитикой и биллинг-системами сделало этот процесс крайне проблемным и непредсказуемым. Нам пришлось выстроить систему коммуникации со всеми агентствами и отделами, научиться договариваться о соблюдении SEO-требований при внедрении изменений.
Продвижение сайта мы начали с того, что с нуля собрали семантическое ядро и провели hard-кластеризацию с учетом типа выдачи, геозависимости и коммерциализации. Переработали структуру и все основные разделы сайта под новые типы запросов и создали новые посадочные страницы.
В рамках технической оптимизации сайта понадобилось вычистить структуру сайта с тысячами редиректов и битых ссылок, часть которых оказались в контенте, интегрированном на сайт с на внешних сервисов, к которым мы не имели доступа. Задача была сложной и долгой, но мы справились. Доступы к части ресурсов нам удалось получить, а часть контента все же пришлось менять в реальном времени во время получения ответа на запрос с внешнего сервера.
Работа над скоростью загрузки оказалась крайне затруднена из-за объема внешних интеграций, JS и CSS, которые необходимы для поддержания всей инфраструктуры проекта. Совместно с разработчиками мы максимально оптимизировали работу сайтов на SPA, сократили структуру DOM, закешировали большую часть внешних скриптов, интеграций и т.д.
KPI по объему трафика, привлекаемого из органического поиска, был выполнен на 115%. Поисковый трафик вырос на 20% по сравнению с аналогичным периодом прошлого года, при снижении частотности брендовых запросов.
Single Page Application в облачном хранилище
Мы уже писали о том, как наше облачное хранилище может быть использовано в качестве площадки для размещения статических сайтов (1 и 2). Сегодня мы расскажем о том, как на базе хранилища можно размещать современные cайты, в основе которых лежит популярный и актуальный в наши дни подход Single Page Application (SPA).
SPA как подход
Аббревиатура SPA расшифровывается как «single page application» («одностраничное приложение»). В узком смысле она употребляется для обозначения одностраничного сайта, непосредственно выполняемого на стороне клиента в браузере. В более широком смысле SPA (иногда также употребляется аббревиатура SPI — «single page interface») означает целый подход в веб-разработке, который в наши дни получает все более широкое распространение. В чем заключается смысл этого подхода и почему он становится всё более популярным?
Начнем несколько издалека. Сегодня самым распространенным типом сайтов являются, конечно же, динамические сайты, в которых генерация страниц осуществляется на стороне сервера. При всех очевидных удобствах для разработчиков (каждый запрос создаёт страницу с чистого листа), такие сайты порой представляют собой настоящую головную боль для клиентов. Вот далеко не полный список неудобств, с которыми им приходится сталкиваться:
Часто описанные проблемы решаются так: страницы всё ещё генерируются на стороне сервера, но на стороне клиента выполняются небольшие JavaScript-сценарии, с помощью которых можно, например, выполнить валидацию формы до того, как она будет отправлена на сервер. Решение на первый взгляд неплохое, но и у него есть недостатки:
Конечно, жить со всем этим можно. Но подход 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-сервисов стоит также выделить:
С кратким обзором Ваа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 это прописывается так:
Если 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
Это позволяет использовать полноценные URL (см. раздел о History API).
К несомненным преимуществам нашего хранилища перед другими площадками (в том числе и перед описанными выше) относятся низкая стоимость и гибкая система оплаты (никаких фиксированных тарифов; оплата взимается только за объём хранимых данных и исходящий трафик — посчитать можно здесь), а также наличие CDN и гибкой системы настроек параметров контейнеров и отдаваемых файлов.
Заключение
В этой статье мы рассказали ещё об одном аспекте использования нашего хранилища в качестве площадки для хостинга одностраничных сайтов. Надеемся, что она окажется вам полезной.
Если вы уже используете наше хранилище для размещения SPA, поделитесь своим опытом и впечатлениями.Все ваши пожелания и предложения будут обязательно учтены в дальнейшей работе.
Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем в наш блог.