Performance · 27 maggio 2026
Snapshot delle prestazioni di amedani.com al 27 maggio. Il punteggio PageSpeed mobile della home mostra una forte fluttuazione sulla stessa URL nello spazio di pochi minuti — oscillazioni del 40–82 — laddove fino a circa una settimana fa il sito si attestava stabilmente su un punteggio di 70+. Il dato è in via di stabilizzazione lato sviluppo: durante la sessione di analisi di oggi sono già stati portati a regime due interventi (compressione del font hero, riduzione del buffer del video di copertura) che hanno migliorato lo Speed Index. Restano due aree da indagare per chiudere il ciclo: il comportamento dell'adapter Cloudflare/Astro modificato di recente e l'impatto del blocco automatico di Iubenda sul caricamento iniziale.
01
Cosa sta succedendo
Il sito al 27 maggio segna un quadro prestazionale diverso da quello osservato sette giorni fa nel check del 19. Il dato non è ancora stabilizzato: durante la stessa sessione di test si è osservato un range di punteggi mobile che varia del 50% sulla stessa URL. Diagnosi in corso, due cause sospette già parzialmente affrontate.
02
Il pattern di fluttuazione
La caratteristica peculiare del problema è la fluttuazione. Non si tratta di un calo netto e stabile (che indicherebbe una causa unica e facilmente isolabile), ma di un punteggio che oscilla del 50% sulla stessa URL nello spazio di minuti. È il segnale di una causa intermittente, non strutturale.
Nel rendering catturato da Lighthouse, le prime due slide del filmstrip sono completamente bianche: il browser ha ricevuto la pagina ma non ha ancora dipinto contenuti. Le slide successive iniziano a mostrare contenuto. Durante la sessione, dopo gli interventi di compressione del font, il primo frame ha iniziato a mostrare già la scritta principale — un piccolo guadagno percettivo, ma significativo per il calcolo di LCP e Speed Index.
Nella stessa finestra di test sono state misurate anche le altre property dell'ecosistema. Anche StudioUp ha mostrato fluttuazione sulla stessa URL — 70/100 sui run desktop, 85 mobile in alcuni run dopo essere stato a 70 — senza alcuna modifica recente al sito. Questo è un dato importante: parte della variabilità potrebbe non dipendere dal sito ma da come Google ha indurito recentemente le regole di Page Speed, o da bias temporanei del servizio. Va tenuto presente come variabile esogena prima di attribuire tutto al sito.
| Metrica | Stato | Lettura |
|---|---|---|
| CLS · Layout shift | stabile 0 | Tenuta visiva ottima. Rimozione dell'intro animata pagante. |
| FCP · First Contentful Paint | buono | Il primo paint è rapido. Il rallentamento avviene dopo. |
| TBT · Total Blocking Time | contenuto | Il JavaScript non sta bloccando in modo significativo il main thread. |
| Byte scaricati | in calo | Dopo gli interventi di compressione font è già sceso. Miglioramento oggettivo lato peso. |
03
Quattro cause sospette · ordine di plausibilità
Quattro ipotesi sul tavolo, di cui due già parzialmente affrontate durante la sessione. La prima è la più probabile in quanto coincide temporalmente con la regressione osservata.
prerender: true non è più applicata a tutta la sitemap come prima, alcune pagine vengono ora servite in modalità non statica. Questo cambia il tempo di risposta lato server e il tipo di rendering che Page Speed osserva. È l'ipotesi più probabile perché coincide nel tempo con il momento in cui le prestazioni hanno iniziato a regredire.Va tenuta in conto un'ipotesi alternativa: la fluttuazione potrebbe in parte dipendere da cambi recenti nel motore di misurazione di PageSpeed, non dal sito. Lo stesso pattern di oscillazione si è osservato su StudioUp (sito non toccato di recente), che ha fatto 70/100/85 a distanza di pochi run. Questo è un segnale a favore della tesi "lato Google", che però non esclude le altre — le ipotesi 1 e 4 sopra restano valide. La risposta più onesta è: probabilmente entrambe le cose contribuiscono, in proporzioni che si chiariranno solo con più giorni di osservazione.
04
Cosa è già stato fatto durante la sessione
Cronologia dei due interventi tecnici applicati durante la sessione di analisi del 27 maggio, con il risultato osservato in tempo reale dopo il deploy.
truetype, font-display: block → woff, font-display: swap
+8 punti mobilemisurazione successiva: 52 → 60
05
Aree di lavoro proposte
Le attività proposte per chiudere il ciclo della regressione e tornare a un benchmark stabile. La sequenza è: osservazione su più giorni → audit mirato sulle ipotesi 1 e 4 → ottimizzazioni puntuali → ricontrollo della cartella foto/video (collegato al check del 19 maggio).
prerender: true e con che impatto sui tempi di risposta server-side. È l'ipotesi con la plausibilità più alta perché coincide nel tempo con la regressione. Se confermata, valutare un'iterazione che mantenga la fix delle form ma riapplichi il prerender alle pagine che ne traevano vantaggio.
/servizi/produzione-foto-video-aziendali/, con LCP a 7,4 secondi. Verificare lo stato attuale di quell'immagine specifica e di quelle sulle altre pillar di servizio (grafica, siti web, social media): la regressione di oggi potrebbe avere componenti che si sommano a quel problema preesistente. Audit Lighthouse mirato sulle 4 pillar.
PageSpeed Insights · Lighthouse audit · ispezione network e codice via DevTools · confronto cross-property con StudioUp come controllo · cronologia commit lato sviluppo.
Sito online da circa 60 giorni · indicizzazione 87% (check 19.05). Performance in stabilizzazione dopo regressione osservata · benchmark da ricostituire su finestra di 5–7 giorni.
Audit adapter Cloudflare/Astro · audit immagini pillar (parallelo al check 19.05) · quantificazione impatto Iubenda · monitoraggio periodico continuativo.
Amedani Studio · Performance · 27 maggio 2026