Il paradosso delle aziende di Hosting italiane e della loro competenza

Il settore dell’hosting in Italia è popolato da realtà grandi e medie che da anni rappresentano un punto di riferimento per professionisti, aziende e privati. Eppure, analizzando da vicino lo stack tecnologico di molte di queste società, emergono lacune sorprendenti: server che non supportano HTTP/3 (QUIC), nessuna traccia della compressione Zstandard (ZSTD), assenza di HTTP/2 o Brotli su servizi che dovrebbero essere all’avanguardia, e totale mancanza di feature moderne come Early Hints. Queste scelte si traducono in più round-trip, maggiore latenza percepita e bandwidth sprecata, soprattutto su mobile e reti congestionate. Anche i KPI di prodotto ne risentono: tempi di TTFB più alti, LCP peggiorato, interazioni meno reattive, con impatti diretti su conversioni e SEO. Spesso il problema non è tecnico in senso stretto, ma organizzativo: si rimane ancorati ai default dei pannelli o a configurazioni “sicure” per compatibilità con CMS e plugin datati, rinviando l’adozione di innovazioni che richiederebbero test, gradualità e osservabilità.

In un mondo in cui Google, Cloudflare e colossi internazionali aggiornano costantemente le proprie piattaforme per ridurre la latenza e migliorare le performance, molte aziende italiane di hosting si presentano ancora con infrastrutture ferme a dieci anni fa. Il paradosso è chiaro: nonostante dimensioni importanti e una clientela numerosa, queste realtà non riescono a tenere il passo con le evoluzioni del settore. Perché? Perché l’innovazione richiede roadmap chiare, change management e la capacità di misurare il beneficio di ogni millisecondo risparmiato, mentre la competizione locale premia spesso listini aggressivi e promozioni più che investimenti protocollari. La paura di “rompere qualcosa” su ambienti legacy e la mancanza di ambienti di staging o rollout canary spingono a rimandare: HTTP/3 resta in backlog, Brotli e ZSTD vengono percepiti come “nice to have”, Early Hints come un dettaglio. Così si consolida una postura difensiva che protegge l’operatività di oggi, ma erode il vantaggio competitivo di domani.

Le cause affondano le radici nella storia dell’hosting in Italia, nella cultura imprenditoriale che ha plasmato queste aziende, e in un mercato del lavoro che rende difficilissimo trattenere i talenti IT più qualificati. Strutture nate e cresciute con logiche finance-driven faticano a dare spazio a sponsor tecnici interni, i budget di formazione sono spesso simbolici, e il turnover riduce la continuità sulle scelte d’infrastruttura. I profili più forti preferiscono la libera professione o realtà internazionali, lasciando gap di competenze proprio sui temi che abilitano salti di qualità (HTTP/3, Brotli, ZSTD, Early Hints). Senza una governance che le consideri ingredienti di base e non optional, l’adozione resta sporadica e tardiva: un limite strutturale che spiega perché tante aziende, pur solide commercialmente, risultino tecnicamente sotto-equipaggiate rispetto agli standard globali.

Le origini: imprenditori prima dei tecnici

Per comprendere l’attuale situazione, occorre fare un salto indietro nel tempo, tra il 1995 e il 2000. In quegli anni pionieristici, Internet in Italia muoveva i primi passi: connessioni dial-up, primi contratti business, nascita dei POP cittadini e dei punti di interscambio che hanno acceso Milano come snodo centrale. In questo contesto Via Caldera diventava il simbolo del nascente ecosistema digitale, un luogo dove telco, system integrator e nuovi provider si affacciavano al mercato con strutture e modelli ancora tutti da definire.

Fondare un’azienda di hosting o un provider in quel periodo significava affrontare investimenti molto elevati: data center, alimentazioni ridondate, climatizzazione, rack e server costosi, connettività di transito con canoni importanti e fibra ancora rara. Non era un mondo per smanettoni solitari o giovani ingegneri con un portatile: servivano capitali, relazioni con i carrier, contratti di fornitura, capacità di negoziare peering e bande minime garantite. In pratica, un terreno naturalmente favorevole a imprenditori e manager più che a tecnici puri.

Molte delle aziende nate in quegli anni sono sopravvissute ed evolute, scalando fino a diventare realtà con centinaia di dipendenti e migliaia di clienti. Ma il DNA rimane quello: strutture fondate e guidate da manager e amministratori, non da tecnologi innamorati della sperimentazione. Questo imprinting ha impattato su processi e priorità: procurement centralizzato, cautela nell’introdurre novità a rischio operativo, forte dipendenza dai vendor e dai loro cicli di release, attenzione prevalente ai conti economici più che alle roadmap tecniche.

Di conseguenza, le pratiche organizzative si sono modellate su logiche finance-driven: piani triennali d’acquisto, standardizzazione spinta per ridurre i costi operativi, limitata tolleranza all’errore e agli esperimenti in produzione. In assenza di una leadership tecnica forte, l’innovazione infrastrutturale è diventata spesso un’attività “su richiesta”, attivata solo quando l’urgenza commerciale lo imponeva, non come competenza distintiva coltivata in modo continuativo.

Questo approccio ha funzionato finché il mercato era giovane e i requisiti relativamente semplici. Ma ha anche sedimentato una cultura aziendale in cui la tecnologia è vista come un mezzo da amministrare con prudenza, più che come un vantaggio competitivo da spingere. È qui che affondano le radici di molte scelte conservative che, anni dopo, spiegano perché tanti provider nati in quell’epoca faticano ad allinearsi rapidamente agli standard tecnici più moderni.

L’evoluzione rapida del web e il ritardo culturale

Dalla metà degli anni 2000, il mondo web ha iniziato un’evoluzione rapidissima. Siti che negli anni ’90 facevano poche migliaia di visite mensili si sono trasformati in piattaforme con milioni di accessi quotidiani, spesso da mobile e con picchi imprevedibili. L’asticella si è alzata su tutto: tempi di risposta, disponibilità, sicurezza, continuità operativa e capacità di reggere carichi elastici.

La scalabilità, la resilienza e le performance sono diventate questioni centrali. Si sono affermati nuovi algoritmi di compressione, protocolli pensati per abbattere la latenza end-to-end, edge caching aggressivo, tecniche di TLS offload e load balancing evoluto, oltre a pratiche di osservabilità (metriche, tracing, log strutturati) indispensabili per capire dove si perdono millisecondi. In questo scenario, molte aziende fondate da imprenditori “amministrativi” hanno iniziato a faticare a stare al passo, perché l’adozione di queste innovazioni richiede una catena di decisioni tecniche coerenti, investimenti continui e la disponibilità a sperimentare in modo controllato.

Il motivo è semplice: chi prendeva (e prende) le decisioni non sempre ha la curiosità o la cassetta degli attrezzi per valutare costi/benefici di novità come HTTP/2 (standardizzato nel 2015) o Brotli (introdotto da Google a partire dal 2013 e poi adottato a livello browser/CDN). Senza una leadership tecnica forte, l’implementazione di queste tecnologie arriva con anni di ritardo, spesso solo dopo pressioni esterne (clienti enterprise, SEO, incidenti di performance) e quasi mai come parte di una roadmap proattiva.

A complicare il quadro ci sono processi interni poco adatti al cambiamento: procurement a cicli lunghi, dipendenza dai default dei pannelli e dai rilasci dei vendor, assenza di ambienti di staging realistici e di rollout graduali (canary, feature flag). Con questa impostazione, ogni upgrade di protocollo o di stack viene vissuto come un rischio operativo da evitare, soprattutto in presenza di applicazioni legacy e CMS non aggiornati. Il risultato è una postura difensiva: meglio non toccare nulla, anche se ciò significa rimanere su HTTP/1.1, gzip e politiche di caching conservative, rinunciando a quei millisecondi che oggi fanno la differenza su UX, SEO e conversioni.

Il ruolo dei dipendenti IT e i limiti del modello italiano

In assenza di fondatori tecnici, l’innovazione finisce sulle spalle di sysadmin e devops dipendenti, ma spesso con mandate sbilanciate sull’operatività: spegnere incendi, tenere in piedi l’on-call, chiudere ticket. Poco spazio a design architetturale, roadmap di performance o sperimentazione controllata. Senza sponsorship tecnica, ogni cambiamento “di base” (nuovi protocolli, compressioni, TLS, edge) diventa straordinario e quindi raro.

Le figure IT sono ancora inquadrate dai CCNL come i metalmeccanici: griglie rigide, scarsa distinzione tra competenze, avanzamenti più legati all’anzianità che all’impatto tecnico. Manca quasi ovunque una engineering ladder (junior → senior → staff → principal) con responsabilità e retribuzioni coerenti. Il risultato è un livellamento verso il basso: chi studia, certifica, automatizza e sposta metri le metriche aziendali guadagna poco più di chi si limita al minimo contrattuale.

Il paragone con il metalmeccanico evidenzia l’anacronismo: il primo necessita di macchinari costosi e quindi del datore che li possiede; l’informatico dal 2005 in poi, con portatile e connessione, può generare valore direttamente per i clienti. Se in azienda non esistono budget formazione strutturati, tempo dedicato al miglioramento continuo, politiche di remote/hybrid e una reperibilità pagata e sostenibile, i migliori scelgono la libera professione o l’estero.

Le conseguenze sono note: turnover alto, isole di eccellenza circondate da routine, config drift tra ambienti, decisioni tecniche rinviate, dipendenza dai vendor e dai default dei pannelli. Il know-how diventa personale, non aziendale: basta un’uscita per perdere mesi di apprendimenti. A quel punto la domanda è inevitabile: perché un tecnico capace dovrebbe accettare 1.500–2.500 € al mese in una PMI, con vincoli e on-call spesso sottostimate, quando da freelance può chiedere 500–1.000 € al giorno lavorando per obiettivi, da remoto e con maggiore autonomia?

La conseguenza: carenza di figure realmente competenti

Questo squilibrio produce una conseguenza inevitabile: nelle aziende di hosting italiane spesso restano figure meno motivate e meno aggiornate. Non perché manchino persone intelligenti o appassionate, ma perché chi ha davvero talento preferisce percorsi alternativi dove può crescere, scegliere gli strumenti e misurare l’impatto del proprio lavoro. All’interno, invece, ci si ritrova con team che presidiano l’operatività di base ma raramente guidano salti di qualità.

Il risultato si vede sul campo: stack implementati a metà, configurazioni contraddittorie tra ambienti, innovazioni ignorate o introdotte senza criterio. In produzione convivono versioni diverse degli stessi servizi, policy di sicurezza non uniformi, automatismi di deploy incompleti. E quando manca una cultura di osservabilità (metriche, log strutturati, tracing) e SLO chiari, i problemi diventano intermittenti e difficili da diagnosticare: si rincorrono i sintomi, non le cause.

Non è raro che all’interno della stessa azienda coesistano due anime ben distinte:

• da una parte il “nerd” competente, che propone e implementa soluzioni moderne, scrive runbook, automatizza e misura;

• dall’altra figure lontane anni luce dal mondo IT, incapaci di gestire persino problematiche di base, che ripiegano su “workaround” manuali e rimandano gli upgrade.

Questa schizofrenia genera segnali ricorrenti:

• Feature a intermittenza: HTTP/2 attivo su un cluster e disattivato su un altro; Brotli solo sugli asset statici “nuovi”; HTTP/3 rimandato “al prossimo trimestre”.

• Configurazioni non allineate: cipher suite diverse, HSTS presente su alcuni vhost e assente su altri, cache policy opposte tra siti simili.

• Operatività fragile: patching saltuario, finestre di manutenzione che slittano, MTTR elevato per incidenti ripetitivi.

• Hero culture: tutto dipende da una o due persone “chiave”; alla loro assenza, i tempi si allungano e la qualità decade.

Per il cliente finale questo si traduce in servizi altalenanti: un mese va tutto bene, quello dopo emergono inefficienze macroscopiche—picchi di latenza, time-to-first-byte in salita, backend che saturano durante campagne marketing, anomalie di caching che invalidano pagine cruciali. La percezione è di un fornitore che non controlla davvero il proprio stack, ma lo subisce. E quando l’esperienza utente vacilla, seguono costi nascosti: ticket in aumento, perdita di fiducia, cali di conversione e SEO. In assenza di competenze stabili e diffuse, ogni miglioramento resta episodico; senza continuità tecnica, la qualità non scala.

Tecnologie mancate: HTTP/2, Brotli, QUIC, Early Hints

Per rendere l’analisi più concreta, vale la pena citare alcune delle tecnologie “mancate” e cosa comporta non adottarle.

• HTTP/2 — Standard dal 2015: introduce multiplexing (più richieste sulla stessa connessione), HPACK per comprimere le intestazioni e una gestione delle priorità più efficiente. Tradotto: meno round-trip, pagine che iniziano a rendere prima e code TCP meno ingolfate. Dove si inceppa? Spesso l’ALPN non è configurato, i bilanciatori terminano ancora HTTP/1.1 o i cipher suite bloccano l’h2 su TLS. È il “minimo sindacale” del 2025.

• Brotli — Algoritmo di compressione per asset testuali (HTML/CSS/JS/JSON) più efficace del gzip: tipicamente -15/25% di bytes rispetto a gzip a parità di qualità. Due modi d’uso: pre-compressione degli asset statici (.br a build time) e compressione dinamica per risposte generate. Spesso si rinuncia per timore del carico CPU, ma profili intermedi (livelli 4-6) e caching fanno quadrare i conti senza penalizzare. Non abilitarlo significa pagine più pesanti e tempi di download maggiori, soprattutto su mobile.

• HTTP/3 (QUIC) — Protocollo su UDP con handshake più rapido, connection migration (cambio rete senza perdere la sessione) e niente head-of-line blocking a livello di trasporto. Impatta soprattutto su reti instabili: riduce la latenza percepita nei primi hop e migliora la resilienza su 4G/5G e Wi-Fi affollati. Richiede supporto a livello di edge/bilanciatore e annunci Alt-Svc ben configurati. Senza h3 si rinuncia a millisecondi preziosi proprio dove conta: mobile e geografie “lontane”.

• Zstandard (ZSTD) — Algoritmo moderno con ottimo compromesso rapporto compressione / CPU. Anche quando non si usa come Content-Encoding lato browser (supporto non uniforme), resta strategico per backhaul origin↔CDN, microservizi, log e backup (dump DB, snapshot, artifact). Adottarlo riduce banda e storage, velocizza pipeline interne e replica dati; ignorarlo significa costi e tempi maggiori in tutto ciò che non è “fronte web”.

• Early Hints (103) — Il server/edge invia in anticipo un 103 Early Hints con Link: rel=preload per asset critici (CSS above-the-fold, font, JS essenziali) mentre l’app prepara la risposta 200. Il browser inizia subito il fetch e il LCP scende spesso di 50–200 ms. Serve coordinare applicazione, CDN/edge e header corretti; non adottarlo è lasciare “fermi ai box” i client durante il TTFB.

Queste mancanze non sono dettagli: sono vantaggi competitivi persi su velocità, UX e SEO. In pratica significano più byte trasferiti, più handshake, layout che si stabilizza dopo, minori conversioni e peggior engagement—con costi nascosti in assistenza e infrastruttura che lievitano nel tempo.

Turnover, demotivazione e qualità altalenante

Il problema si aggrava con l’elevato turnover. Le aziende che non riconoscono economicamente (e professionalmente) i tecnici migliori perdono ciclicamente le risorse chiave: un sysadmin competente resta 6–12 mesi, poi passa a realtà più grandi o alla consulenza. Così la conoscenza resta personale, non aziendale: quando quella persona esce, se ne vanno anche contesto, script, “trucchi” operativi, criteri di tuning.

Senza una base stabile, l’hosting non sviluppa una cultura tecnica duratura. Si vive di presente: qualcuno introduce una soluzione avanzata, chi arriva dopo non la comprende, la disattiva “per prudenza” o la lascia degradare. L’assenza di runbook aggiornati, documentazione minima e SLO condivisi produce entropia: ambienti divergenti, patching a macchia di leopardo, procedure di incident response improvvisate.

I segnali tipici di questa deriva:

• Config drift continuo tra cluster e data center; versioni e policy incoerenti.

• Hero culture: due persone sanno tutto; se mancano, i tempi esplodono.

• DORA metrics in peggioramento: lead time lunghi, alto change failure rate, MTTR in crescita.

• Incidenti ricorrenti (“Groundhog Day”): stessi bug, stessi workaround, nessun postmortem efficace.

• Debt organizzativo: ticket backlog, rilascio funzionalità in freeze, aggiornamenti rimandati “a dopo”.

Per il cliente, questa instabilità si traduce in qualità altalenante: un mese performance brillanti, quello dopo crolli inspiegabili; caching che cambia comportamento, latenze che oscillano, rollout bloccati nei periodi caldi. La percezione è di un fornitore che subisce l’infrastruttura invece di governarla, con un costo nascosto fatto di tempo perso, fiducia erosa e opportunità mancate. In assenza di continuità e ownership diffusa, la qualità non scala e ogni progresso resta episodico.

Il divario con le aziende fondate da tecnici

Non tutte le realtà, però, sono così. Esiste una differenza sostanziale tra le aziende di hosting fondate e guidate da tecnici e quelle dirette da imprenditori amministrativi. Le prime trattano l’infrastruttura come un vantaggio competitivo; le seconde come un centro di costo da contenere.

Nelle realtà guidate da tecnici:

• si studia e si sperimenta con regolarità (tech radar interno, RFC, prove in canary e feature flag);

• si introducono tecnologie quando sono stabili e misurabili (SLO di latenza, error budget, RUM e synthetic test);

• esistono runbook, postmortem senza colpe (blameless) e standard condivisi su TLS, caching, CDN, CI/CD;

• il procurement è snello e orientato a ridurre la latenza e aumentare l’affidabilità, non solo i CAPEX;

• la crescita delle persone è parte del piano: mentorship, training, certificazioni, ladder di carriera tecnica.

Nelle aziende “amministrative”:

• la roadmap è sales/finance-driven, con cicli di acquisto lunghi e dipendenza dai default dei vendor;

• si misura l’uptime, raramente la lentezza (nessun budget di performance, poca osservabilità);

• gli upgrade sono straordinari e temuti, perciò rimandati; l’innovazione è reattiva, non proattiva;

• la documentazione è scarsa, gli standard sono inconsistenti tra ambienti, la qualità dipende da singoli “eroi”;

• formazione e ricerca sono viste come costo, non come leva di margine.

Questa differenza culturale determina tutto: soddisfazione del cliente (meno ticket, risolti meglio), tempo di risposta ai problemi (MTTR più basso, incidenti che non si ripetono), e soprattutto capacità di innovare: chi è guidato da un forte asse tecnico porta in produzione prima—e con meno rischi—HTTP/3, Brotli, Early Hints, ZSTD e quanto serve per restare competitivo.

Il cliente e la scelta consapevole

Alla luce di tutto ciò, cosa dovrebbe fare un cliente che cerca un’azienda di hosting affidabile in Italia? Partite dalle persone. Valutate chi avete davanti, non solo cosa c’è in listino.

• Parlate con un tecnico, non solo con il commerciale. Chiedete una call con chi mette mano allo stack: se sa spiegare in modo chiaro perché HTTP/3, Brotli, ZSTD o Early Hints migliorano LCP/TTFB, siete sulla strada giusta. Se invece arrivano risposte generiche o scriptate, aspettatevi un servizio standardizzato e arretrato.

• Fate domande verificabili.

  1. “Supportate HTTP/2 e HTTP/3 end-to-end, anche dietro bilanciatori/CDN? Avete ALPN e TLS 1.3 ovunque?”

  2. “Usate Brotli in dinamico e in pre-compressione degli asset? Avete una strategia per ZSTD su backhaul, backup e artefatti?”

  3. “Implementate Early Hints (103) con Link: rel=preload sugli asset critici?”

  4. “Quali SLO di latenza misurate (p95 TTFB/LCP)? Pubblicate status page e postmortem?”

  5. “Come rilasciate: canary/blue-green, rollback in un clic, staging realistici?”

• Chiedete prove, non promesse. Un ambiente di test o una migrazione pilota di un sito reale, con misure prima/dopo (RUM o synthetic), vale più di qualsiasi brochure. Guardate i numeri: p95 TTFB, LCP, INP, tempo di build e di purge della cache.

• Valutate la cultura, non solo la tecnologia. Segnali verdi: runbook e documentazione aggiornati, changelog trasparente, incidenti gestiti con postmortem blameless, roadmap tecnica pubblica. Segnali rossi: “se funziona non toccarlo”, upgrade straordinari e rari, dipendenza dai default dei pannelli, un “eroe” che sa tutto e il resto del team che naviga a vista.

• Guardate l’allineamento incentivi → qualità. Ci sono SLA con penali anche su performance (non solo uptime)? Esistono piani di capacity per i picchi (saldi, campagne, TV)? C’è un responsabile tecnico con ownership misurata su metriche di esperienza reale?

La differenza non sta nei listini o nelle brochure patinate, ma nella passione tecnica e nella disciplina operativa di chi porta avanti l’azienda. Se al telefono trovate un tecnico entusiasta, aggiornato e capace di argomentare scelte e trade-off, è molto probabile che dietro ci sia un’infrastruttura curata. Se vi risponde l’ennesimo impiegato demotivato che recita frasi fatte, preparatevi a un servizio che procede per inerzia.

Conclusione

Il paradosso è chiaro: molte aziende di hosting italiane sono solide sul piano commerciale ma arretrate sul piano tecnico. Le radici sono storiche e culturali: imprenditori prima dei tecnici, contratti che non valorizzano le competenze, un mercato che spinge i migliori verso la libera professione o l’estero. Il risultato sono stack conservativi, upgrade tardivi e performance che non reggono il confronto internazionale.

La buona notizia è che esistono realtà diverse, guidate da tecnici con visione e disciplina: adottano per tempo HTTP/3, Brotli, ZSTD, Early Hints; misurano TTFB, LCP e INP; investono in CI/CD, osservabilità e SLO chiari. Qui le scelte infrastrutturali non sono “optional”, ma fondamento competitivo.

Il vero discrimine non è la dimensione dell’azienda ma la cultura tecnica che la guida. Per il cliente si traduce in una regola semplice: scegliete chi sa spiegare e dimostrare, con numeri e prove, le ragioni delle proprie scelte. Scegliete sempre l’hosting dove c’è un tecnico entusiasta dietro la cornetta, non un impiegato in attesa della pensione.