| | Eh no! Se anche questo mese vi aspettavate un articolo trash scritto dal vecchio pieno di virgole, parentesi, faccine ed errori di battitura vi stavate sbagliando!
D'altro canto, non aspettatevi nemmeno termini in latino o titoli solenni come gli articoli del Sensei, non è proprio roba da me 
Essendomi preso il compito di scrivere l'articolo del mese e non avendo la più pallida idea di cosa parlare, ho deciso di ricollegarmi all'articolo di luglio scritto da Kakashi, In interiore server habitat veritas, nel quale il maestoso ci ha fatto notare come molti siti ancora non adottino le configurazioni base che sono diventate standard negli anni.
Quindi, un sito web che possa definirsi aggiornato, quali canoni deve rispettare? Ho deciso di fare un elenco di punti base che, secondo la mia personalissima opinione, dovrebbero essere rispettati in un sito che possa definirsi attuale e funzionale.
La configurazione dello spazio web
E' il punto cruciale da cui partire, in base a questo vengono infatti definiti gli strumenti che saranno messi a disposizione al webmaster, in base al tipo di sito che vogliamo creare possiamo scegliere tra diversi http servers, i più utilizzati sono Apache, nginx e node.js (non un vero proprio webserver ma, grazie al modulo http-server, può svolgere tutte le funzioni di cui abbiamo bisogno), per ognuno di essi è facilissimo reperire guide online o plugins, rendendoli semplici da configurare: se il nostro sito avrà bisogno di lavorare tramite un websocket la scelta migliore è utilizzare node.js per gestire l'intero backend, se invece non ne abbiamo bisogno possiamo utilizzare Apache/nginx in accoppiata con il classico Php; nel caso ci interessi servire molti contenuti statici la scelta migliore è sicuramente nginx, nettamente più veloce ed in grado di servire contemporaneamente moltissime richieste, se si tratta invece di contenuti dinamici la prestazioni sono pressochè equivalenti (a patto di utilizzare l'mpm_event ed abbandonare la mod_php in favore di Php-FPM gestito tramite Fast-CGI).
Qualsiasi scelta si voglia effettuare, il requisito principale è uno: utilizzare https!
Al giorno d'oggi non si tratta di una scelta, se volete fare un sito e non volete vedere quell'orribile avviso "Questo sito non è sicuro" non avete alternative, senza contare tutti i vantaggi relativi alla sicurezza dei dati trasmessi.
Ma anche qua, nel corso degli anni, sono stati deprecati diversi protocolli crittografici, dobbiamo quindi adottare solo TLSv1.2 e TLSv1.3, qualsiasi altro (come ad esempio TLSv1/1.1 o i vari SSL) porterà ad una scarsa valutazione dello spazio web, poichè nonostante venga utilizzato il protocollo più recente supportato dal nostro browser rimangono comunque attivi quelli deprecati.
Purtroppo però non basta questo, dobbiamo fornire un minimo di configurazione ai virtualhost, bisogna quindi evitare che le pagine del sito siano raggiungibili attraverso il solo indirizzo ip del server o tramite altri sottodomini, questo non farebbe altro che creare dei duplicati nei risultati delle ricerche con conseguenti penalizzazioni oppure crearci seri problemi con la validità del certificato SSL.
Fatta questa configurazione di base ci si può quindi spostare sull'adozione del nuovo protocollo http/2, ormai largamente supportato, per poter sfruttare la nuova funzionalità push: immaginate di aprire una pagina web, contenente vari files Javascript, Css ed immagini (residenti tutte sul nostro spazio), per ognuno di essi senza http/2 il browser esegue una richiesta al server per recuperare il contenuto, instaurando quindi più connessioni; grazie ad http/2 possiamo invece spingere questi files direttamente nella risposta alla prima richiesta, evitando quindi spreco di risorse per gestire altre connessioni (ci sarebbe un discorso da fare sulla cache client di questi contenuti pushati, ma se volete possiamo approfondirlo in un altro momento ).
Ultimo punto di questo breve discorso su una configurazione basilare riguarda invece il database: la scelta non manca, il più diffuso è sicuramente MySQL, ma ci si può fiondare anche sul più completo PostgreSQL, che include funzioni più avanzate di analisi dati e diversi tipi di campi in più, oltre ad un debug delle queries più dettagliato.
Importantissimo adottare un sistema di cache dei dati, se ne possono trovare a bizzeffe, questo eviterà in molti casi di interpellare il database con tempi notevolmente ridotti di esecuzione.
La struttura del backend
Nonostante si possa avere un'ottima configurazione, ogni improvement può essere letteralmente distrutto da un backend pessimo: istruzioni complicate lente da eseguire, inclusioni di numerosi files (eh sì, più l'applicazione è frammentata più i tempi per includere i files si allungano, va quindi ragionata bene) o, ancora peggio, queries eseguite malamente su campi che non sono nè primary/indici che possono risultare lente, mettendo sotto sforzo il server con risultati potenzialmente catastrofici, come down o addirittura corruzione dei dati.
Non voglio dilungarmi troppo su questa parte parte, anche perchè ci sono veramente troppi modi in cui può essere fatto un backend e non vi è uno standard, tutto dipende da cosa dobbiamo fare: oltre ad un codice pulito e fluido ciò che aiuta molto è appunto l'adozione del sistema di cache, sia per il recupero/salvataggio dei dati estratti, sia anche per il caching dell'opcode (nel caso si stesse utilizzando Php), che ci permette di mantenere salvato il codice già compilato, evitando quindi utilizzo smodato del processore per ricompilare ad ogni esecuzione.
Va fatta molta attenzione anche all'utilizzo di altri strumenti quali SASS, molto diffuso: è comodissimo per organizzare i propri fogli di stile ed eseguire modifiche veloci su moltissimi selettori grazie all'integrazione di variabili e funzioni ma la compilazione, specie su larga scala, deve essere eseguita solo nel caso di modifiche; lo scrivo perchè, per quanto possa essere scontata come cosa, mi è capitato di vedere alcune applicazioni basate su node che ricompilavano i fogli di stile ad ogni apertura della pagina 
Interfaccia grafica
Inutile dirlo: deve essere responsive, diciamo basta ai design tabellari! (oddio, lo sto scrivendo veramente sul blog del NewsBoard?!)
Al giorno d'oggi per poter usufruire di tutti i vantaggi che offrono questo tipo di templates è facilissimo, basti pensare a Bootstrap, con la sua documentazione e la moltitudine di snippsets disponibili rende veramente facile creare un'interfaccia comune tra i dispositivi mobili e quelli desktop.
Date le mie scarsissime doti grafiche non sono mai stato un amante della moltitudine di immagini nei siti, ci vanno solo quelle estremamente necessarie, tutti gli altri effetti/icone possono benissimo essere fatte con i css oppure con l'adozione di files svg o webfonts.
Per quanto riguarda la semplicità di utilizzo/navigazione ed organizzazione dei contenuti ho poco da dire, tutto sta al webmaster, se si adottano le configurazioni UI come i social sicuramente l'utente si troverà meno spaesato, ma anche qua non c'è un metodo preciso da seguire: quel che posso dire è prendete come esempio il sito dell'Agenzia delle Entrate e fate totalmente il contrario.
Ok, credo di aver esposto le cose principali, seppur in modo molto marginale, per approfondirle tutte molto probabilmente non sarebbero bastate 100 pagine, ma se qualcuno avesse piacere di approfondire un argomento kostaki sarebbe contento, ci facciamo un articolo apposito 
Sono invece curioso di sapere cosa ne pensate voi, quali strumenti/configurazioni/requisiti sono necessari al giorno d'oggi secondo voi per definire un sito web moderno?
- Tags:
- configurazione,
- gestione,
- hosting,
- http,
- performance,
- server,
- sicurezza
|
|
però anche di recente (qualche mese fa) mi è capitato di vedere un sito di "pubblica amministrazione" ancora http
comunque sono d'accordo, fate la rubrica, così per qualche mese siamo a posto 