Come velocizzare un negozio Magento in 2026: Il Performance Playbook per 2.4.8 - IT

La maggior parte delle guide rapide di Magento si aprono con “svuota la cache.” Salta questo consiglio. Nel momento in cui la memorizzazione nella cache diventa il collo di bottiglia, hai già perso l'argomento dello stack. Un ritardo di un secondo costa ai negozi Magento 7% di conversioni, e Tideways’ Q2 2025 il benchmark mostra il più lento 25% di Magento 2 negozi che raggiungono il TTFB di 3 secondi nelle loro pagine peggiori. Il 2026 vince dal vivo nello stack di hosting (PHP 8.3+, walkie-talkie 8, Vernice 7.6) e in quello che fai prima che arrivi la prima richiesta. Magento 2.4.8 (attualmente stabile a marzo 2026) parte fissa di esso. Il resto è a carico del proprietario del negozio.

Risposta rapida: Esegui Magento 2.4.8 sopra PHP 8.3+ con walkie-talkie 8 gestione della cache, Vernice 7.6 facendo a pagina intera, e OpenSearch 2.19 potenziare la ricerca nel catalogo. Cambia la vetrina su Hyvä se le entrate giustificano il progetto. Buoni siti colpiti 65% eccellenti Core Web Vitals contro 41% è Luma. Ogni passaggio seguente ha un punteggio rispetto a quella linea di base.

Ultima revisione: aprile 2026. Numeri di versione, pila di cache, e dati di benchmark verificati rispetto alle note sulla versione di Adobe Commerce e a Tideways Q2 2025 rapporto.

Perché la velocità di Magento è un problema di entrate

Gli acquirenti non valutano i negozi Magento in base all’architettura. Saltano. I dati di Contentsquare mostrano 57% degli acquirenti abbandonano una pagina che richiede più di tre secondi per caricarsi, e la conversione diminuisce 4.42% per ogni secondo in più successivo. Il pagamento è peggio. Più della metà degli utenti cammina se il check-out impiega più tempo di 30 secondi da un capo all'altro.

Magento inizia dietro. I negozi costruiti sulla piattaforma vedono l'abbandono del carrello nel 72-76% gamma rispetto alla media globale dell'e-commerce di 78.77% a partire da agosto 2025. Questo divario sembra piccolo finché non ricordi che i commercianti Magento gestiscono valori medi degli ordini molto più alti rispetto ai negozi Shopify o WooCommerce. UN 2% aumento della conversione di un negozio che spinge 4 milioni di dollari in GMV (Valore lordo della merce, vendite totali elaborate) è all'incirca USD 80,000 all'anno di entrate recuperate.

Niente di tutto questo è teorico. Vie delle maree’ Q2 2025 rapporto registrato senza cache Magento 2 TTFB a 2 secondi per il più lento 25% di negozi e passato 3 secondi al 95° percentile. Questo è prima del tuo tema, il tuo CDN, le tue estensioni, o il tuo hosting entra nella foto. È la linea di base.

Le vere cause di un Magento lento 2 Negozio

La maggior parte del lavoro prestazionale fallisce perché i proprietari inseguono i sintomi. Salta il generico “svuota la cache e spera” routine. Questi sono i sei modelli che effettivamente spiegano la lentezza di Magento 2 negozi in 2026:

• PHP sottodimensionato o configurato in modo errato. Esecuzione di PHP 8.1 sopra 2.4.8 lavori, una specie di, ma OPcache, JIT, e miglioramenti del sistema di tipo in PHP 8.3 composto sui carichi di lavoro Magento. Se il tuo host è attivo 8.0 o 8.1, stai lasciando sul tavolo un TTFB misurabile ed erediti il ​​rischio per la sicurezza sulle versioni che Adobe non testa più.
• Stack della cache incompleto. Vernice senza Valkey (o Redis), o Valkey senza vernice, è la configurazione danneggiata più comune. Vernice 7.6 gestisce la memorizzazione nella cache dell'intera pagina per il traffico anonimo. walkie-talkie 8 gestisce la cache, sessioni, e cache degli oggetti per il traffico registrato. Hai bisogno di entrambi.
• OpenSearch mancante o sottodimensionato. Magento 2.4.8 richiede OpenSearch 2.19. Elasticsearch è deprecato. Alcuni negozi utilizzano ancora il vecchio ES 7.x e si chiedono perché le pagine di ricerca impiegano quattro secondi.
• Gonfiore dell'estensione. Ogni estensione di terze parti è un potenziale killer del piano per il compilatore di inserimento delle dipendenze e per i controlli di runtime. Un negozio con 80+ le estensioni hanno quasi sempre un osservatore che si comporta in modo anomalo durante l'evento di pagamento.
• Luma sull'hosting delle materie prime. Luma è stato progettato per 2015. Non è stato progettato per Core Web Vitals. Buono era.
• Le immagini sono servite come JPEG grezze. WebP lo è 25-34% più piccolo di JPEG. AVIF dimezza nuovamente le dimensioni del file sugli scatti dei prodotti di punta. La maggior parte dei negozi spedisce ancora immagini di prodotti da 400 KB e si chiede perché LCP (La più grande vernice contenta, quanto tempo impiega il più grande elemento visibile per il rendering) è 4 secondi.

La posizione del tuo negozio nell'elenco determina l'ordine di ciò che segue.

Velocizza Magento passo dopo passo

Questo è un ordine di costruzione. Esegui i passaggi dall'alto verso il basso. Saltare i primi passi e saltare a “ottimizzare JavaScript” è l'equivalente Magento di dipingere una casa prima di sistemare le fondamenta.

1. Aggiorna a Magento 2.4.8 (o 2.4.9 Quando atterra)

Magento 2.4.8-p4 è l'attuale versione stabile a partire da marzo 10, 2026. Versione 2.4.9-beta1 è in fase di test con GA previsto per maggio 2026, lasciando cadere MySQL 8.0 e MariaDB 10.6 e richiede PHP 8.4 o 8.5.

Una breve nota sulla denominazione. Adobe Commerce e Magento Open Source condividono la stessa base di codice principale e gli stessi numeri di versione. Adobe Commerce sviluppa livelli di quotazione B2B, allestimento e anteprima del commercio, reportistica avanzata, e lo stack di hosting gestito di Adobe Commerce Cloud. I suggerimenti sulle prestazioni contenuti in questa guida si applicano a entrambi. I clienti Adobe Commerce del livello Cloud ottengono rapidamente, Nuova reliquia, e gestito il pacchetto Varnish, quindi passi 3 e 8 di seguito sono già preconfigurati su quel livello.

Perché aggiornare? 2.4.8 capovolge tutti gli indicizzatori in Aggiorna in modalità Pianificazione per impostazione predefinita su nuove installazioni e aggiornamenti. Questo da solo riduce il ritardo di salvataggio dei prodotti di amministrazione e la latenza di aggiornamento del checkout per la maggior parte dei negozi, perché il valore predefinito precedente (“Aggiorna al salvataggio”) bloccato ogni salvataggio durante la reindicizzazione completa. Il 2.4.8 Il rilascio ha inoltre migliorato gli aggiornamenti dei prezzi a livelli in blocco tramite l'API REST, che conta per i cataloghi B2B.

Corsa 2.4.5 o prima? Stai utilizzando un codice non supportato. Inizia il tuo lavoro di performance qui, non con modifiche alla memorizzazione nella cache sui rami morti.

2. Correggi lo stack di hosting prima di ogni altra cosa

Nessuna quantità di salvataggi nella cache a 1 vCPU / 2 Piano condiviso GB con Magento. Il minimo onesto per una produzione 2.4.8 il negozio è 4 GB di RAM, con 8-16 GB il terreno pratico per tutto ciò che è passato 500 ordini giornalieri. I nostri Riepilogo dell'hosting Magento VPS analizza quali fornitori spediscono lo stack giusto fuori dalla scatola.

Ecco una diagnostica specifica. Se il tuo host non può installare OpenSearch 2.19 o non ti consente di eseguire Varnish 7.6, non sei su un hosting compatibile con Magento. Migra prima di passare un altro fine settimana a inseguire TTFB su uno stack che non può supportare il negozio.

3. Configura Varnish Plus Valkey (o Redis) Correttamente

Vernice 7.6 è la cache a pagina intera. Configurato correttamente, serve pagine memorizzate nella cache su TTFB inferiore a 200 ms contro 2-5 secondi non memorizzati nella cache. I numeri dei benchmark lo confermano: le richieste memorizzate nella cache di Varnish non vengono nemmeno visualizzate in Tideways’ percentili TTFB lenti perché sono molto più veloci.

Lista di controllo della configurazione:

• L'host backend e la porta di Varnish puntano al tuo vero server web
• Elenco di accesso (ACL) limitato agli IP amministratori che dovrebbero eliminare la cache
• Periodo di grazia impostato almeno 10 minuti (serve contenuti obsoleti mentre li recupera nuovi)
• Magento impostato per utilizzare Varnish in Stores > Configurazione > Avanzate > Sistema > Cache a pagina intera

Quindi sovrapponi Valkey 8 (o Redis 7.2) per la cache, memorizzazione della sessione, e cache degli oggetti. walkie-talkie 8 è il backend di nuova installazione consigliato per 2.4.8. Rosso 7.2 funziona ancora per i negozi esistenti. Il vantaggio di Valkey su Redis su Magento è sotto pressione in termini di memoria, dove mantiene meglio la latenza nelle letture della sessione.

4. Cambia la vetrina in Hyvä

I buoni siti ottengono ottimi risultati 90-100 su Google PageSpeed per impostazione predefinita, e 65% dei negozi Hyvä ha raggiunto ottimi Core Web Vitals rispetto a 41% per i negozi Luma. Il payload JavaScript è una frazione di quello di Luma perché Hyvä ha abbandonato RequireJS e Knockout a favore di Alpine.js e Tailwind.

Ecco il 2026 aggiorna la maggior parte delle guide che non sono state rilevate: Hyvä ha ottenuto la licenza del MIT ed è diventato gratuito negli ultimi tempi 2024. Non esiste più una licenza per temi per dominio. Ciò che costa ancora è il lavoro di migrazione su un negozio Luma personalizzato, tipicamente 80-200 ore, oltre a componenti aggiuntivi opzionali a pagamento come Buon pagamento (euro 1,000), Buona interfaccia utente (euro 250), o buona impresa (euro 2,500) se ne hai bisogno. Per qualsiasi vetrina che genera entrate, questa è la più grande mossa Core Web Vitals disponibile. Ancora bloccato su Luma? I nostri Raccolta dei temi Magento copre le opzioni più veloci compatibili con Luma, sebbene nessuno di loro colmi il divario Hyvä.

Avvertenza importante: solo 51% di buoni negozi effettivamente ha raggiunto un buon CWV. Il tema stabilisce il tuo soffitto. Una cattiva attuazione abbassa ancora il limite. Controlla i moduli di terze parti compilati nel tema Hyvä prima di presumere di aver finito.

5. Abilita la modalità di produzione (Correttamente)

Questo è veloce e la gente continua a mancarlo. Magento ha tre modalità: predefinito, sviluppatore, e produzione. Le modalità sviluppatore e predefinita rigenerano i file di visualizzazione su ogni richiesta, accedere in modo aggressivo a var/log, e saltare la configurazione compilata dell'inserimento delle dipendenze. La modalità di produzione precompila l'inserimento delle dipendenze, distribuisce i file di visualizzazione statica una volta, ed elimina l'output degli errori di sviluppo.

L'interruttore a una linea:

• distribuzione di php bin/magento:modalità:impostare la produzione

Sotto il cofano funziona quel comando impostare:di:compilare e impostare:contenuto statico:distribuire. Puoi anche eseguire questi due comandi manualmente durante una finestra di distribuzione senza cambiare modalità, che è il modo in cui la gestisce la maggior parte delle pipeline CI. Il profitto è misurabile: il passaggio di un negozio configurato in modo errato dalla modalità sviluppatore alla modalità produzione in genere fa cadere il TTFB 30-50% senza nessun altro cambiamento, perché ogni richiesta smette di pagare la tassa sulla generazione DI e sulla ricostruzione dei file statici.

Se stai distribuendo dalla gestione temporanea alla produzione, eseguire i passaggi di compilazione e distribuzione sullo staging e sincronizzare i file generati. Evitare di rigenerare la produzione durante le ore di punta. Compila picchi CPU per 3-8 minuti a seconda della complessità del tema, e la distribuzione del contenuto statico può spingerlo a farlo 10-15 minuti sui siti Hyvä con più impostazioni locali.

6. Ottimizza le immagini con AVIF e WebP

Da allora il caricamento lento nativo è stato distribuito in Magento 2.4.0 utilizzando il caricamento HTML=”Pigro” attributo sulle immagini del catalogo. Se è stato disabilitato durante la personalizzazione del tema, riattivarlo.

Oltre a questo, spingere le immagini attraverso formati moderni:

• WebP: riduce la dimensione JPEG di 25-34% con una qualità visiva quasi identica
• AVIF: riduce la dimensione del file di un altro 40-50% rispetto a WebP, al costo di più CPU da codificare
• Per la fotografia del prodotto, AVIF vale il tempo di codifica perché mantiene la fedeltà dei colori

Ottimizzazione rapida delle immagini (su Adobe Commerce Cloud) esegue automaticamente la negoziazione del formato per browser. I negozi self-hosted possono utilizzare estensioni come JaJuMa Ultimate Image Optimizer o inserire la generazione AVIF nella pipeline di distribuzione. In entrambi i casi, Trasformazione dell'immagine a livello CDN supera la conversione PHP per richiesta per qualsiasi negozio che esegue più di una manciata di caricamenti di SKU a settimana.

7. Elimina le estensioni che uccidono il TTFB

Ogni estensione installata include almeno un plug-in, osservatore, o preferenza. Molti ne spediscono dozzine. L'evento di pagamento è l'evento più osservato in Magento e la fonte più comune di regressioni TTFB da 500-800 ms.

Flusso di lavoro di controllo:

1. Correre modulo bin/magento:stato ed elencare i moduli di terze parti abilitati
2. Disabilitare i moduli non critici uno per uno durante lo staging
3. Checkout benchmark TTFB dopo ogni disabilitazione
4. Mantieni disabilitato tutto ciò che consente di risparmiare oltre 100 ms senza evidenti costi aziendali

Osserva attentamente i moduli nella spedizione, promozioni, e categorie B2B. Quelli trasportano il carico più pesante degli eventi di pagamento.

8. Aggiungi un CDN con regole di cache che effettivamente memorizzano nella cache

Cloudflare, Velocemente, o KeyCDN davanti a Magento è table-stakes. L’errore è lasciare stare le regole predefinite. Fuori dagli schemi, la maggior parte dei CDN ignorano la cache per qualsiasi cosa con una stringa di query, che interrompe la memorizzazione nella cache per le pagine di categoria filtrabili con ?p=2 impaginazione.

Set minimo di regole di cache:

• Asset statici (JS, CSS, font, immagini): cache 1 anno, servire stantio mentre riconvalidato
• Pagine di categoria: cache 1 ora per anonimo, bypass per l'accesso
• Pagine dei prodotti: cache 4-12 ore, bypass per l'accesso
• Carrello, guardare, conto cliente: bypassare del tutto

Le intestazioni della cache a pagina intera di Magento dicono a Varnish cosa è memorizzabile nella cache. La CDN dovrebbe rispettare tali intestazioni. Se stai ignorando le regole generali, stai lavorando contro la logica della cache di Magento.

Abilita anche HTTP/3 a livello CDN se è un'opzione (Cloudflare e Fastly lo supportano entrambi). HTTP/3 utilizza QUIC anziché TCP, che recupera più velocemente dalla perdita di pacchetti sulle reti mobili. I miglioramenti LCP mobili reali di 100-300 ms sono tipici delle connessioni 4G, che è la differenza tra “Caricamento in corso” e “caricato” per molti acquirenti.

9. Ricostruire gli indicizzatori e mantenere il database

Anche con l'aggiornamento della versione 2.4.8 in base alla pianificazione predefinita, gli indicizzatori vanno alla deriva. Correre indicizzatore bin/magento:reindicizzare su un minimo cron settimanale, più reindicizzazione mirata dopo importazioni di cataloghi in blocco.

La manutenzione del database non la fa nessuno:

• Troncare citazione e quote_item tabelle trimestrali (i carri abbandonati si accumulano per sempre)
• Pulito vendite_bestseller_aggregate_* se non usi i report
• Archivia ordini più vecchi di 24 mesi utilizzando l’archivio integrato di Adobe Commerce (Gli utenti Open Source necessitano di uno strumento di terze parti)

UN 6 GB citazione table rallenta ogni query dell'amministratore. La maggior parte dei negozi Magento non l'hanno mai troncato.

10. Rimanda JavaScript e unisci CSS con attenzione

Abilita la minimizzazione JS, fusione, e raggruppamento in Negozi > Configurazione > Avanzate > Sviluppatore. Il raggruppamento riduce il conteggio delle richieste. La minimizzazione riduce il carico utile. Rinvio di JS non critico (analitica, widget di chat) impedisce loro di bloccare il rendering iniziale.

Un avvertimento. Il raggruppamento avanzato su Luma prevede regressioni note per specifici moduli di terze parti. Testare la messa in scena con le esecuzioni sintetiche di Lighthouse prima di lanciarlo in produzione.

Come diagnosticare dove il tuo negozio sta effettivamente perdendo tempo

L'ottimizzazione senza misurazione è un'ipotesi. Questo è lo stack diagnostico che eseguiremmo su qualsiasi negozio Magento prima di toccare una singola impostazione:

• Page Speed ​​Insights + CruUX: dati utente reali da Chrome. Concentrati su tre Core Web Vitals al 75° percentile: LCP (La più grande vernice contenta, Quello di Google “bene” la soglia è inferiore a 2,5 s), INP (Interazione con la vernice successiva, obiettivo inferiore a 200 ms), e CLS (Spostamento del layout cumulativo, bersaglio sotto 0.1).
• Tideways o New Relic APM: tracciamento PHP a livello di transazione. Ti dice quali controller, osservatori, e i plugin mangiano tempo.
• DebugBear o SpeedCurve: monitoraggio sintetico con andamenti storici. Cattura le regressioni dopo le distribuzioni.
• Il profiler integrato di Magento: abilitare tramite .htaccess, controllare l'output sulle pagine lente.

Controlla il 95° percentile, non la mediana. La tua mediana potrebbe andare bene. Il 5% delle pagine più lente sono solitamente quelle in cui si nasconde l'abbandono del carrello.

Quando coinvolgere uno specialista delle prestazioni Magento

Alcuni problemi di prestazioni non sono problemi fai-da-te. Porta uno specialista quando:

• Il TTFB è superiore a 800 ms con Varnish correttamente configurato e l'infrastruttura correttamente dimensionata. Ciò indica un problema di codice profondo o una catena di plug-in che non troverai modulo:stato.
• Gli eventi di pagamento sono stati ampiamente personalizzati 3+ anni. Districare le catene degli osservatori è un audit completo, nemmeno un pomeriggio.
• Stai pianificando una migrazione Hyvä da un negozio Luma personalizzato. Budget 120-200 ore con un'agenzia Hyvä certificata per qualsiasi cosa oltre un semplice catalogo.
• Hai già eseguito i primi sei passaggi di questa guida e il TTFB è ancora sopra 1 secondo.

UN 40-60 Il controllo orario da parte di uno specialista delle prestazioni di Magento in genere viene eseguito in USD 8,000-15,000. Sembra molto finché non calcoli cosa a 1% l'incremento della conversione vale sul tuo GMV annuale.

Domande frequenti

Ne vale la pena Hyvä per un piccolo negozio Magento che fa sotto 500 ordini al mese?

Il tema stesso è ora gratuito (Con licenza MIT da tardi 2024), quindi l’unico costo che rimane è il lavoro di migrazione, che gestisce USD 5,000-15,000 tutto compreso per un negozio modesto. Sotto 500 ordini al mese a USD 100 AOV, si tratta comunque di una finestra di rimborso pluriennale. Correggi l'hosting, Vernice, immagini, e prima l'audit di estensione. Rivisita Hyvä una volta superato il GMV annuale di 1 milione di dollari, o prima, se riesci ad assorbire in anticipo i costi di migrazione.

Qual è la specifica di hosting minima per un Magento 2.4.8 magazzino di produzione?

4 Minimo assoluto di GB RAM, 8 GB se stai utilizzando Varnish, walkie-talkie, e OpenSearch sulla stessa casella, 16 GB se ne hai 50,000+ SKU o esegui un catalogo B2B. La CPU conta meno della RAM. La maggior parte dei colli di bottiglia di Magento sono dovuti alla pressione della memoria, non CPU. I nostri Raccolta VPS per l'e-commerce elenca i fornitori che soddisfano queste specifiche senza prezzi aziendali.

Varnish su Magento aiuta i clienti che hanno effettuato l'accesso?

Non direttamente. Varnish serve traffico anonimo, che per la maggior parte dei negozi B2C è 70-85% delle visualizzazioni di pagina. I clienti che hanno effettuato l'accesso ignorano la cache dell'intera pagina perché il loro contenuto è personalizzato. È qui che conta la cache degli oggetti Valkey o Redis. La tua home page e le pagine delle categorie voleranno per nuovi visitatori. I dettagli del prodotto e il checkout per gli utenti che hanno effettuato l'accesso ricadono ancora su PHP più Valkey.

Quanto riduce effettivamente il passaggio ad AVIF o WebP LCP?

In una pagina di prodotto in cui LCP è un'immagine di prodotto eroe, 300-700Il miglioramento della ms è tipico. Se l'immagine LCP scende da 420 KB a 140 KB, ciò si traduce direttamente in un rendering più veloce su qualsiasi connessione di seguito 10 Mbps. Avvertimento: La codifica AVIF è pesante per la CPU, quindi genera al momento del caricamento (o tramite CDN) piuttosto che su ogni richiesta.

Qual è l'hosting più veloce per un Magento 2.4.8 memorizzare?

“Il più veloce” dipende se vuoi gestito o autogestito. Gli specialisti di Magento gestito come Nexcess e Hypernode forniscono uno stack pre-ottimizzato (PHP-FPM, Vernice, Redis o Valkey, OpenSearch) e in genere forniscono immediatamente un TTFB inferiore a 300 ms. Sul lato autogestito, un Hetzner CX32 o equivalente a 8 GB di RAM con Varnish e Valkey configurati correttamente possono eguagliare quelle prestazioni 40-60% costo mensile inferiore, al prezzo del lavoro dell'amministratore di sistema. Il riepilogo di Magento VPS collegato in precedenza in questa guida presenta la suddivisione fornitore per fornitore.

Magento è più lento di Shopify fuori dagli schemi?

Metriche di velocità della pagina grezza, sì. Shopify serve la maggior parte delle visualizzazioni di pagina dalla sua CDN edge globale con caching aggressivo, quindi un nuovissimo negozio Shopify in genere batte un nuovissimo negozio Magento su TTFB. Il divario si riduce drasticamente una volta che Magento è su Varnish più un CDN. Flessibilità sul fronte del negozio, profondità di personalizzazione, e funzionalità B2B, Magento vince, ecco perché le imprese tollerano la complessità dell’infrastruttura. Se desideri una velocità simile a Shopify con controllo a livello di Magento, questa è la combinazione di hosting gestito Hyvä plus.

Come posso testare accuratamente la velocità del mio sito Magento?

Esegui tre strumenti e confronta. PageSpeed ​​Insights ti fornisce l'LCP ufficiale di Google, INP, e CLS al 75° percentile da utenti reali di Chrome. WebPageTest.org ti consente di eseguire test da posizioni geografiche e velocità di rete specifiche (scegli un profilo 4G Moto G4 per una lettura mobile onesta). GTmetrix o DebugBear tengono traccia delle regressioni nel tempo. Prova sia una pagina di categoria anonima (dove Varnish dovrebbe entrare in azione) e un checkout effettuato con l'accesso (dove non lo farà). Il divario tra i due ti dice quanto lavoro sta svolgendo il tuo stack non memorizzato nella cache.

Il cibo da asporto

Il percorso più veloce verso un negozio Magento più veloce non è quasi mai quello glamour. Compressione dell'immagine, Regole della cache della CDN, e una migrazione Hyvä supera ogni volta una dozzina di micro-ottimizzazioni a livello di estensione. Correre 2.4.8 (o 2.4.9 una volta spedito a maggio 2026) su hardware compatibile, strato di vernice più Valkey, e controllare spietatamente le estensioni. La maggior parte dei negozi vede 40-60% Miglioramento del TTFB solo con queste quattro mosse.

Se stai ancora valutando le infrastrutture, il Guida all'hosting NVMe è un utile punto di partenza. L'I/O del disco colpisce duramente i tempi di checkout di Magento sulle vecchie unità SATA, e NVMe sposta le letture del carrello e della tabella dei preventivi in ​​una classe di latenza diversa. Combinalo con le guide sull'hosting e sui temi collegate sopra, e hai coperto l'intero stack.