WordPress \u00e8 un CMS potente ma esigente: per funzionare al meglio necessita di un ambiente server adeguatamente configurato. I requisiti minimi ufficiali includono PHP 7.4 o superiore (consigliato PHP 8.1+), MySQL 5.7 o MariaDB 10.4+, e supporto HTTPS. Tuttavia, per un sito professionale, questi valori rappresentano solo il punto di partenza. La memoria PHP consigliata \u00e8 di almeno 128 MB per sito, ma con plugin complessi e temi page builder si sale rapidamente a 256 o 512 MB. La CPU incide soprattutto sui picchi di traffico: un sito condiviso su server economici soffre durante i momenti di alta richiesta.<\/p>\n
La scelta della versione PHP \u00e8 critica: PHP 8.x offre miglioramenti prestazionali fino al 30% rispetto a PHP 7.4 grazie al JIT compiler. Verificate sempre che il vostro hosting supporti le versioni pi\u00f9 recenti e che i plugin e il tema siano compatibili. Strumenti come “Health Check & Troubleshooting” di WordPress aiutano a diagnosticare problemi di compatibilit\u00e0.<\/p>\n
L’infrastruttura di hosting \u00e8 la base su cui poggia tutto il resto. La scelta tra hosting condiviso, VPS, dedicato e cloud dipende dal volume di traffico, dal budget e dalle competenze tecniche.<\/p>\n
Economico e gestito, ideale per siti piccoli o in fase di lancio. Le risorse (CPU, RAM, I\/O) sono condivise tra centinaia di utenti. Se un sito vicino assorbe traffico, il vostro ne risente. Adatto per blog personali o siti vetrina con poche visite giornaliere.<\/p>\n
Offre risorse dedicate all’interno di un ambiente virtualizzato. Ogni VPS ha CPU, RAM e storage assegnati, senza competizione con altri utenti. \u00c8 la scelta pi\u00f9 bilanciata per siti in crescita. Richiede competenze di amministrazione Linux o un pannello come Plesk, cPanel o RunCloud.<\/p>\n
Una macchina fisica interamente per voi. Massime prestazioni e controllo totale. Necessario per siti con centinaia di migliaia di visite mensili, e-commerce pesanti o applicazioni custom. Costo elevato e gestione complessa.<\/p>\n
Piattaforme come AWS, Google Cloud, DigitalOcean o Linode offrono scalabilit\u00e0 orizzontale. Si paga a consumo e si possono aggiungere risorse al volo. Ottimo per siti con traffico variabile. Servono competenze DevOps per configurare correttamente load balancer, auto-scaling e caching distribuito.<\/p>\n
Il web server \u00e8 il primo punto di contatto con i visitatori. La configurazione influisce direttamente sui tempi di risposta e sulla capacit\u00e0 di gestire richieste concorrenti.<\/p>\n
Apache \u00e8 tradizionale, funziona con .htaccess, ed \u00e8 pi\u00f9 facile da configurare. Nginx \u00e8 event-driven, consuma meno memoria e gestisce pi\u00f9 connessioni simultanee con minori risorse. Per WordPress, Nginx con PHP-FPM \u00e8 considerato lo stack pi\u00f9 performante. Apache con mod_php \u00e8 pi\u00f9 semplice ma meno efficiente sotto carico. Una configurazione ibrida (Nginx come reverse proxy con Apache dietro) unisce flessibilit\u00e0 e prestazioni.<\/p>\n
PHP-FPM separa l’esecuzione PHP dal web server. I parametri cruciali sono pm.max_children, pm.start_servers, pm.min_spare_servers e pm.max_spare_servers. Un valore troppo basso causa errori “502 Bad Gateway” sotto carico; troppo alto esaurisce la RAM. Per un VPS con 2 GB di RAM, un buon punto di partenza \u00e8 max_children = 10, con processi dinamici. Usate strumenti come htop e il log di PHP-FPM per monitorare l’utilizzo.<\/p>\n
Abilitate la compressione Gzip a livello server per ridurre la dimensione dei file trasferiti. Nginx: gzip on; gzip_types text\/css application\/javascript image\/svg+xml;. Per le risorse statiche (CSS, JS, immagini), impostate header Cache-Control con expiry lungo. Plugin come WP Rocket o Flying Press gestiscono automaticamente il caching lato server, ma una configurazione manuale su Nginx con FastCGI Cache elimina la necessit\u00e0 di plugin.<\/p>\n
Il database MySQL o MariaDB \u00e8 spesso il collo di bottiglia nascosto. WordPress esegue numerose query per ogni pagina; un database ottimizzato riduce i tempi di caricamento in modo significativo.<\/p>\n
InnoDB \u00e8 il motore predefinito e consigliato. Il parametro innodb_buffer_pool_size dovrebbe occupare il 70-80% della RAM disponibile (escludendo quella riservata a PHP e OS). Su un server con 4 GB di RAM, impostate 2-3 GB. La query cache (query_cache_type e query_cache_size) \u00e8 deprecata da MySQL 8, ma su MariaDB \u00e8 ancora utile. Attivate query_cache_type = 1 con una dimensione di 64-128 MB per siti con molte letture.<\/p>\n
innodb_log_file_size = 256 MB per gestire scritture pesanti senza attriti. innodb_flush_method = O_DIRECT per bypassare il filesystem cache. innodb_file_per_table = ON per gestire singole tabelle. Disabilitate innodb_flush_log_at_trx_commit = 2 se la durabilit\u00e0 immediata non \u00e8 critica (raddoppia le prestazioni di scrittura). Usate lo script mysqltuner.pl per ricevere raccomandazioni personalizzate.<\/p>\n
Plugin come WP-Optimize o Advanced Database Cleaner eliminano revisioni, post spam e transient scaduti. Pianificate pulizie settimanali. Le tabelle wp_options e wp_postmeta crescono rapidamente; ottimizzatele con OPTIMIZE TABLE. Per database molto grandi, valutate l’indicizzazione personalizzata delle meta query pi\u00f9 frequenti.<\/p>\n
Il kernel Linux offre parametri regolabili per migliorare le prestazioni del server WordPress.<\/p>\n
vm.swappiness controlla la propensione del kernel a usare la swap. Su un server dedicato, impostate vm.swappiness = 10 (valore predefinito 60). Questo riduce l’uso della swap e mantiene i dati in RAM, dove l’accesso \u00e8 pi\u00f9 veloce. Per server con molta RAM, potete scendere a 5 o addirittura 0.<\/p>\n
Il limite di file descriptors (ulimit -n) deve essere alto per gestire molte connessioni simultanee. Impostate fs.file-max = 100000 in \/etc\/sysctl.conf. Per Nginx, aumentate worker_connections a 1024 o pi\u00f9. Anche il net.core.somaxconn (coda di connessioni in attesa) va portato ad almeno 1024 per evitare rifiuti di connessione sotto carico.<\/p>\n
net.ipv4.tcp_tw_reuse = 1 per riutilizzare i socket TIME_WAIT. net.core.rmem_max e net.core.wmem_max = 16777216 per buffer di rete pi\u00f9 grandi. net.ipv4.tcp_congestion_control = bbr (BBR congestion control) migliora la velocit\u00e0 percepita su connessioni con perdita di pacchetti. Applicate con sysctl -p e verificate con sysctl Il file php.ini contiene decine di parametri che influenzano WordPress. I pi\u00f9 importanti sono raggruppabili in tre aree: limiti di risorse, gestione upload e caching delle opcode.<\/p>\n memory_limit = 256M (o 512M per siti complessi). max_execution_time = 120 secondi per permettere operazioni lunghe (import, backup, aggiornamenti). max_input_time = 120. Questi valori si impostano nel php.ini principale o tramite wp-config.php con define(‘WP_MEMORY_LIMIT’, ‘256M’);.<\/p>\n upload_max_filesize = 64M (per caricare temi, plugin e media pesanti). post_max_size = 64M (deve essere >= upload_max_filesize). max_file_uploads = 20 (numero massimo di file per richiesta). Se usate un CDN per media, potete tenere valori pi\u00f9 bassi.<\/p>\n OPcache memorizza il bytecode compilato di PHP in RAM, eliminando la ricompilazione a ogni richiesta. Configurazione consigliata: opcache.enable=1, opcache.memory_consumption=128, opcache.max_accelerated_files=4000, opcache.revalidate_freq=60. Su server con molti plugin, aumentate memory_consumption a 256 MB e max_accelerated_files a 10000. Disabilitate opcache.validate_timestamps in produzione per massime prestazioni (ma ricordatevi di svuotare la cache dopo aggiornamenti).<\/p>\n L’ottimizzazione non \u00e8 un’operazione una tantum. Strumenti di monitoraggio aiutano a identificare colli di bottiglia prima che diventino critici.<\/p>\n htop, iotop e nload danno una panoramica in tempo reale di CPU, I\/O disco e banda di rete. Per monitoraggio storico, Netdata o Prometheus con Grafana sono la scelta professionale. New Relic e Datadog offrono piani gratuiti con tracciamento delle transazioni PHP. Dal lato WordPress, il plugin Query Monitor mostra query lente, hook dispendiosi e warning PHP in tempo reale.<\/p>\n Impostate alert per: utilizzo CPU > 80% per 5 minuti, RAM libera < 256 MB, spazio disco < 10%, e tempi di risposta HTTP > 2 secondi. Servizi come UptimeRobot o Better Uptime inviano notifiche su Telegram, email o Slack. Con un monitoraggio solido, potete intervenire prima che gli utenti notino rallentamenti.<\/p>\n Ottimizzare un server WordPress \u00e8 un lavoro a pi\u00f9 livelli: sistema operativo, web server, database e PHP devono lavorare in sintonia. Non serve essere esperti DevOps per ottenere miglioramenti significativi. Partite dai requisiti minimi, scegliete l’hosting adatto alle vostre esigenze, configurate Nginx con PHP-FPM, ottimizzate InnoDB per il database, regolate i parametri del kernel e impostate OPcache. Ogni passo riduce i millisecondi di caricamento e aumenta la capacit\u00e0 di gestire traffico. Misurate prima e dopo ogni modifica con strumenti come Lighthouse o WebPageTest per verificare i miglioramenti. Un server ben configurato \u00e8 il fondamento di un sito WordPress veloce, sicuro e scalabile.<\/p>","protected":false},"excerpt":{"rendered":" Requisiti server per WordPress WordPress \u00e8 un CMS potente ma esigente: per funzionare al meglio necessita di un ambiente server adeguatamente configurato. I requisiti minimi ufficiali includono PHP 7.4 o superiore (consigliato PHP 8.1+), MySQL 5.7 o MariaDB 10.4+, e supporto HTTPS. Tuttavia, per un sito professionale, questi valori rappresentano solo il punto di partenza. […]<\/p>\n","protected":false},"author":1,"featured_media":2073,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_gspb_post_css":"","ai_primary_source":"Studio Immens Blog","visibility_scope":"both","ai_summary":"Requisiti server per WordPress WordPress \u00e8 un CMS potente ma esigente: per funzionare al meglio necessita di un ambiente server adeguatamente configurato. I requisiti minimi ufficiali includono PHP 7.4 o superiore (consigliato PHP 8.1+), MySQL 5.7 o MariaDB 10.4+, e supporto HTTPS. Tuttavia, per ...","ai_intent":"informative","ai_related_resources":"","ai_priority":5,"ai_entity_type":"Article","ai_is_based_on":"https:\/\/blog.studioimmens.com\/ottimizzare-il-server-per-wordpress\/","ai_citations":"","ai_mentions":"","ai_speakable_selector":"","ai_chunk_hints":"Ottimizzare, il, server, per","footnotes":""},"categories":[40],"tags":[],"ai_visibility":[],"class_list":["post-1916","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sviluppo-web"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/posts\/1916","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/comments?post=1916"}],"version-history":[{"count":0,"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/posts\/1916\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/media\/2073"}],"wp:attachment":[{"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/media?parent=1916"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/categories?post=1916"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/tags?post=1916"},{"taxonomy":"ai_visibility","embeddable":true,"href":"https:\/\/studioimmens.com\/en\/wp-json\/wp\/v2\/ai_visibility?post=1916"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Configurazione PHP<\/h2>\n
Limiti di memoria e tempo<\/h3>\n
Upload e file<\/h3>\n
OPcache<\/h3>\n
Monitoraggio della salute del server<\/h2>\n
Conclusioni<\/h2>\n