Esiste un solido ragionamento sul perché i siti non dovrebbero essere sviluppati con la funzionalità Ajax che carica le parti principali di ogni parte (supponendo che ci siano elementi come l'intestazione, la navigazione ecc. Che rimangono gli stessi)?

Sicuramente sarebbe meno dispendioso in termini di risorse poiché il server non dovrebbe servire il contenuto che appare su ogni pagina, a beneficio sia dell'host che dell'utente finale.

Rispondi alla domanda prendendo in considerazione:

• Il comportamento javascript dei siti degrada con garbo in ogni istanza

• Per la mia domanda sto parlando di nuovi siti in cui questo comportamento potrebbe essere implementato piuttosto da subito, quindi non costa tecnicamente alcun denaro - non stiamo tornando a un prodotto finito per implementarlo.

Se il contenuto è raggiungibile senza JavaScript abilitato, la tua domanda non ha alcun senso. Non è "completamente Ajaxified" se è possibile ottenere il contenuto con altri mezzi. Davvero, quello che stai chiedendo è "va bene migliorare l'esperienza del mio utente tramite Ajax?". La risposta è ovviamente "sì".

modificare

Quando Google è uscito con la sua proposta Ajax crawlable, è stata definita una pessima idea . Rende per una lettura interessante.

Cominciando dall'inizio

I pro

• AJAX può consentire di utilizzare una pagina "base" comune e di caricare solo le aree di contenuto, che possono ridurre il tempo di caricamento per gli utenti, dal momento che gran parte della pagina è già caricata.
• Può consentire ad alcuni piacere per gli occhi come sbiadire l'area del contenuto dentro e fuori.

I contro

• Non funziona bene se la pagina viene scaricata.
• Può pasticciare con i dispositivi per disabili.
• I visualizzatori con javascript disattivato non saranno in grado di utilizzare il contenuto a meno che non venga utilizzata anche una versione non javascript.
• Molto più lavoro (bisogna davvero dirlo?).

Ora per la tua domanda

Supponendo che il tuo sito degrada con garbo per coloro che non hanno Javascript, quanto bene dipende da come è fatto. Ad esempio, se visualizzi un collegamento a una versione non javascript di punto in bianco, è un inconveniente per quegli spettatori dover fare clic su un altro collegamento. D'altra parte, se esiste una "pagina principale" di noscript che utilizza i collegamenti tradizionali, che funziona meglio per la maggior parte degli utenti, ma manca ancora il supporto per coloro che utilizzano dispositivi per disabili, istanze in cui l'utente arriva per una "pagina" specifica da un collegamento, ecc.

Tutto sommato, nel mondo della connessione web sempre più veloce, non giustifica davvero tagliare una piccola quantità di file (presumeremo tutto il Javascript stesso, il CSS e le immagini possono e saranno memorizzate nella cache, lasciando solo la pagina "base" su cui salvare i byte) per i contro che può dare, vale a dire la difficoltà extra (anche se non è sempre una sfida è buona) e la mancanza di supporto che può dare ad alcuni utenti.

Tutto sommato, direi che dipende da te, probabilmente funzionerebbe abbastanza bene, e per la stragrande maggioranza degli utenti, probabilmente vedranno il sito come previsto, ma personalmente direi di no fastidio, in quanto non vale la pena per un tale miglioramento marginale di dimensioni del file.

Dai un'occhiata a http://gawker.com/ - questo sito si carica quasi completamente dopo il fatto. Usano "hashbangs" ( http://mydomain.com/#!some_section) per determinare quale pagina di contenuto deve essere caricata, la navigazione principale rimane statica.

Dai un'occhiata a http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ per un breve tutorial sul concetto usato da Gawker.

Ci sono pro e contro, devi considerare i motori di ricerca (vedi http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), le persone con javascript disabilitato e fare molti test.

Detto questo, l'argomento più grande contro di loro è probabilmente che quando un utente attende il caricamento di una pagina, quindi deve attendere un ulteriore caricamento, potrebbe essere impaziente. Dal mio punto di vista, la migliore pratica è caricare il sito principale, la navigazione e il contenuto principale in un unico passaggio (su richiesta) e salvare l'AJAX per le spese accessorie non essenziali. Funziona con l'idea del miglioramento progressivo e mescola il meglio di entrambi gli approcci.

Perché probabilmente non è necessario.
Il caricamento di documenti HTML di base è semplice e funziona. L'introduzione di Ajax aggiunge un intero altro livello di processo per browser, codice e manutenzione per Javascript, elementi back-end, strani URL hashbang e così via. A volte questo può essere giustificato, a volte no. Potrebbe risparmiare alcune risorse del server (potrebbe), ma sarà sufficiente per compensare la manutenzione? Devi valutare quel per progetto.

Ad esempio, quando Twitter ha ottenuto la sua ultima riprogettazione, hanno adottato l'approccio secondo cui non si trattava solo di un sito Web (pagina), ma di un'applicazione, e l'intera cosa è fortemente basata su Ajax, anche se la maggior parte di ciò che fa potrebbe essere gestito con richieste di pagine regolari. Uno dei maggiori problemi, che ancora oggi accade molto meno, è arrivare lì e essere accolti con una pagina vuota perché qualcosa nell'Ajax è fallito.

In pratica è molto difficile produrre un sito Web "completamente AJAX", in particolare per i principali siti Web che sono molto complicati. Alcuni siti Web che tentano questo sono Google e Facebook, ma anche loro non lo fanno perfettamente.

Problemi comuni sono la navigazione (ovvero avanti e indietro) e il bookmarking, ma ci sono molti altri bug che molti sviluppatori preferirebbero non avere a che fare. Fondamentalmente significa creare due versioni del sito Web per essere compatibili con gli utenti Javascript e non javascript (e correzioni per tutti i browser con un supporto AJAX non valido).

Sì, dovrebbe essere, tuttavia dovrebbe essere il contrario.

Le parti comuni della pagina devono essere inviate su HTTP. Quindi un piccolo controllo ajax (o anche migliori websocket) carica il contenuto dinamico in modo asincrono.

Ovviamente devi prima rilevare se javascript è abilitato (tramite cookie) e utilizzare questo metodo solo se è abilitato.

Quindi è necessario il normale percorso HTTP completo e quindi un percorso WebSocket. Ciò richiede la duplicazione del codice a meno che non si utilizzi uno strumento come node.js

Molte persone "pensano" che non valga la pena di fare uno sforzo in più. E a volte no.

A parte un sacco di persone ajaxify pagine sbagliate. In realtà decidono che non hai bisogno di una versione non javascript e che hai bisogno di tutti questi strani URL hash bang e pulsanti avanti / indietro rotti. Fare Ajax correttamente richiede la cronologia HTML5 (IE9 non ce l'ha). Richiede inoltre agli sviluppatori di completare le versioni del tuo sito Web.

Dato che hai dichiarato che si degraderebbe con grazia per i visitatori con Javascript disabilitato, posso vedere solo due problemi reali (e un possibile problema) che potrebbero sorgere.

Male per l'accessibilità

Gli screen reader e altre tecnologie assistive sono spesso respinti da cambiamenti DOM dinamici. Elaborano e leggono la pagina in modo lineare e cambiando il contenuto della pagina dopo che è stata caricata potrebbe non essere gestita correttamente.

Potrebbero esserci delle tecniche per aggirare questo problema, ma non ho esaminato troppo a fondo.

Complessità aumentata

Mantenere questo tipo di sito potrebbe essere complicato. Per un esempio: se hai creato un nuovo layout e modificato l'ID dell'area di contenuto che stavi sostituendo con i tuoi collegamenti AJAX, ciò potrebbe interrompere il tuo schema di navigazione in un modo piuttosto sconcertante.

Questo tipo di comportamento AJAX complicherebbe anche qualsiasi analisi del traffico che potresti fare; Google Analytics non registra correttamente questi carichi AJAX senza una chiamata manuale a pageTracker._trackPageview('this_page');.

L'aggiunta di maggiore complessità al funzionamento della tua pagina aumenta anche il livello per i nuovi sviluppatori; chiunque lavori sul sito dovrebbe probabilmente essere informato di come questo comportamento influisce sul caricamento delle pagine.

Possibile: caricamento della pagina più lento alla visita iniziale

A seconda di come strutturi le cose, questa pagina che recupera il codice AJAX potrebbe essere avviata solo dopo il caricamento completo del documento. Quindi, solo dopo che il tuo visitatore ha scaricato l'intera pagina, quindi il Javascript (se fosse un file esterno) e il suo browser lo ha reso e recuperato il contenuto tramite AJAX, vedrebbero il contenuto della pagina.

Ogni collegamento successivo cliccato sarebbe più veloce, ma recuperare la prima pagina visitata da un utente richiederebbe effettivamente più tempo di una versione statica.

Il motivo per cui l'ho etichettato come un possibile problema è che potresti sempre inviare staticamente la prima pagina (poiché avrai già la versione statica come fallback) e quindi utilizzare AJAX per i collegamenti successivi.

Per quello che vale, questa non mi sembra un'idea terribile, specialmente per usi sensibili alla larghezza di banda come le pagine mobili. Dovresti valutare attentamente gli svantaggi per assicurarti che ne sia valsa la pena nel tuo caso.

Avere elementi Ajax su una pagina va bene quando hai una piccola base di utenti, ma quando hai più traffico; si desidera utilizzare un approccio più statico per ridurre l'abuso di risorse.

Ad esempio: supponi di avere 200 persone che provano ad accedere a una pagina al secondo. Hai circa 7 query sul database per le tue chiamate ajax; che è 1400 database chiama un secondo, che può impantanare un sito Web.

Un sito Web che deve essere progettato per un traffico maggiore dovrebbe avere pagine statiche rivolte verso l'esterno, per contenuti che possono essere visualizzati in modo statico. Ciò si ottiene utilizzando uno script lato server che viene eseguito ogni secondo per ricostruire la pagina statica, che viene recuperata per l'utente finale, e quindi è stato ridotto il carico da 1400 chiamate al database al secondo a 7.

È un approccio SOA alla costruzione di siti Web.