Есть ли веские аргументы в пользу того, почему не следует разрабатывать сайты с функциональностью ajax, которая загружает основные части каждой части (при условии, что есть такие элементы, как заголовок, навигация и т. Д., Которые остаются прежними)?

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

Ответьте на вопрос с учетом:

• Поведение javascript на сайтах изящно ухудшается в каждом случае.

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

Если контент доступен без JavaScript, тогда ваш вопрос не имеет смысла. Это не «полностью Ajaxified», если вы можете получить доступ к контенту другими способами. На самом деле, вы спрашиваете: «Можно ли улучшить работу моего пользователя с помощью Ajax?». Ответ, очевидно, "да".

редактировать

Назад, когда Google выпустил свое предложение Ajax для сканирования, оно было расстроено как очень плохая идея . Делает для интересного чтения.

Перво-наперво

Плюсы

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

Минусы

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

Теперь на ваш вопрос

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

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

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

Проверьте http://gawker.com/ - этот сайт почти полностью загружается после факта. Они используют "hashbangs" ( http://mydomain.com/#!some_section), чтобы определить, какая страница контента должна быть загружена, основная навигация остается статичной.

Проверьте http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ для краткого учебника по концепции, которую использовал Gawker.

Есть плюсы и минусы, вы должны учитывать поисковые системы (см. Http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), людей с отключенным JavaScript и проводить большое тестирование.

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

Потому что это, вероятно, просто не нужно.
Загрузка основных документов HTML проста и работает. Представление Ajax добавляет совершенно другой уровень процессов для браузеров, кода и обслуживания для Javascript, серверной части, странных URL-адресов hashbang и так далее. Иногда это может быть оправдано, иногда нет. Это может сэкономить вам некоторые ресурсы сервера (может), но будет ли этого достаточно, чтобы компенсировать содержание? Вы должны оценить этот проект.

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

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

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

Да, так и должно быть, но все должно быть наоборот.

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

Конечно, вам нужно сначала определить, включен ли javascript (по cookie), и использовать этот метод, только если он включен.

Итак, вам нужен нормальный полный HTTP-маршрут, а затем маршрут websockets. Это требует дублирования кода, если вы не используете такой инструмент, как node.js

Большинство людей «думают», что это не стоит дополнительных усилий. И иногда это не так.

Кроме того, многие люди неправильно настраивают страницы. Они на самом деле решают, что вам не нужна не-javascript-версия, и вам нужны все эти странные URL-адреса для взлома хеша и сломанные кнопки вперед / назад. Для правильной работы ajax требуется история HTML5 (в IE9 ее нет). Это также требует от разработчика, чтобы завершить версии вашего сайта.

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

Плохо для доступности

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

Там могут быть методы, чтобы обойти это, но я не изучал это слишком тщательно.

Увеличение сложности

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

Такое поведение AJAX также усложнит любой анализ трафика, который вы можете выполнять; Google Analytics не будет правильно регистрировать эти загрузки AJAX без ручного вызова pageTracker._trackPageview('this_page');.

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

Возможно: более медленная загрузка страницы при первом посещении

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

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

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

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

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

Например: скажем, у вас есть 200 человек, пытающихся получить доступ к странице в секунду. У вас есть около 7 запросов к базе данных для ваших вызовов ajax; это 1400 вызовов базы данных в секунду, которые могут затормозить веб-сайт.

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

Это SOA- подход к созданию сайтов.