Entro nel tuo team e rendiamo il sito veloce

Dipende da quanto fattura il tuo sito. Loop Earplugs è diventato più veloce di circa 800 ms su mobile e la conversione al checkout è salita del 7%. Non posso prometterti il 7%, ma il RUM mostra l'effetto di ogni fix sulle metriche e i tuoi analytics mostrano l'impatto sui ricavi. Avrai entrambi i dati.

Poco. I Core Web Vitals sono un fattore di ranking, ma secondario: i contenuti pertinenti vengono prima e la velocità fa da spareggio tra pagine simili. Il vero vantaggio arriva dopo il clic. Un sito più veloce perde meno visitatori e converte di più tra quelli che restano. Questo si riflette sui tuoi ricavi, che Google ti posizioni più in alto o meno.

Aziende con sviluppatori interni, traffico reale e un sito in cui la velocità incide direttamente sul fatturato. Soprattutto e-commerce, applicazioni SaaS in cui i clic sembrano lenti ed editori con molta pubblicità. Non hai sviluppatori interni né un'agenzia che sviluppi per te? Allora un audit o un intervento rapido è un punto di partenza migliore.

No. Chiunque garantisca un punteggio prima di aver analizzato il tuo sito sta solo tirando a indovinare. Il mio obiettivo è superare i Core Web Vitals al 75° percentile sulle pagine che generano fatturato. È questo ciò che misura Google, ed è quello che percepiscono i visitatori.

La maggior parte delle agenzie si occupa un po' di tutto, e le performance sono solo una voce nell'elenco. Per me è l'unica cosa. I problemi complessi si trovano raramente in una checklist: l'idratazione in Next.js, decine di script di terze parti su un sito editoriale, annunci pubblicitari che spostano il layout durante il caricamento. Ciascuno ha la propria specializzazione. Questa è la mia.

Sì, è incluso nella consulenza. Se il tuo sistema RUM mostra già quale elemento o script è lento, possiamo usare direttamente quello.

Praticamente tutti. Next.js, Nuxt, Magento, Salesforce Commerce Cloud, Shopify, WordPress o un sito PHP creato nel 2012. Al browser non interessa con cosa è stata generata la pagina, e il browser è proprio il luogo in cui lavoro. Su una piattaforma hosted come Shopify non puoi modificare la piattaforma stessa, ma il tema, le app e gli script che caricano sono tuoi, ed è proprio lì che si trova la maggior parte dei problemi.

Quel punteggio è di Lighthouse: un lab test su un singolo smartphone simulato con connessione lenta. Google guarda i field data, cioè quello che i tuoi visitatori reali sperimentano al 75° percentile, ed è su quello che lavoro. Di solito il punteggio Lighthouse sale durante il percorso, ma non lo inseguo. Un sito può ottenere 95 e non superare i Core Web Vitals, o viceversa.

Individuo cosa viene eseguito sul main thread quando qualcuno fa clic. L'API Long Animation Frames (LoAF) mi indica quale script e quale funzione lo fanno. Poi dividiamo quel lavoro, lo spostiamo fuori dal percorso o lo eliminiamo del tutto.

Quasi mai. Di solito si tratta di pochi componenti pesanti, dell'ordine di caricamento degli script o del modo in cui la pagina effettua l'idratazione. Modificare questi elementi costa molto meno di un rewrite e i risultati si vedono molto prima.

Non hai ancora un RUM, o il tuo non riesce a mostrare quale elemento o script sia lento? Allora aggiungo CoreDash. È costruito appositamente per questo tipo di lavoro. Per ogni evento LCP, INP e CLS mostra quale elemento, script o risorsa lo ha causato. Vedi l'effetto di un fix sui visitatori reali entro una giornata, invece di aspettare che la media mobile su 28 giorni di Google si aggiorni. E non c'è alcun limite al numero di URL tracciati o al periodo di conservazione dei dati.

Sì. Lavoro volentieri con le agenzie e con chiunque altro sia coinvolto. L'agenzia sviluppa, io trovo i problemi, li metto in ordine e verifico ogni fix, esattamente come farei con il tuo team. Sei tu l'agenzia? Qui trovi come lavoro con le agenzie.

Problemi trasformati in ticket nel tuo sistema, fix già rilasciati in produzione, performance budget nella pipeline di CI/CD, monitoraggio e alert sui dati RUM, e sviluppatori che sanno esattamente perché tutto funziona.

In due modi. I performance budget nella pipeline di deployment segnalano una build che introduce layout shift o blocca il main thread prima che vada online. Gli alert sui dati RUM ti avvisano quando qualcosa peggiora. CoreDash controlla ogni ora, ma invia un alert solo quando ci sono abbastanza dati per avere la certezza, così non devi inseguire falsi positivi. Lo sai comunque con settimane di anticipo rispetto a Search Console.

Un audit ti dice cosa non va e in quale ordine intervenire. La consulenza resta finché non è tutto risolto.

Il tuo team prende in mano la situazione. C'è anche un retainer, a partire da 1.500 € al mese per circa un giorno del mio tempo: tengo d'occhio i dati RUM, ti avviso se qualcosa rallenta e ogni trimestre decidiamo i passi successivi.

Accesso al repository (GitHub, GitLab o qualunque strumento tu usi), a un ambiente di staging e ai tuoi analytics. Niente settimane di riunioni per l'onboarding. Una volta dentro inizio, e di solito ricevi i primi risultati entro 5 giorni lavorativi.

Da una settimana a sei mesi. Dipende da quanti problemi ci sono e da quanto è veloce il tuo team a rilasciare. La maggior parte dura meno di quanto ci si aspetti: il 60% dei miei incarichi si conclude entro un mese. La durata esatta è definita nello scope, prima di iniziare.

Nei dati RUM vedi i cambiamenti entro un giorno dal deploy. I numeri hanno bisogno di abbastanza visite per essere significativi, quindi le pagine con molto traffico lo mostrano prima di quelle più tranquille. In ogni caso lo sai con settimane di anticipo rispetto all'aggiornamento del report CrUX di Google.

Sì. Non rimuoviamo i tag, cambiamo il modo e il momento in cui vengono caricati. Gli annunci pubblicitari possono comunque rispettare i requisiti di viewability senza bloccare il main thread né spostare il layout. DPG Media, Aleteia e Who What Wear hanno mantenuto i ricavi pubblicitari e superato i Core Web Vitals.