{"id":16,"date":"2026-02-22T09:16:54","date_gmt":"2026-02-22T08:16:54","guid":{"rendered":"https:\/\/seocodice.online\/seoblog\/?p=16"},"modified":"2026-02-22T10:31:05","modified_gmt":"2026-02-22T09:31:05","slug":"wordpress-100-100-pagespeed-il-case-study","status":"publish","type":"post","link":"https:\/\/seocodice.online\/seoblog\/wordpress-100-100-pagespeed-il-case-study\/","title":{"rendered":"WordPress 100\/100 PageSpeed: il Case Study"},"content":{"rendered":"

Il 22 febbraio 2026 abbiamo pubblicato il primo articolo su SEOCodice e \u2014 prima ancora di promuoverlo \u2014 abbiamo aperto PageSpeed Insights. Il punteggio era 91\/100 su mobile<\/strong>. Per un blog appena nato, gi\u00e0 un risultato straordinario. Ma non era abbastanza: l’obiettivo era dimostrare che un WordPress costruito con la metodologia Infrastructure-First SEO<\/a> pu\u00f2 competere con qualsiasi framework statico. Questo \u00e8 il diario tecnico di come siamo arrivati a 100\/100<\/strong> in meno di 24 ore, senza plugin di cache, senza CDN, senza magie.<\/p>\r\n

<\/p>\r\n

\r\n

Qual era il punto di partenza e cosa mostrava il report?<\/h2>\r\n

Il primo report PageSpeed Insights registrava questi valori su dispositivi mobili:<\/p>\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
Metrica<\/th>\r\nValore iniziale<\/th>\r\nSoglia Google “Buono”<\/th>\r\nStato<\/th>\r\n<\/tr>\r\n<\/thead>\r\n
First Contentful Paint<\/td>\r\n0,8 s<\/td>\r\n< 1,8 s<\/td>\r\n\u2705<\/td>\r\n<\/tr>\r\n
Largest Contentful Paint<\/td>\r\n3,0 s<\/td>\r\n< 2,5 s<\/td>\r\n\ud83d\udd34<\/td>\r\n<\/tr>\r\n
Total Blocking Time<\/td>\r\n0 ms<\/td>\r\n< 200 ms<\/td>\r\n\u2705<\/td>\r\n<\/tr>\r\n
Cumulative Layout Shift<\/td>\r\n0,183<\/td>\r\n< 0,1<\/td>\r\n\ud83d\udd34<\/td>\r\n<\/tr>\r\n
Speed Index<\/td>\r\n0,8 s<\/td>\r\n< 3,4 s<\/td>\r\n\u2705<\/td>\r\n<\/tr>\r\n
Punteggio Performance<\/strong><\/td>\r\n91<\/strong><\/td>\r\n90\u2013100<\/strong><\/td>\r\n\ud83d\udfe1<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

Tre problemi principali emergevano dalla sezione Approfondimenti:<\/p>\r\n

    \r\n
  1. LCP 3,0s<\/strong>: l’immagine in evidenza non era precaricata<\/li>\r\n
  2. Cache browser assente<\/strong>: nessun header di scadenza sulle risorse statiche (349 KiB sprecati ad ogni visita)<\/li>\r\n
  3. CSS render-blocking<\/strong>: il foglio di stile bloccava il rendering per ~130ms<\/li>\r\n<\/ol>\r\n

    Come funziona la diagnosi Infrastructure-First SEO sulla performance?<\/h2>\r\n

    Prima di toccare il codice, abbiamo applicato il protocollo diagnostico dell’Infrastructure-First SEO<\/a>: analisi layer per layer, dal pi\u00f9 esterno al pi\u00f9 interno.<\/p>\r\n

      \r\n
    1. Layer rete<\/strong>: DNS, TTFB, cache<\/li>\r\n
    2. Layer rendering<\/strong>: risorse bloccanti, ordine di caricamento<\/li>\r\n
    3. Layer visuale<\/strong>: LCP element, CLS sources<\/li>\r\n
    4. Layer codice<\/strong>: asset inutili, richieste esterne<\/li>\r\n<\/ol>\r\n

      Questo approccio \u2014 infrastruttura prima, contenuto dopo \u2014 \u00e8 esattamente ci\u00f2 che separa un’ottimizzazione sistematica da una serie di tentativi casuali.<\/p>\r\n

      Fix 1: Come abbiamo eliminato il problema della cache in 10 righe di Apache?<\/h2>\r\n

      Il sito non aveva un file .htaccess<\/code> ottimizzato. Ogni visita scaricava le stesse immagini, gli stessi font, lo stesso CSS da zero. La soluzione: un .htaccess<\/code> con tre blocchi precisi. GZIP\/Deflate<\/strong> per comprimere HTML, CSS, JS, JSON, SVG in transito (~70% di risparmio sui file di testo). Cache-Control headers<\/strong> via mod_headers<\/code>:<\/p>\r\n