Pubblicato il: nov 08, 2025 - 654 Visualizzazioni

Audit server web (Apache/Nginx, PHP-FPM, MySQL): prestazioni & sicurezza
Intervento rapido disponibile: ricevi il tuo audit del server entro 72 ore (urgenza in 24 ore possibile). Richiedi un preventivo gratuito

Il tuo sito è lento, va in errore 502/504 o è poco sicuro? Il tuo server arriva al 100% di CPU con appena 50 visitatori simultanei? Eseguo un audit tecnico completo del tuo server (Ubuntu/Debian, OVH/Scaleway, Contabo...) per ridurre il TTFB, stabilizzare il carico e rafforzare la sicurezza.

L'audit copre l'intero stack tecnico: protocolli di rete (TLS/HTTP2), configurazione del server web (Nginx/Apache), ottimizzazione di PHP-FPM, analisi delle query MySQL lente, messa in sicurezza del sistema e implementazione di strumenti di monitoraggio. Deliverable: un report chiaro e con priorità, con la possibilità che sia io stesso ad applicare le correzioni.


Perché fare un audit del server web?

I sintomi che devono metterti in allarme

La tua infrastruttura server mostra segni di debolezza se riscontri uno o più di questi problemi:

Prestazioni in calo:

  • Tempo di risposta del server (TTFB) superiore a 600 ms, quando l'obiettivo è < 200 ms
  • Il sito diventa lento o irraggiungibile appena il traffico aumenta (50-100 visitatori simultanei)
  • Le pagine impiegano 5-10 secondi a caricarsi, mentre il solo HTML dovrebbe essere servito in < 1 secondo
  • I Core Web Vitals sono in zona rossa (LCP > 4 s, TTFB > 800 ms)

Errori ricorrenti:

  • Errori 502 Bad Gateway o 504 Gateway Timeout più volte al giorno
  • Errori 500 Internal Server Error senza una causa evidente nei log applicativi
  • Connessioni PHP-FPM che saturano ("max children reached")
  • MySQL che rifiuta nuove connessioni ("Too many connections")

Problemi di stabilità:

  • Il server richiede riavvii frequenti (più volte a settimana)
  • Consumo di CPU o RAM costantemente al 90-100% senza un picco di traffico che lo giustifichi
  • I processi PHP-FPM o MySQL si arrestano in modo casuale (OOM Killer)
  • I log mostrano decine di query lente (> 2 secondi) ogni giorno

Vulnerabilità di sicurezza:

  • Certificato SSL/TLS scaduto o configurazione debole (cipher obsoleti, niente HSTS)
  • Nessun firewall configurato o regole troppo permissive
  • Nessuna protezione contro gli attacchi brute force (fail2ban assente)
  • Versioni di PHP, MySQL o del sistema operativo obsolete e senza patch
  • Accesso SSH come root con password (invece delle chiavi SSH)

L'impatto di questi problemi sul business

Un server configurato male ha conseguenze dirette e misurabili sulla tua attività:

Perdita di fatturato: un sito che impiega 5 secondi a caricarsi perde il 20% dei visitatori (studio Google). Per un e-commerce da 50.000 €/mese, significa 10.000 € di mancati incassi ogni mese.

Penalizzazioni SEO: Google penalizza i siti lenti nel suo algoritmo. Una pagina che passa da 2 a 5 secondi di caricamento può perdere il 30-50% del traffico organico in pochi mesi.

Costi di infrastruttura gonfiati: un server poco ottimizzato richiede spesso un costoso upgrade hardware (da 4 a 8 CPU, RAM raddoppiata), quando una semplice ottimizzazione software risolverebbe il problema a un costo 10 volte inferiore.

Rischio di attacchi informatici: il 43% dei cyberattacchi prende di mira le PMI (rapporto Verizon 2024). Un server non protetto è una porta d'ingresso per phishing, furto di dati dei clienti o ransomware.


Cosa analizzo nel dettaglio

Il mio audit del server copre 7 livelli tecnici essenziali, con misurazioni prima/dopo per quantificare i miglioramenti.

1. Rete & protocollo

Cosa verifico:

  • Configurazione TLS/HTTPS: versione del protocollo (minimo TLS 1.2, idealmente 1.3), suite di cifratura sicure, catena di certificati completa
  • Header di sicurezza: HSTS, CSP, X-Frame-Options, X-Content-Type-Options
  • HTTP/2 o HTTP/3 attivo per il multiplexing e la compressione degli header
  • Compressione Gzip/Brotli configurata per HTML/CSS/JS/JSON
  • DNS: tempo di risoluzione, configurazione DNSSEC se applicabile

Cosa rivela: cipher obsoleti (RC4, 3DES) rendono il tuo sito vulnerabile ad attacchi come BEAST o POODLE. L'assenza di HTTP/2 costa il 20-30% di velocità sulle pagine con molte risorse. Un TTFB DNS elevato (> 100 ms) rallenta sistematicamente tutte le richieste.

Impatto misurabile: passaggio a TLS 1.3 + HTTP/2 + Brotli = riduzione del 25-40% del tempo di caricamento totale e voto A+ su SSL Labs.


2. Configurazione Nginx / Apache

Cosa verifico:

  • Cache statica: direttive expires, cache-control, etag per immagini/CSS/JS
  • Header di compressione: gzip_types, brotli_types
  • Log: formato personalizzato con $request_time e $upstream_response_time per il debug
  • Rate limiting: protezione contro scraper e bot aggressivi
  • WAF di base: ModSecurity o Nginx limit_req per bloccare i pattern di attacco più comuni
  • File di configurazione: worker_processes, worker_connections, keepalive_timeout, client_max_body_size

Cosa rivela: worker_connections a 768 invece di 4096 limitano artificialmente il numero di connessioni simultanee. L'assenza di cache statica costringe il browser a riscaricare gli asset a ogni visita. Un client_max_body_size a 2M blocca l'upload dei file multimediali.

Impatto misurabile: configurazione ottimale = 50-60% di banda risparmiata grazie alla cache del browser + capacità di gestire 4 volte più connessioni simultanee.


3. PHP-FPM: il collo di bottiglia invisibile

Cosa verifico:

  • Strategia di gestione dei processi: pm = dynamic vs static vs ondemand
  • Dimensionamento: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers
  • Limiti: pm.max_requests (riciclo dei worker), request_timeout, request_terminate_timeout
  • Opcache: opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files, hit rate
  • Limiti PHP: memory_limit, max_execution_time, post_max_size, upload_max_filesize
  • Slow log: attivazione e analisi delle richieste PHP lente (> 1 s)

Cosa rivela: è IL punto di blocco n. 1 sull'80% dei server. Esempio tipico: pm.max_children = 5 su un server con 4 CPU → appena arrivano 6 richieste simultanee, le successive vengono messe in coda, generando timeout.

Un opcache configurato male (troppo piccolo, senza preloading in PHP 8.x) costringe PHP a ricompilare gli script a ogni richiesta, moltiplicando il carico della CPU di 5-10 volte.

Impatto misurabile: passaggio da pm.max_children = 5 a pm.max_children = 40 (dimensionato in base alla RAM disponibile) + opcache ottimizzato = riduzione del 70% del TTFB + scomparsa degli errori "502 Bad Gateway".

Esempio concreto: sito WordPress con WooCommerce, 4 GB di RAM, pm.max_children = 5 (valore predefinito).

  • Prima: errori 502 già con 8 visitatori simultanei, TTFB di 3-6 secondi
  • Dopo: pm.max_children = 30, pm = dynamic, opcache attivo → TTFB di 0,4 s, nessun 502 fino a 100 visitatori simultanei

4. Database MySQL / MariaDB

Cosa verifico:

  • Configurazione delle connessioni: max_connections, wait_timeout, interactive_timeout
  • Buffer e cache: innodb_buffer_pool_size, query_cache_size (se MySQL < 8.0), tmp_table_size
  • Slow query log: attivazione e analisi delle query > 1 secondo
  • Indici mancanti: EXPLAIN sulle query più frequenti per individuare i full table scan
  • Lock: rilevamento di deadlock e transazioni lunghe
  • Ottimizzazione delle tabelle: frammentazione, tabelle inutilizzate, ANALYZE TABLE

Cosa rivela: un innodb_buffer_pool_size a 128MB (valore predefinito) su un server con 16 GB di RAM = MySQL non riesce a tenere in cache i dati più usati e sollecita continuamente il disco.

Le query senza indici costringono MySQL a scansionare 500.000 righe invece di 10, moltiplicando il tempo di esecuzione di 5000 volte (da 0,001 s a 5 s).

Impatto misurabile: innodb_buffer_pool_size portato al 70% della RAM + aggiunta di 3-5 indici strategici = riduzione dell'80% delle slow query + tempo di risposta della pagina diviso per 3.


5. Prestazioni applicative & TTFB

Cosa misuro:

  • TTFB (Time To First Byte) da diversi punti geografici: obiettivo < 200 ms per l'Europa
  • LCP (Largest Contentful Paint): obiettivo < 2,5 s
  • Tempo di generazione del solo HTML (senza asset): deve essere < 400 ms per una pagina dinamica
  • Numero di query SQL per pagina: più di 50 query = problema N+1 da indagare
  • Dimensioni e peso degli asset: immagini non ottimizzate, JS/CSS non minificati
  • Strategia di cache applicativa: Redis/Memcached, cache HTML statica (Varnish, nginx fastcgi_cache)

Cosa rivela: un TTFB di 2-4 secondi indica che il server impiega quel tempo solo per iniziare a inviare i dati. Anche con una connessione in fibra, l'utente aspetta. Il problema è spesso una combinazione di PHP lento + query MySQL non ottimizzate + assenza di cache.

Impatto misurabile: ottimizzazione combinata (PHP-FPM + MySQL + cache Redis) = TTFB che passa da 2,8 s a 0,3 s, LCP da 6 s a 2,1 s → ingresso nella fascia "Good" dei Core Web Vitals.


6. Sicurezza del sistema & hardening

Cosa verifico:

  • Firewall: UFW o iptables configurato, porte aperte ridotte al minimo (22, 80, 443), blocco delle scansioni delle porte
  • Fail2ban: protezione di SSH, HTTP e MySQL contro gli attacchi brute force
  • Accesso SSH: disattivazione del login come root, autenticazione solo tramite chiavi SSH, porta non standard
  • Utenti e permessi: nessun servizio eseguito come root, separazione degli utenti web/db
  • Aggiornamenti: versioni di PHP, MySQL e del sistema operativo aggiornate con le patch di sicurezza
  • Backup: frequenza, conservazione, test di ripristino, archiviazione esterna al server
  • Rotazione dei log: logrotate configurato, compressione, eliminazione automatica dei log vecchi
  • Rilevamento delle intrusioni: individuazione dei file modificati, monitoraggio dell'integrità del sistema

Cosa rivela: l'80% dei server analizzati non ha fail2ban oppure lo ha configurato male, consentendo migliaia di tentativi di connessione SSH al giorno. L'assenza di backup testati = rischio di perdita totale dei dati in caso di guasto del disco o ransomware.

Impatto misurabile: hardening completo = riduzione del 95% dei tentativi di intrusione (log di fail2ban) + garanzia di ripristino in < 2 ore in caso di incidente grave.


7. Osservabilità & monitoraggio

Cosa implemento:

  • Analisi dei log: errori PHP, errori Nginx, slow query MySQL, errori di sistema
  • Metriche del server: CPU, RAM, disco, rete, swap
  • Alerting di base: email/SMS se CPU > 90% per 5 minuti, disco > 85%, servizio down
  • Strumenti: Netdata (leggero, gratuito) o New Relic (se il budget lo consente)
  • Dashboard semplice: un colpo d'occhio per verificare lo stato di salute del server

Impatto: rilevamento proattivo: ricevi un avviso 10 minuti prima che il server vada giù, invece di scoprire il problema dai clienti scontenti. Riduzione dell'MTTR (Mean Time To Repair) da 2 ore a 15 minuti.


La mia metodologia completa

Fase 1: accesso & analisi preliminare (30 min)

Accesso:

  • Connessione SSH (chiave pubblica fornita) o accesso al pannello OVH/Plesk/ISPConfig
  • Accesso in lettura ai log (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
  • Credenziali MySQL in sola lettura per l'analisi delle slow query

Raccolta iniziale:

  • Inventario: versioni di PHP, MySQL, sistema, server web
  • Statistiche: uptime, load average, utilizzo attuale di CPU/RAM/disco
  • Lettura rapida dei log: individuazione degli errori ricorrenti

Fase 2: test di prestazioni & di carico (1 h)

Misurazioni di riferimento (baseline):

  • TTFB da 3 località diverse (Europa, USA, Asia) con curl/webpagetest
  • Load test: simulazione di 10, 50, 100 utenti simultanei con Apache Bench o k6
  • Profiling PHP: attivazione di Xdebug o Blackfire per individuare le funzioni lente
  • Analisi MySQL: top 20 delle query lente tramite pt-query-digest (Percona Toolkit)

Individuazione dei colli di bottiglia: il load test rivela esattamente dove si rompe qualcosa: è PHP-FPM che satura? MySQL che va in lock? La RAM che finisce in swap?

Fase 3: analisi della sicurezza (45 min)

Scansione delle vulnerabilità:

  • Test SSL: ssllabs.com, testssl.sh per individuare le debolezze TLS
  • Scansione delle porte aperte: nmap per rilevare servizi esposti non necessari
  • Verifica delle CVE: versioni di PHP/MySQL obsolete con vulnerabilità note
  • Audit dei file: file con permessi 777, possibili script backdoor

Revisione della configurazione:

  • Analisi di /etc/ssh/sshd_config, regole del firewall, jail di fail2ban
  • Verifica dell'esistenza e della validità dei backup

Fase 4: analisi delle configurazioni (1 h)

Analisi approfondita delle configurazioni:

  • Nginx/Apache: lettura riga per riga dei file di configurazione + benchmark
  • PHP-FPM: calcolo della memoria totale consumata (pm.max_children * memory_limit) rispetto alla RAM disponibile
  • MySQL: analisi di my.cnf, raccomandazioni di MySQLTuner
  • Sistema: configurazione dei limiti (ulimit), swap, parametri del kernel

Fase 5: stesura del report (1-2 h)

Struttura del report:

1. Executive Summary (2 pagine)

  • I 3 problemi critici individuati
  • Impatto stimato sul business (es.: perdita del 15% del traffico SEO, 25% di visitatori che abbandonano)
  • Budget per le correzioni: 0-500 € (configurazione), 500-1500 € (ottimizzazioni complesse), > 1500 € (migrazione/upgrade hardware)

2. Diagnosi dettagliate (5-10 pagine)

  • Ogni problema documentato con screenshot, estratti dei log, metriche
  • Spiegazione tecnica accessibile (niente gergo inutile)
  • Gravità: Critico / Importante / Opportunità

3. Piano d'azione con priorità (2-3 pagine) Tabella: Azione | Impatto stimato | Complessità | Tempo | Costo

Esempio:

  • Aumentare pm.max_children da 5 a 30 | Riduzione del 70% degli errori 502 | Bassa | 10 min | Incluso
  • Aggiungere 3 indici MySQL sulla tabella orders | Query 50 volte più veloci | Media | 1 h | Incluso
  • Migrare a un server con 8 GB di RAM | Regge un carico 3 volte maggiore | Alta | 4 h | 150 € di migrazione

4. Raccomandazioni a lungo termine

  • Piano di monitoraggio continuo
  • Frequenza di aggiornamento consigliata
  • Roadmap di miglioramento su 6-12 mesi

Caso cliente concreto: e-commerce su WooCommerce

Contesto iniziale

Cliente: negozio online specializzato in prodotti artigianali, 500-800 visitatori/giorno, 5000 prodotti, carrello medio di 85 €.

Infrastruttura:

  • VPS OVH Comfort (4 vCPU, 4 GB di RAM)
  • Ubuntu 20.04, Nginx 1.18, PHP 7.4, MySQL 5.7
  • WordPress 6.1 + WooCommerce 7.5 + 15 plugin attivi

Sintomi segnalati

  • Picchi di lentezza ogni giorno tra le 14 e le 16 (pausa pranzo = traffico massimo)
  • Errori 502 Bad Gateway 2-3 volte al giorno, con necessità di riavviare PHP-FPM
  • Pagine prodotto che impiegano 6-8 secondi a caricarsi
  • Google Search Console segnala "Poor" sul 70% delle pagine (LCP > 4 s)
  • Frequenza di rimbalzo passata dal 45% al 62% in 3 mesi
  • Perdita stimata: 200-300 €/giorno di vendite mancate

Diagnosi dell'audit (2 h 30)

1. PHP-FPM: configurazione disastrosa

pm = dynamic
pm.max_children = 5 ATTENTION: (CRITIQUE)
pm.start_servers = 2
memory_limit = 128M

Calcolo: 5 processi figli × 128MB = 640MB al massimo per PHP, con 4 GB di RAM disponibili → appena arrivano 6 richieste simultanee, messa in coda → timeout 502

2. MySQL: query lente e indici mancanti

  • 847 query > 2 secondi nelle ultime 24 ore
  • Query su wp_postmeta senza indice: 3,8 s per filtrare per meta_key
  • innodb_buffer_pool_size = 128M (valore predefinito) a fronte di un database di 2,1 GB

3. Opcache PHP: disattivato

  • PHP ricompila tutti i file di WordPress/WooCommerce a ogni richiesta
  • Carico della CPU inutilmente moltiplicato di 8-10 volte

4. Nessuna cache applicativa

  • Nessun plugin di cache HTML (WP Super Cache, W3 Total Cache)
  • Ogni pagina ricalcolata a ogni visita, anche per i visitatori non loggati

5. Sicurezza debole

  • Fail2ban non installato: 3200 tentativi di login SSH al giorno
  • PHP 7.4: 12 CVE critiche senza patch (PHP 8.1 disponibile)

Correzioni applicate (3 h)

PHP-FPM (15 min)

pm.max_children = 30 (4GB RAM / 130MB par enfant)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Opcache (5 min)

opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 0 (prod)
opcache.enable_cli = 1

MySQL (45 min)

-- Ajout index manquant
ALTER TABLE wp_postmeta ADD INDEX meta_key_value (meta_key, meta_value(20));
-- Configuration
innodb_buffer_pool_size = 2G (50% de la RAM)
max_connections = 200
query_cache_size = 0 (inutile MySQL 5.7+)

Cache applicativa (30 min)

  • Installazione di WP Rocket (licenza del cliente)
  • Configurazione: cache HTML, minificazione CSS/JS, lazy loading delle immagini
  • Generazione della cache per le 500 pagine principali

Sicurezza (1 h)

  • Aggiornamento da PHP 7.4 → 8.1
  • Installazione di fail2ban con jail SSH + HTTP
  • Hardening SSH: root disattivato, solo chiavi
  • Backup automatici giornalieri su S3

Risultati misurati (dopo 7 giorni)

Prestazioni:

  • TTFB: ~~3,2 s~~ → 0,4 s (-87%)
  • LCP: ~~6,1 s~~ → 2,0 s (-67%)
  • Pagina prodotto: ~~7,2 s~~ → 1,8 s (-75%)
  • Core Web Vitals: ~~12% Good~~ → 89% Good

Stabilità:

  • Errori 502: ~~2-3/giorno~~ → 0 in 7 giorni
  • Load average: ~~4,5~~ → 0,8 (su 4 CPU)
  • RAM utilizzata: ~~92%~~ → 65%

Business:

  • Frequenza di rimbalzo: ~~62%~~ → 48% (-14 punti)
  • Tempo sul sito: +22%
  • Conversioni: +18% (calcolate su 7 giorni rispetto alla settimana precedente)
  • Stima: +280 €/giorno di fatturato, ossia +8400 €/mese

Sicurezza:

  • Tentativi SSH bloccati: 3200/giorno → 0 (IP bannati automaticamente)
  • Vulnerabilità CVE: ~~12 critiche~~ → 0

Costo totale: audit (490 €) + esecuzione (350 €) + licenza WP Rocket (59 €/anno) = 899 € IVA esclusa ROI: ripagato in 3 giorni di fatturato aggiuntivo


Audit del server vs altri tipi di audit

È importante distinguere bene i vari tipi di audit web, perché non coprono gli stessi aspetti:

Tipo di auditFocus principaleQuando farlo?Complementare a
Audit del serverInfrastruttura, prestazioni del server, configurazione PHP/MySQL, sicurezza del sistemaSito lento (TTFB > 600 ms), errori 502/504, server instabile, dopo un attacco informaticoAudit di sicurezza, audit delle prestazioni front-end
Audit di sicurezza applicativaVulnerabilità dell'applicazione (XSS, CSRF, SQLi), plugin obsoleti, backup, conformità GDPRPrima della messa in produzione, dopo un attacco, almeno 1 volta l'annoAudit del server, pentest
Audit SEOIndicizzazione, parole chiave, backlink, contenuti, meta tag, strutturaCalo di traffico, restyling del sito, nuovo sitoAudit delle prestazioni (Core Web Vitals = fattore SEO)
Audit delle prestazioni front-endOttimizzazione degli asset (immagini, CSS, JS), lazy loading, CDN, cache del browserLCP/FID/CLS scadenti, punteggi Lighthouse < 50Audit del server (TTFB)
Audit di accessibilitàWCAG, RGAA, navigazione da tastiera, screen readerObbligo di legge, miglioramento della UX, apertura al pubblico con disabilitàAudit UX

Il mio consiglio: se il tuo sito arranca, inizia sempre dall'audit del server. È inutile ottimizzare le immagini se il tuo TTFB è a 4 secondi per colpa di un PHP-FPM configurato male.


Checklist: ti serve un audit del server?

Rispondi onestamente alle domande seguenti. Se spunti 3 caselle o più, un audit del server è vivamente consigliato.

  • [ ] Il mio sito impiega più di 3 secondi a caricarsi con una buona connessione
  • [ ] Ho errori 502, 504 o 500 almeno una volta a settimana
  • [ ] Il mio server richiede un riavvio manuale almeno una volta al mese
  • [ ] Non conosco il valore di pm.max_children del mio PHP-FPM
  • [ ] Il mio sito rallenta molto quando ho più di 50 visitatori simultanei
  • [ ] Non ho mai ottimizzato il mio database MySQL
  • [ ] Il mio certificato SSL ha un voto < A su SSL Labs
  • [ ] Non aggiorno il sistema o PHP da più di 6 mesi
  • [ ] Non ho un sistema di backup automatico testato
  • [ ] Il mio provider di hosting mi ha già contattato per "utilizzo eccessivo delle risorse"
  • [ ] Google Search Console indica "Poor" sui miei Core Web Vitals
  • [ ] La mia frequenza di rimbalzo è aumentata di oltre il 10% negli ultimi mesi senza un motivo apparente

Punteggio:

  • 0-2 caselle: il tuo server sembra a posto, ma resta consigliabile un controllo preventivo ogni 12-18 mesi
  • 3-5 caselle: audit consigliato entro 1-2 mesi, probabilmente ci sono quick win facili da ottenere
  • 6+ caselle: audit urgente, probabilmente stai perdendo clienti e fatturato ogni giorno

Deliverable & svolgimento

Cosa ricevi

1. Report di audit completo (PDF di 15-25 pagine)

  • Executive summary con i 3 problemi più critici
  • Diagnosi dettagliate con screenshot ed estratti dei log
  • Piano d'azione ordinato per impatto/complessità
  • Raccomandazioni a lungo termine

2. File di configurazione ottimizzati

  • Configurazioni Nginx/Apache commentate e pronte per il deploy
  • Pool PHP-FPM dimensionato per il tuo server
  • File my.cnf di MySQL ottimizzato
  • Script di base per monitoraggio e alert

3. Documentazione delle procedure

  • Checklist per il deploy delle correzioni
  • Guida al rollback in caso di problemi
  • Procedura di ripristino dei backup

4. Follow-up dopo l'intervento (opzionale)

  • Accesso alla dashboard di monitoraggio per 30 giorni
  • Supporto via email per 7 giorni per le tue domande
  • Sessione di formazione di 30 min (configurazione, lettura delle metriche)

Svolgimento tipico

G0: primo contatto

  • Briefing telefonico o in videochiamata di 15 min per capire i tuoi problemi
  • Invio di un questionario tecnico preliminare
  • Preventivo entro 24 ore

Da G+1 a G+2: accessi & preparazione

  • Creazione degli accessi SSH/pannello
  • Installazione di strumenti di monitoraggio non intrusivi, se accetti
  • Raccolta dei log e delle metriche di riferimento

G+3: audit (2-4 ore)

  • Analisi approfondita di tutti i livelli (rete, server, PHP, MySQL, sicurezza)
  • Test di carico per individuare i limiti
  • Documentazione dei risultati in tempo reale

Da G+4 a G+5: stesura & presentazione

  • Stesura del report completo
  • Videochiamata di 30-45 min per presentare risultati e raccomandazioni
  • Risposte alle tue domande tecniche

G+6 (opzionale): esecuzione delle correzioni

  • Backup completo del sistema prima dell'intervento
  • Applicazione delle ottimizzazioni in ordine di priorità
  • Test di non regressione dopo ogni modifica
  • Misurazioni post-intervento: verifica del raggiungimento degli obiettivi

G+7: validazione & chiusura

  • Report di validazione con metriche prima/dopo
  • Trasferimento delle conoscenze e breve formazione
  • Documentazione finale + supporto per 7 giorni

Risultati tipici dopo audit + ottimizzazione

Sulla base di oltre 40 audit di server realizzati dal 2020, ecco i miglioramenti medi riscontrati:

Prestazioni

  • TTFB ridotto dal 30 al 70%: in media da 1,5-3 s a 0,3-0,8 s
  • LCP migliorato del 40-60%: la maggior parte dei siti passa da "Poor" a "Good" (< 2,5 s)
  • Capacità di carico moltiplicata per 3-5: un server che andava in crash con 30 visitatori simultanei ora ne regge 100-150
  • Scomparsa degli errori 5xx: il 90% dei siti non ha più alcun errore 502/504 dopo l'ottimizzazione

Sicurezza

  • Riduzione di oltre il 95% dei tentativi di intrusione grazie a fail2ban
  • Superficie di attacco ridotta: chiusura delle porte inutili, aggiornamenti di sicurezza applicati
  • Voto SSL che passa da B/C ad A+ grazie all'hardening TLS
  • Conformità rafforzata: GDPR (cifratura, backup), PCI DSS (per gli e-commerce)

Costi

  • 30-50% di risparmio sull'infrastruttura: spesso evita un costoso upgrade del server
  • Riduzione del 70-80% del tempo di manutenzione: meno emergenze da spegnere, monitoraggio proattivo
  • ROI medio: 3-6 mesi per un e-commerce (grazie all'aumento delle conversioni)

SEO & conversione

  • Aumento del traffico organico del 15-30% grazie ai Core Web Vitals (fattore di ranking di Google)
  • Calo della frequenza di rimbalzo di 10-20 punti: i visitatori non abbandonano più per la lentezza
  • Aumento del tasso di conversione del 10-25%: un sito veloce converte meglio

Ambienti supportati

Sistemi operativi

  • Ubuntu 18.04, 20.04, 22.04, 24.04 LTS
  • Debian 10, 11, 12
  • Altre distribuzioni Linux su richiesta (CentOS, Rocky Linux, Alpine)

Hosting & infrastrutture

  • OVH / OVHcloud (VPS, Dedicated, Public Cloud)
  • Scaleway (Instances, Elastic Metal)
  • Contabo (VPS, Dedicated)
  • Hetzner (Cloud, Dedicated)
  • DigitalOcean, Linode, Vultr
  • Server dedicati on-premise

Pannelli di amministrazione

  • Plesk Obsidian
  • ISPConfig 3.x
  • cPanel/WHM (meno esperienza, ma fattibile)
  • Configurazione manuale (senza pannello): la mia preferita per le massime prestazioni

Server web

  • Nginx 1.18+ (consigliato per le prestazioni)
  • Apache 2.4+ con MPM Event o Worker
  • OpenLiteSpeed (su richiesta)
  • Configurazioni ibride (Nginx come reverse proxy + Apache come backend)

PHP

  • PHP 7.4, 8.0, 8.1, 8.2, 8.3 (tutte le versioni FPM)
  • Supporto di più versioni di PHP in parallelo
  • Estensioni: opcache, APCu, Redis, Memcached, imagick, ecc.

Database

  • MySQL 5.7, 8.0+
  • MariaDB 10.3, 10.5, 10.6, 10.11+
  • PostgreSQL (su richiesta, meno esperienza rispetto a MySQL)

Applicazioni web più diffuse

  • WordPress / WooCommerce (l'80% della mia esperienza)
  • Magento 2.x
  • PrestaShop 1.7, 8.x
  • Drupal 9, 10
  • Laravel, Symfony, CodeIgniter (framework PHP)
  • Applicazioni PHP su misura

Prezzi & tempi

Pacchetti di audit

Audit Essenziale – 390 € IVA esclusa

  • Server semplice: 1 sito, stack standard (Nginx/Apache + PHP + MySQL)
  • 2-3 ore di analisi
  • Report di 10-15 pagine con piano d'azione prioritizzato
  • File di configurazione ottimizzati inclusi
  • Ideale per: sito vetrina, blog, piccolo e-commerce (< 1000 visitatori/giorno)

Audit Avanzato – 690 € IVA esclusa

  • Server complesso: multi-sito, configurazioni personalizzate, traffico elevato
  • 4-6 ore di analisi approfondita
  • Report di 20-30 pagine + test di carico + profiling applicativo
  • Raccomandazioni sull'architettura (Redis, CDN, load balancing)
  • Presentazione dei risultati in videochiamata (1 ora)
  • Ideale per: e-commerce medi/grandi, SaaS, applicazioni gestionali

Audit + Esecuzione – Su preventivo (in genere 900-1500 € IVA esclusa)

  • Audit Avanzato + applico io stesso le correzioni
  • Backup completo prima dell'intervento
  • Test di non regressione
  • Misurazioni prima/dopo con report di validazione
  • Supporto per 7 giorni dopo l'intervento
  • Ideale se: non hai competenze sistemistiche interne

Audit Urgente (< 24 h) – Tariffa × 1,5

  • Intervento entro 24 ore (giorni lavorativi)
  • Report express entro 48 ore
  • Ideale per: crisi in corso, sito down, attacco recente

Opzioni aggiuntive

  • Sessione di formazione (1 ora): +150 € IVA esclusa
    • Lettura delle metriche, uso del monitoraggio, manutenzione preventiva
  • Supporto di manutenzione mensile: a partire da 200 € IVA esclusa/mese
    • Aggiornamenti di sicurezza mensili
    • Monitoraggio 24/7 con alert
    • Interventi correttivi inclusi (fino a 2 ore/mese)
  • Audit di follow-up (dopo 6 mesi): -50% sulla tariffa iniziale
    • Verifica che le ottimizzazioni reggano nel tempo
    • Aggiustamenti in caso di variazioni del traffico

Tempi standard

  • Preventivo: entro 24 ore dal briefing iniziale
  • Accessi & preparazione: da G+1 a G+2
  • Audit: G+3 (2-4 ore di lavoro concentrato)
  • Consegna del report: da G+4 a G+5
  • Esecuzione (se scelta): G+6
  • Validazione finale: G+7

Tempo totale: in media 7 giorni lavorativi, 3-4 giorni in caso di urgenza.

Cosa è incluso in tutte le tariffe

Analisi completa dei 7 livelli (rete, server, PHP, MySQL, sicurezza, prestazioni, monitoraggio) Report PDF dettagliato con screenshot e raccomandazioni concrete File di configurazione ottimizzati pronti per il deploy Presentazione dei risultati in videochiamata di 30 min (pacchetto Avanzato e superiori) 1 giro di domande e risposte via email dopo la consegna

Metodi di pagamento

  • Bonifico bancario (IBAN indicato in fattura)
  • Carta di credito tramite Stripe (link di pagamento sicuro)
  • PayPal (aziende francesi)

Condizioni: 50% all'ordine (dopo l'accettazione del preventivo), 50% alla consegna del report.


Domande frequenti

Cosa copre esattamente l'audit del server web?

L'audit analizza 7 livelli tecnici: protocollo di rete (TLS/HTTP2), configurazione del server web (Nginx/Apache), ottimizzazione di PHP-FPM (pm.*, opcache), database MySQL (query lente, indici mancanti), sicurezza del sistema (fail2ban, firewall, aggiornamenti), prestazioni applicative (TTFB, Core Web Vitals) e monitoraggio (log, metriche, alert). Ricevi un report dettagliato con un piano d'azione prioritizzato.

Puoi correggere i problemi trovati o solo individuarli?

Entrambe le cose. I pacchetti "Audit Essenziale" e "Avanzato" individuano i problemi e forniscono i file di configurazione ottimizzati che il tuo team tecnico può applicare. Il pacchetto "Audit + Esecuzione" prevede che sia io ad applicare le correzioni, con backup preliminare, test di non regressione e misurazioni prima/dopo. È l'opzione consigliata se non hai un sistemista interno.

Quali sono i tempi e il costo di un audit?

Audit di base a partire da 390 € IVA esclusa per un server semplice, realizzato entro 7 giorni lavorativi (urgenza in 24 ore possibile con un supplemento). Il pacchetto "Audit + Esecuzione" è su preventivo (in genere 900-1500 € IVA esclusa) in base alla complessità. Un briefing iniziale gratuito di 15 min permette di preparare un preventivo preciso entro 24 ore.

Devo mettere offline il mio sito durante l'audit?

No, l'audit non è invasivo. L'analisi avviene principalmente tramite SSH in sola lettura (log, configurazioni, metriche). I test di carico si fanno d'accordo con te e, se preferisci, possono essere pianificati nelle ore di minor traffico. Solo l'esecuzione delle correzioni (pacchetto opzionale) può richiedere 2-5 minuti di indisponibilità per riavviare alcuni servizi (PHP-FPM, MySQL), e viene pianificata in anticipo.

Il mio server è su OVH/Scaleway/altro: è un problema?

Assolutamente no. Lavoro regolarmente con OVH, Scaleway, Hetzner, Contabo, DigitalOcean e altri provider di hosting standard. L'audit è indipendente dall'hosting, purché io abbia un accesso SSH o al pannello (Plesk, ISPConfig). Se il tuo hosting è molto particolare (es.: hosting gestito su AWS con restrizioni), un briefing preliminare permetterà di verificarne la fattibilità.

Cosa succede se trovi falle di sicurezza critiche?

Ti avviso immediatamente (anche prima della fine dell'audit completo) se rilevo una vulnerabilità critica sfruttabile attivamente (backdoor, versione di PHP con una CVE critica già sfruttata in circolazione, server completamente aperto). Il report include poi un piano d'azione prioritizzato con le correzioni urgenti in cima alla lista. Con il pacchetto "Audit + Esecuzione", posso applicare le patch di sicurezza in via prioritaria non appena individuate.

L'audit copre anche l'ottimizzazione del codice della mia applicazione?

L'audit del server si concentra sull'infrastruttura e sulla configurazione del sistema (server, PHP, MySQL). Posso rilevare che una pagina esegue 150 query SQL o che alcune funzioni PHP sono lente (tramite profiling), ma l'ottimizzazione dettagliata del codice applicativo (refactoring, riscrittura di query complesse) richiede un audit applicativo dedicato. Detto questo, l'80% dei problemi di prestazioni deriva dalla configurazione del server, quindi l'audit risolve la maggior parte dei casi.

Offri una garanzia sui risultati?

Garantisco che il report conterrà raccomandazioni concrete e misurabili. Per il pacchetto "Audit + Esecuzione", mi impegno su obiettivi numerici definiti insieme in anticipo (es.: TTFB < 400 ms, 0 errori 502 per 7 giorni, Core Web Vitals "Good" su oltre l'80% delle pagine). Se dopo l'intervento gli obiettivi non vengono raggiunti, riprendo l'ottimizzazione senza costi aggiuntivi fino alla tua piena soddisfazione.

Posso avere un esempio di report di audit?

Sì, su richiesta posso inviarti via email un report anonimizzato (dati del cliente oscurati), che ti darà un'idea precisa del livello di dettaglio e del formato. Contattami a [il tuo indirizzo email] con oggetto "Esempio report audit".

Offri un follow-up o la manutenzione dopo l'audit?

Sì, con diverse opzioni:

  • Supporto post-audit incluso: 7 giorni di domande/risposte via email dopo la consegna
  • Audit di follow-up a 6 mesi: -50% sulla tariffa iniziale per verificare che tutto regga nel tempo
  • Manutenzione mensile: a partire da 200 €/mese, con aggiornamenti di sicurezza, monitoraggio 24/7 e interventi correttivi (fino a 2 ore/mese)

Il mio sito è su WordPress/Shopify/un altro CMS: cambia qualcosa?

L'audit del server è indipendente dal CMS, perché si concentra sul livello di sistema (Linux, Nginx, PHP, MySQL). Tuttavia, la mia solida esperienza su WordPress/WooCommerce (l'80% dei miei audit) mi permette di andare oltre: posso analizzare i plugin problematici, ottimizzare il database di WP (wp_options, transient), configurare una cache a oggetti (Redis), ecc. Per Shopify in hosting, l'audit del server non è applicabile (infrastruttura gestita da Shopify), ma posso analizzare le app Shopify personalizzate se sono ospitate sul tuo server.

Di quali accessi hai bisogno sul mio server?

Requisiti minimi:

  • Accesso SSH (account utente con sudo, oppure root se lo accetti) tramite una chiave pubblica che ti fornisco
  • Accesso in lettura ai log (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
  • Credenziali MySQL in sola lettura per analizzare le slow query

Facoltativo (ma consigliato):

  • Accesso al pannello (Plesk, ISPConfig), se presente
  • Credenziali del CMS (admin di WordPress) per i test in condizioni reali
  • Accesso a Google Search Console / Analytics per correlare i dati con le metriche di business

Sicurezza: tutti gli accessi forniti vengono eliminati immediatamente dopo l'audit (entro 48 ore al massimo). Su richiesta si può firmare un NDA.


Se cerchi soluzioni complementari, dai un'occhiata anche a:


Pronto a dare una spinta alle prestazioni e alla sicurezza del tuo server? Richiedi il tuo audit gratuito