Ciao, e benvenuto nella settima puntata della cinquantottesima stagione. Finora abbiamo parlato di macchinari complessi: due mondi, idratazione, pacchetti di dati. È lecito fermarsi e chiedersi: ma chi me lo fa fare? Perché non tenere tutto semplice, con una normale applicazione che gira solo nel browser? Oggi rispondo a questa domanda, e la risposta giustifica tutto lo sforzo. Oggi parliamo di visibilità e prestazioni.
Partiamo dal primo motivo, perché per molti progetti è decisivo: farsi trovare. Immagina di aver costruito un negozio online, o un blog, o il sito di un'attività. Vuoi che le persone lo trovino cercando su internet, e che i tuoi contenuti appaiano quando qualcuno li condivide su una chat o su un social. Ma i motori di ricerca, e i sistemi che generano le anteprime dei link, funzionano mandando dei robot automatici a leggere le pagine. E qui casca l'asino con l'applicazione che gira solo nel browser: quando il robot arriva, trova una pagina praticamente vuota, perché i contenuti compaiono solo dopo che il codice si è scaricato e ha lavorato, cosa che il robot spesso non aspetta. Il risultato è che il tuo bellissimo sito, per chi lo cerca, è quasi invisibile.
Voglio dirti come il server risolve tutto questo, perché è netto. Costruire la pagina sul server risolve il problema alla radice. Quando il robot del motore di ricerca arriva, trova una pagina già piena, completa di testi, titoli, descrizioni, tutto pronto e leggibile immediatamente. Non deve aspettare nessun codice: il contenuto è lì, in chiaro, dal primo istante. Lo stesso vale per le anteprime dei link: quando condividi una pagina, l'anteprima appare ricca e corretta, con titolo e immagine, perché quelle informazioni erano già nella pagina spedita dal server. Per qualunque contenuto che deve essere scoperto, trovato, condiviso, costruire sul server non è un lusso: è una necessità.
Voglio darti il secondo motivo, perché tocca ogni utente. Il secondo motivo è la prestazione percepita, cioè quanto veloce sembra il sito alla persona che lo usa. Con l'applicazione che gira solo nel browser, l'utente apre il sito e per un momento fissa una pagina bianca, o una rotellina che gira, mentre aspetta che il codice si scarichi e costruisca tutto. Su una connessione lenta o un telefono modesto, quel momento può essere lungo e frustrante. Costruendo sul server, invece, l'utente vede subito i contenuti veri: la pagina compare piena all'istante. L'interattività arriverà un attimo dopo, con l'idratazione, ma intanto l'utente sta già leggendo. La differenza tra fissare il vuoto e leggere subito è enorme, in soddisfazione e in persone che restano invece di andarsene.
Voglio darti l'immagine che rende chiara questa idea, perché la fissa. Pensa a due negozi nella stessa via. Il primo ha la vetrina illuminata, piena di prodotti in mostra: chi passa vede subito cosa vende, entra incuriosito, e anche chi cerca quel tipo di prodotto lo nota da lontano. Il secondo negozio ha la saracinesca abbassata, con un cartello scritto a mano: apriamo tra poco, aspettate. Chi passa non vede nulla, tira dritto, e nessuno saprà mai cosa vendeva. L'applicazione che gira solo nel browser è il secondo negozio, con la saracinesca abbassata mentre carica. Costruire sul server è il primo, con la vetrina già accesa e piena, che invita e si fa notare.
Voglio essere onesto ed equilibrato, perché non sempre serve. Detto tutto questo, va detto anche il rovescio: non tutti i progetti hanno bisogno di farsi trovare. Un'applicazione gestionale interna, dietro una password, usata solo dai dipendenti, non deve comparire su nessun motore di ricerca, e i suoi utenti sono disposti ad aspettare un istante di caricamento. Per casi come questo, tutta la complessità del server è uno sforzo che non ripaga, e una semplice applicazione nel browser va benissimo. La visibilità e la comparsa istantanea sono vantaggi enormi, ma solo quando servono davvero. Ed è per questo che la scelta pagina per pagina, di cui abbiamo parlato, è così preziosa.
Voglio darti la lezione generale, perché lega mezzi e fini. La lezione è che la complessità tecnica ha senso solo se serve un obiettivo reale. Tutto il macchinario del rendering universale, l'idratazione, i due mondi, non è complicazione fine a se stessa: esiste per due scopi concreti e misurabili, essere trovati e apparire subito. Quando quegli scopi contano per il tuo progetto, la complessità è giustificata e ripaga. Quando non contano, la stessa complessità è solo zavorra. Il professionista non abbraccia la complessità per moda, e non la rifiuta per pigrizia: la adotta quando serve uno scopo, e la lascia perdere quando non serve.
Per oggi ci fermiamo qui. Abbiamo risposto alla domanda: perché tutto questo sforzo? Due motivi concreti. Il primo è farsi trovare: i robot dei motori di ricerca e le anteprime dei link leggono una pagina già piena, mentre trovano vuota quella che gira solo nel browser, rendendola quasi invisibile. Il secondo è la prestazione percepita: l'utente vede subito i contenuti, invece di fissare una pagina bianca. Come una vetrina accesa e piena contro una saracinesca abbassata. Con l'onestà del rovescio: per un gestionale interno dietro una password, tutto questo non serve, e una semplice app nel browser basta. La lezione: la complessità ha senso solo al servizio di uno scopo reale. Nella prossima puntata: la magia delle convenzioni, comodità e costo. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.