Abbiamo molte immagini generate dagli utenti sul nostro sito. Quando gli utenti caricano le loro immagini, archiviamo solo l'originale. Tuttavia, a seconda della pagina, mostriamo diverse dimensioni di quelle immagini (piccole, medie, grandi, originali). È necessario memorizzare tutte le dimensioni di queste immagini o c'è un modo migliore? Attualmente li stiamo ridimensionando con i CSS, ma questo è molto lento.
La memorizzazione di più copie dell'immagine nelle dimensioni richieste è probabilmente la scelta migliore, per diversi motivi:
Lo spazio su disco è relativamente economico,
Come @Jalayn ha commentato, il ridimensionamento delle immagini non richiede molta potenza di elaborazione,
Come commentato da @Dan Pichelman, offrire immagini più piccole quando possibile farà risparmiare sui costi della larghezza di banda.
Una volta caricato un file, avvia un processo asincrono per generare le varie copie in modo che l'utente non debba attendere.
C'è un sacco di modi per gestirlo e penso che la "strada giusta" dipenda.
Tuttavia penso che possiamo essere tutti d'accordo sul fatto che memorizzare le diverse dimensioni sia il modo migliore.
Il tuo sito potrebbe non essere configurato in modo che 3 dimensioni funzionino comunque per te (come piccolo, medio, grande) e, naturalmente, memorizzare tutte le possibili combinazioni non è pratico. Quindi, detto questo, memorizzerei alcune dimensioni diverse in base alle dimensioni più comuni che servi.
Se ti capita di memorizzare un'immagine 100px x 100px per la maggior parte del tempo e hai bisogno di un'immagine 90px x 90px servi solo il 100x100 e ridimensionala con css, non è un grosso problema dover servire l'immagine 900x900px e ridimensionandolo. È un buon compromesso.
Non sono d'accordo sull'archiviazione dei file, se possibile, quelle immagini intermedie non dovrebbero mai essere archiviate poiché creano sempre confusione.
Lo spazio su disco è poco costoso, ma servire file da disco è lento, e gli SSD - che sono veloci - non sono ancora così economici. Questo modello "genera tutte le dimensioni dell'immagine che possiamo pensare" non è a prova di futuro e funziona fino a quando non è possibile predefinire tutte le risoluzioni di immagine che è necessario visualizzare. C'è sempre il problema del contenuto residuo che è difficile da mantenere, ma almeno è sempre lo stesso problema. Le specifiche aziendali possono rovinare questo modello abbastanza facilmente. Se è necessario disporre di una nuova risoluzione delle immagini, è necessario scrivere script di ridimensionamento che attraversano l'intera libreria di immagini esistente e crea la nuova risoluzione in modo che le vecchie immagini possano funzionare in un nuovo design. È fattibile, ma ha bisogno di amministratori di sistema. Tuttavia, se le specifiche aziendali richiedono di essere molto reattivi e cambiano sempre le dimensioni dell'immagine, che non possono essere predefinite, questo modello è fottuto.
Siamo stati lì e abbiamo fatto questo, ora invece usiamo la cache di vernice e una combinazione di applicazioni di ridimensionamento per servire immagini ridimensionate arbitrariamente senza memorizzarle esplicitamente su disco. Dato che le immagini sono servite dalla cache, la loro consegna è velocissima. Con questa soluzione non è necessario:
Nel nostro modello il ridimensionamento avviene nel processo richiesta-risposta quando il visitatore richiede l'immagine ridimensionata. In altre parole, il visitatore che carica un'immagine ridimensionata nel browser - un'immagine che non è mai stata visualizzata - dovrà attendere un po 'di tempo in più, mentre il sistema crea la nuova immagine ridimensionata.
Funzione bonus: tutto è testabile chiamando un semplice URL, non è necessario eseguire l'app Image Resizer per creare le diverse versioni dell'immagine. L'immagine verrà creata al volo.
Ogni richiesta di collegamento arriverà a una Varnish che gestisce le richieste in arrivo. Varnish è configurato in modo tale che quando riceve una richiesta che non ha parametri di query, serve la richiesta dal filesystem statico senza memorizzare il contenuto nella cache. Disattivare la cache in questo caso è una buona idea solo se l'immagine originale non verrà mai mostrata ai visitatori, solo quelli ridimensionati (forse perché l'originale è abbastanza grande).
Se la richiesta in entrata ha parametri di query, Varnish invia la richiesta all'applicazione di ridimensionamento. L'applicazione ottiene l'immagine di base eseguendo nuovamente la richiesta originale senza la stringa di query, il che significa che Varnish servirà l'immagine originale all'applicazione. Poiché Varnish può fungere da bilanciamento del carico, può persino mitigare i problemi, come il timeout dell'applicazione.
L'applicazione esegue quindi il ridimensionamento appropriato (controllando la validità dei parametri, le regole, ecc.) e fa una risposta con l'immagine ridimensionata. La risposta risale alla catena di risposta, che è Varnish, e che memorizza nella cache l'immagine ridimensionata e la restituisce al client.
Qualsiasi richiesta successiva all'immagine della stessa dimensione (ovvero lo stesso URL con gli stessi parametri di query) verrà pubblicata dalla cache fino alla scadenza della cache.
In questo modo Varnish viene utilizzato come dispositivo di archiviazione, con l'ulteriore vantaggio di essere una cache.
Leggi altre domande sui tag web-development
