Являются ли SPA (Single Page Applications) подходящими для сайтов, предназначенных для мобильных телефонов?

Ответ 1

TL; DR: приложения с одной страницей требуют большего внимания к их архитектуре, особенно если вы перенастраиваете функциональность существующего веб-сайта (doh, проекты с коричневыми полями жесткие).

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

• Разница между загрузкой 10 КБ и 15 КБ незначительна, это накладные расходы на подключение, которые истощают всю радость от опыта работы с мобильными устройствами.

• Вы можете редко влиять на latency (хотя использование CDN и хостинга в облачном баннере), но вы можете компенсировать его влияние. Ресурс объединяет и минимизирует, и базовые концепции применимы независимо от используемой среды.

• В любом случае вы должны быть gzipping вашего контента, а способ работы дополнительно дефлирует (haha) аргумент размера. В основном, он фокусируется на повторении последовательностей символов и более эффективен для таких вещей, как раздутая разметка HTML, а не насадка JSON. Это смешно для clojure -компилированного javascript.

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

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

• Использование jQuery на мобильном сайте иногда является необходимым злом. Возможно также использовать его правильно.

• Чем больше javascript у вас есть, тем больше относительный стимул к тому, чтобы он не выполнялся повторно при каждой загрузке страницы. Любая инфраструктура, которую вы включаете на странице, должна быть инициализирована до ее использования, и для этого требуется разбор и выполнение кода... на каждой используемой странице. SPA должен выполнить этот шаг один раз (все же это не оправдание для плохого/отсутствующего управления зависимостями).

• Это также относится к CSS. Когда новый контент добавляется в DOM после взаимодействия с пользователем, будет меньше повторных потоков и повторных красок, чем новая загрузка; также нет необходимости в том, чтобы браузер снова разбирал таблицы стилей.

Реальная сила одностраничного приложения в своей воспринимаемой производительности. Мы с вами оба знаем, что нажатие на ссылку не разрешается мгновенно, но пользователю этого не нужно. Приведение сайта в соответствие с пользовательскими взаимодействиями путем добавления состояний касания и своевременного throbber значительно улучшит UX. Конечно, вы всегда можете пройти лишнюю милю и предварительно получить определенный контент. Может быть, имеет смысл загрузить следующую страницу/элемент/фотографию в фоновом режиме сразу после того, как текущий будет готов?

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

Ответ 2

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

Менее загруженный контент

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

Другим способом, с помощью которого SPA может быть более эффективным, является разделение логики построения разметки и ваших данных. Рассмотрим пример списка со 100 именами и баллы:

Традиционные:

<ul id="myList">
  <li><strong>Name 1</strong> score 1</li>
  <li><strong>Name 2</strong> score 2</li>
  <li><strong>Name 3</strong> score 3</li>
  ...
  <li><strong>Name 100</strong> score 100</li>
<ul>

SPA:

<ul id="myList"></ul>

var myData = { 
  "Name 1" : "score 1",
  "Name 2" : "score 2",
  "Name 3" : "score 3",
  ...  
  "Name 100" : "score 100"
}
var html = '';
for (var name in myData) {
  var html += '<li><strong>' + name + '</strong> ' + myData[name] + '</li>';
}
document.getElementById('myList').innerHTML = html;

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

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

Transitions

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

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

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

Ответ 3

TL; DR: Да, это возможно, но вам нужно быть дисциплинированным, и преимущество в восприятии производительности

Я работаю над переходом традиционного серверного веб-приложения на рабочем столе в отзывчивый SPA за последние несколько месяцев. В частности, мы выбрали проект MV *, поддерживаемый маршрутизатором-посредником, развязанный с AMD. Мы изучаем переход на RVP.

Я включил некоторые из наших принципов дизайна ниже:

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

Вы можете найти это сравнение с картой полезным

Ответ 4

Держите его простым -

Да Приложения с одной страницей идеально подходят для мобильной разработки. В таких системах SPA, как Durandal, Angular, Backbone, Ember и т.д., Нужен только механизм JavaScript для эффективной работы. Они совместимы с кросс-браузером и не требуют ничего специального для работы с каждым размером экрана, разрешением или устройством и используют мощные двигатели мобильных устройств.

Что делает их настолько подходящими?

С одностраничным приложением вы можете поместить все крючки в место для декларативного двустороннего связывания данных с такими библиотеками, как Knockout, Handlebars или Angular, которые заменят все манипуляции с JQuery DOM, которые вы будете использовать на традиционном веб-сайте. Это будет способствовать использованию повторно используемых компонентов, таких как директивы и пользовательские обработчики привязки, которые уменьшают количество необходимого кода и позволяют упростить тестирование, поскольку привязки будут повторно использоваться через ваше приложение.

Что делает их не очень хорошими для мобильных?

Приложения с одной страницей часто могут начинать путь плохого дизайна, от которого трудно восстановить (как и любая другая разработка). Разница в том, что трудно найти отличный путь для создания масштабируемого приложения и часто сначала разработчики времени SPA делают предположения. Это может быть облегчено за счет использования ресурсов (таких как платная поддержка, StackOverflow и т.д.) Или путем выполнения расширенного обзора кода вокруг основания вашего SPA

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

В большинстве случаев приложения с одной страницей быстро становятся молниеносно. Основная идея заключается в использовании инъекции зависимостей, а библиотеки, такие как Require.js для загрузки модулей AMD, позволяют разработчику требовать от клиентов загрузки файлов HTML и JavaScript редко при внесении изменений. Погружая из кеша, вы существенно уменьшаете свои хиты до сервера на вызовы данных. Это следует методам веб-разработки RESTful.

Ответ 5

SPA - хороший выбор для мобильных сайтов. Следующий шаблон кажется хорошей производительностью на мобильных сайтах SPA

Hottowel
(Обзор)

С меньшим временем отклика вы сможете добиться отличной производительности. Я попытался использовать этот шаблон для создания веб-сайта, который поддерживает как мобильные браузеры, так и веб-браузеры.

• Использование jquery для динамического процесса
• Используйте вызов ajax для быстрого вызова данных по мере необходимости
• Архитектура MV предоставит вам четкую картину для реализации ваших концепций.
• HTML5 будет лучшим выбором для внешнего интерфейса.
• Используйте отдельный API для обработки данных, что увеличит вашу производительность.

Ответ 6

Короткий ответ - да.

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

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

У меня был большой успех, используя такие инструменты, как RequireJS, чтобы загружать нужные мне биты (и организацию!). Это может быть сопряжено с каркасом вашего выбора, например BackboneJS, AngularJS, EmberJS... там много отличного.

Самая интересная структура, которую я видел, - Famo.us, они требуют 40-60 кадров в секунду на телефонах, ПК и телевизорах. И их демоверсии работают безупречно на мобильных устройствах.

Ответ 7

Переломным моментом для этого решения является сложность разработки. Обычные веб-серверные приложения легче разрабатывать, потому что там гораздо больше разработчиков, которые знают все трюки, как сделать такое приложение максимально эффективным. СПА, с другой стороны, могут обеспечить лучшую производительность во всех областях: 1) более быстрая передача данных, 2) более быстрые операции с графическим интерфейсом (DOM), 3) более интеллектуальный UX, но для всех из них потребуются более опытные (дорогие) разработчики, которые могут быстро и быстро надежный. Эти разработчики меньше. Если вы планируете делать все сами, это означает, что вам будет более длинной кривая обучения и много проб или ошибок. Это в основном потому, что SPA-центры являются новыми по сравнению с обычными WWW.

Чтобы создать эффективный SPA, вам нужно хорошо знать часть соединения/сокета, знать узкие места, выбирать протоколы, какие платформы (устройства) поддерживают протоколы подключения. Просто выбрать предпочтительное решение непросто: Engine, IO, Socket.IO, SockJS и др.

Вам нужно хорошо знать манипуляции с DOM с точки зрения динамической производительности, чтобы разумно выбирать между divs/tables/canvas.

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

JavaScript в эти дни очень быстро работает на iOS/Android, поэтому скорость языка сама по себе не должна быть проблемой. Большим преимуществом является использование Node.js, чтобы вы могли программировать на одном языке как на стороне клиента, так и на стороне сервера. Нет необходимости синхронизировать функции hashThisPassword() на двух (или более) языках.

Ответ 8

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

Но я бы добавил, что SPA - не волшебное решение для всех приложений, особенно когда речь идет о "Critical Path Rendering".

Краткая история

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

Мы поняли, что было бы труднее достичь желаемого клиента с помощью Angular. Таким образом, мы создали приложение без него. Приложение широко использовало запросы AJAX и другие методы оптимизации. В итоге время рендеринга главной страницы уменьшилось почти на 1 секунду. Через два месяца после развертывания клиент показал рост на 30% в продажах! Хорошо, это было приложение с простыми функциями, и у него не было всего богатства, которое обычно имеет SPA.