jQuery Mobile — все страницы в index.html по сравнению с отдельными внешними страницами — Что обеспечивает лучшую производительность?

#javascript #jquery #cordova #jquery-mobile

#javascript #jquery #кордова #jquery-mobile

Вопрос:

«Структура «страницы» jQuery Mobile оптимизирована для поддержки либо отдельных страниц, либо локальных внутренних связанных «страниц» внутри страницы.» Документы jQuery

Что обеспечивает лучшую производительность для мобильного приложения jQuery, которое работает на PhoneGap?

  • все страницы в single.html загрузка файлов и внутренняя загрузка
  • либо отдельные страницы с внешними ссылками

Какие-либо другие аспекты, которые следует учитывать?

Ответ №1:

Я использую jQuery mobile, и все сайты, которые я создал, были одностраничными сайтами. Единственные внешние страницы, которые я создаю, — это те, в которые встроены карты Google, просто чтобы загрузка iframe не происходила, если пользователю это не нужно.

Я думаю, это сводится к следующему: одна страница с большим количеством контента может замедлить начальную загрузку, но после загрузки будет быстрее, в то время как крошечная домашняя страница будет быстрой с самого начала, но каждая связанная страница вызовет Ajax-запрос. При разработке для мобильных устройств мое эмпирическое правило — максимально минимизировать http-запросы. Хотя многие пользователи работают в сетях 3 G, все равно может потребоваться время ожидания в зависимости от подключения. Кроме того, подключение может измениться в мгновение, и если пользователь успешно перемещался по сайту, и внезапно все замедляется до обхода, это может вызвать некоторое разочарование. Поэтому, я думаю, исходя из пользовательского опыта POV, пользователи готовы подождать несколько дополнительных тактов при начальной загрузке, если все остальное выполняется быстро после загрузки.

Создание всего на одной странице также полезно для разработки с jQM, imo, потому что я просто создаю кэш-манифест, который включает только одну страницу (и файлы css и js). Тогда мой сайт кэшируется и запускается, даже если у пользователя нет подключения. Если вы работали с applicationCache, вы быстро понимаете, что чем больше у вас файлов, тем сложнее поддерживать манифест кэша, а обновления происходят медленнее.

Ответ №2:

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

Кроме того, многостраничный формат нельзя использовать часто, если вы хотите придерживаться progressive enhancement философии разработки JQM.

Какие-либо другие аспекты, которые следует учитывать?

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

Комментарии:

1. Как насчет автономных приложений — например, с «локальными» файлами в PhoneGap?

2. Это другая история. У меня нет большого опыта в этом, поэтому я могу не знать о некоторых проблемах, связанных с phonegap, но я не вижу никакой разницы, когда нет времени загрузки. За исключением проблем с диалогом, о которых я упоминал, очевидно 🙂 Я думаю, это больше касается вашего удобства при создании архитектуры приложения.

Ответ №3:

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