Il consolidamento / riduzione delle richieste HTTP vale la complessità logistica?

La tua domanda è troppo ampia per rispondere semplicemente a sì / no .

Normalmente dipende .

La mia sfera di cristallo è attualmente fuori uso, il che rende difficile dare consigli concreti;)

My project is in the early stages

Quindi, perché preoccuparsi di questa domanda? Il tipo non specifico della tua domanda è un segno, che non hai punti di dolore . Altrimenti la tua domanda sarebbe come »Il tempo di caricamento della mia pagina iniziale è orribile. Come gestire una tonnellata di Javascript? «

Questo rientra nella categoria prematura , cioè senza necessità pratica . Certo, è sempre bene pensare al futuro, ma non è necessario pensarci ora . Inizia semplice . Fai il layout dell'applicazione, dai uno sguardo a webpack come bundler. E fai andare le cose.

Does consolidating HTTP requests substantially reduce server usage/costs?

La risposta ovvia è si . Ma ancora: perché preoccuparsi?

Se non sei GoogleFacebookAmazon , perché gestire i loro problemi?

Comprendo il timore del debito tecnico ; ma osservalo da un'altra parte: Dì che hai messo insieme qualche Javascript insieme a un Django-backend. L'architettura generale è crap - ma funziona . Quando hai un business di successo, puoi assumere ingegneri qualificati , che ti aiutano a mettere in forma la tua applicazione.

Se prendi Amazon come esempio, è stato AFAIR un gruppo di script Perl, che ha svolto il lavoro in quel momento. Ovviamente non è possibile eseguire Amazon oggi (solo) sugli script da quel momento (inoltre sarebbe interessante sapere se alcuni artefatti sono ancora in esecuzione). Il sistema si è evoluto nel tempo.

Ecco tre take away:

1) Promuovi l'attività

2) C'è no right per farlo.

3) YAGNI - Oppure non ottimizzare per un caso d'uso, che è irrilevante ora .

O se vuoi un consiglio tecnico concreto: Dai una buona prima impressione della tua pagina :

• Fornisci Javascript minimo che aiuti a riavviare la tua applicazione
• Poche immagini nella pagina di destinazione. Ci deve essere un equilibrio tra la consegna delle immagini (aumento tempo di caricamento iniziale ) e il caricamento dinamico delle immagini (che potrebbe richiedere un po 'di tempo su Internet mobile). Devi scegliere tra una più lenta o una forse incompleta pagina, che ha effetto sia sulla prima impressione .
• Poche / nessuna animazioni - aiuta a mantenere la impressione di una veloce pagina; anche se la potenza di elaborazione non dovrebbe avere la stessa importanza di anni fa.

La risposta di Thomas è un ottimo consiglio pratico: ottieni il prodotto per primo.

Da lì, devi capire perché ogni ottimizzazione potenziale è raccomandata o popolare prima di poter determinare se il prodotto ne trae beneficio. Se si determina che una particolare "ottimizzazione" è in realtà un potenziale miglioramento, provare a quantificarlo, stimare il lavoro e prendere la decisione aziendale come al solito.

Ad esempio: CSS image sprites.

Quale problema risolve? Quando si utilizzano molte piccole immagini, le richieste di tali immagini vengono eseguite in serie, a volte bloccando altre risorse provenienti dalla pipe e / o causando la utente di vedere una pagina incompleta per un "lungo tempo".

Come funziona la soluzione? Combina un "core set" di immagini in una singola richiesta, eliminando la latenza delle richieste per immagine a causa di handshake di connessione (in alcuni casi), intestazioni HTTP, il server richiede la pianificazione e l'elaborazione, e così via. Su alcuni browser o quando il numero di immagini è eccessivo, libera anche il pool di connessioni del browser, permettendogli di iniziare a lavorare su altre risorse in parallelo.

Come faccio a sapere quando è applicabile alla mia applicazione? quando carichi il tuo sito con uno strumento di limitazione della velocità (come lo strumento integrato di Chrome), configurato per simulare una velocità comunemente bassa e osservare che la pagina impiega "troppo tempo" per rendere completamente in particolare perché ci sono "molte" richieste di immagini, eseguite in serie, bloccando le "risorse principali" richieste per la pagina per essere utili.

Al contrario, se hai una piccola manciata di immagini che non stanno mettendo le tue pagine oltre una soglia di usabilità, o per immagini che sono solo grandi, probabilmente non vale la pena di trasformarle in sprite.

Quanto è facile implementare e mantenere che varia. Se hai a che fare con un mucchio di immagini decorative, "saporite" che non cambiano quasi mai, è un piccolo, un costo una tantum per eseguirle attraverso uno strumento. Non esitare nemmeno! Se sono immagini "contente", è molto più lavoro ..

E infine, Ne vale la pena? ... munito di alcune informazioni sul rapporto costi / benefici effettivi, è solo una decisione aziendale.

Considera ogni trucco in quel tipo di rispetto.

Che problema risolve? Come lo risolve? È applicabile? Quali sono i costi di implementazione e manutenzione?

Infine, se si determina che il problema esiste e la soluzione è applicabile, ma il costo è elevato, cercare alternative.

Nel caso degli sprites di immagini CSS, un'alternativa è usare semplicemente un minor numero di immagini ...

Sì, lo è. Ma non si tratta del carico del server.

Sembra che tu stia costruendo un'applicazione per una sola pagina le librerie HTML5 e javascript meritano molto credito per aver fatto questo è possibile, ma la motivazione per aderire a una sola pagina non è quella di risparmiare il server. È così che l'utente non deve aspettare mentre viene caricata una seconda pagina.

Il contenuto nascosto può essere caricato mentre l'utente sta fissando la prima schermata leggendo il contenuto visibile. In questo modo l'utente non viene punito quando fa clic. Ricevono contenuti immediati.

Questo approccio alloggia effettivamente i server più a lungo termine poiché anche le cose che non sono mai state cliccate vengono caricate. Ma questo è quello che serve per creare utenti felici.