Чи є якісь обґрунтовані міркування, чому сайти не повинні розроблятися з функцією 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 тощо. Іноді це може бути виправдано, іноді ні. Це може заощадити деякі ресурси сервера (можливо), але чи цього буде достатньо для компенсації обслуговування? Ви повинні оцінити цей проект.

Наприклад, коли Twitter отримав останнє оновлення, вони взяли підхід, що це був не просто веб-сайт, а додаток, і вся справа на базі Ajax, хоча більшість того, що вона робить, могла оброблятись із регулярними запитами на сторінку. Одна з найбільших проблем, яка все ще трапляється зараз, хоча набагато рідше, приїжджає туди і вітається з чистою сторінкою, оскільки щось в Аяксі не вдалося.

На практиці багато роботи над створенням "повністю AJAX" веб-сайту, особливо для великих веб-сайтів, які дуже складні. Деякі веб-сайти, які намагаються це зробити, - це Google і Facebook, але навіть вони не роблять це ідеально.

Поширені проблеми - навігація (тобто вперед і назад) та закладки, але є багато інших помилок, з якими багато розробників, швидше за все, не повинні мати справу. Це в основному означає створення двох версій веб-сайту, сумісних з користувачами Javascript і не-javascript (і виправлення для всіх браузерів з поганою підтримкою AJAX).

Так, так і має бути, однак має бути навпаки.

Загальні частини сторінки повинні надсилатися через HTTP. Тоді невеликий ajax (або ще краще веб-розетки) управління завантажує динамічний вміст асинхронно.

Звичайно, потрібно спочатку визначити, чи ввімкнено JavaScript (за допомогою файлу cookie), і використовувати цей метод лише в тому випадку, якщо він включений.

Отже, вам потрібен звичайний повний HTTP-маршрут, а потім маршрут веб-розетки. Для цього потрібно дублювання коду, якщо ви не використовуєте такий інструмент, як 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 до створення веб-сайтів.