8 Luglio 2022

Delay JS per ottimizzare i Core Web Vitals e basse performance delle campagne Facebook ADS.

Come la sovraottimizzazione Core Web Vitals ed il delay del Javascript può uccidere le tue campagne Facebook Advertising.

L’abbiamo detto e stradetto, il punteggio PageSpeed e l’ottimizzazione dei Core Web Vitals sono importanti, ma bisogna trovare un compromesso tra un punteggio che porti dei vantaggi ed un punteggio che porti solo vanità.

Lo abbiamo ribadito ed evidenziato in questo articolo quando abbiamo spiegato i pericoli tra usare background-image piuttosto che il tag html img per ingannare Google PageSpeed, bisogna trovare un compromesso e non farsi illudere da vanity metrics.

Il problema è sempre che di fondo mancano le compentenze, l’onestà, o a volte tutte e due.

Oppure più semplicemente arriva il committente che va dall’esperto Core Web Vitals e dice :

“Uèèèèèè Artista !!! Ma sai che Big Looca ha detto che le campagne per performare richiedono siti veloci come dei missili terra aria e che il mio amico che fa Affiliate Marketing con siti Web Veloci si è comprato il nuovo BMW M3 Sport e ha un punteggio PageSpeed di 91 su Mobile? Forza dai, mandami veloce il sito che ti pago mille euri !!!”

Ed ecco l’artista web designer, sviluppatore web, o web performer come va di moda oggi, semplicemente esegue senza battere ciglio.

E’ prassi, forma mentis di eseguire e realizzare quel che il committente richiede, evitando di dare consigli e sollevare obiezioni sulla richiesta e sulle implicazioni dannose che ne potrebbero conseguire.

E se poi ci ripensa e non mi fa fare più l’ottimazzione, o peggio, non la fa più fare a me ma la lascia fare a qualcun altro al posto mio ?

Meglio rimanere in silenzio ed ecco che torna dopo qualche giorno e ti porta il sito a punteggi Mobile stratosferici. Non solo non ti ha aiutato, ma anzi ti ha creato dei seri problemi, che pagherai a tue spese in futuro, come quello di farti spendere un sacco di soldi di FB Advertising e campagne che non girano come dovrebbero con un altissimo drop.

 

PageSpeed Insights Asso360 Mobile

Devi tener conto infatti che Facebook è uno dei posti migliori per pubblicizzare qualsiasi attività commerciale. Esistono molti modi per creare gli annunci perfetti per le tue esigenze e puoi preventivare all’interno del loro modulo pubblicitario per ogni tipo di annuncio in modo univoco. Ciò significa che puoi indirizzare il traffico al tuo sito web con i tuoi annunci Facebook, a un costo molto basso.

Ma cosa succede se le tue inserzioni su Facebook non generano i risultati di una volta? Ciò potrebbe essere dovuto ai recenti aggiornamenti di iOS14. Ciò è dovuto alle funzionalità di tracciamento che Apple ha bloccato. Anche se questo potrebbe essere stato molto utile dal punto di vista della sicurezza, è un cambiamento inutile relativo alla pubblicità, di cui tutti pagheremo lo scotto, quando il prodotto che prima costava 100 euro, oggi con i costi aumentati della pubblicità lo pagheremo 120.

Tornando al discorso dell’altro drop delle campagne facebook invece, potrebbe essere dovuto anche ad una sovraottimizzazione dei Core Web Vitals, andando ad ogni costo a cercare un punteggio ottimale e dunque utilizzando male la funzione del delay js presente in molti plugin di ottimizzazione delle performance.

Cosa si intende con Drop di una campagna Facebook ?

Per Drop di una campagna Facebook in gergo tecnico si intende quella situazione in cui la campagna non performa come dovrebbe, ed in particolar modo il fenomeno in cui Facebook manda traffico a pagamento dalle campagne verso il tuo sito di ecommerce ed il tuo sito di ecommerce non registra la visita dando a sua volta feedback a FB e inviando gli eventi come la visita stessa.

Facebook pensa e ragiona così: io ti ho inviato 1000 visitatori potenzialmente in target con i tuoi criteri che hai inserito, di questi 1000 utenti che io Facebook ti ho inviato da FB (e che so di averti inviato) ben 800 (ovvero l’80%) se ne sono andati subito, quindi io Facebook penso che:

  1. Hai il sito che non funziona ed è down.
  2. Hai un sito lento che non carica e gli utenti abbandonano subito.
  3. Hai un sito non pertinente o con creatività scrause e brutte con pessima usabilità.
  4. Hai un sito su cui non funziona il pixel e non riesco a tracciare gli eventi.

A prescindere, Facebook ha interesse esclusivo di far girare campagne che funzionano e generano profitti, tutte quelle che non vanno semplicemente non girano oppure girano con una spesa maggiore non riuscendo a profilare e tracciare le persone interessate.

Questo significa in parole povere altissima spesa e minima resa, l’incubo di ogni imprenditore, di ogni advertiser e di ogni Affiliate Marketer che a causa di ciò non potrà vivere la vita da sogno in villa e piscina a Dubai insieme a Big Looca.

Cos’è il pixel di Facebook?

Il Facebook Pixel è un codice che si può inserire in un sito web per tracciare gli utenti che visitano il sito e utilizzare queste informazioni per creare pubblicità mirate su Facebook. Questo codice consente di seguire le azioni degli utenti sul sito, come le pagine visitate e i prodotti acquistati, e utilizzare queste informazioni per creare pubblicità personalizzate su Facebook.

Il Facebook Pixel consente di:

  • Creare pubblicità mirate in base alle azioni degli utenti sul sito, come le pagine visitate e i prodotti acquistati.
  • Creare pubblicità personalizzate per gli utenti che hanno visitato il sito in precedenza.
  • Creare pubblicità mirate in base all’audience.
  • Monitorare le conversioni, ovvero le azioni intraprese dall’utente, come ad esempio un acquisto.

Come funziona Facebook Pixel?

Il funzionamento del Pixel di Facebook in se è piuttosto facile. Non andremo ad analizzarlo dal punto di vista del codice Javascript, ci basterà infatti sapere sommariamente in modo grossolano come funziona:

  1. Un utente visita il tuo sito Web eseguendo alcune azioni come cercare prodotti, aggiungerli al carrello, completare il checkout, ecc.
  2. Il pixel di Facebook tiene traccia di questi eventi e si sincronizza con i cookie di Facebook nel browser web dell’utente.
  3. Dopo il processo di sincronizzazione, l’utente viene contrassegnato come parte di determinati gruppi target.
  4. Quando l’utente apre Facebook, la piattaforma sa già quali annunci mostrare.

 

Dobbiamo tenere a mente un concetto ben chiaro, il pixel di Facebook è un Codice Javascript. Ricorda, un codice … Javascript.

Delay dei Javascript e ottimizzazione Core Web Vitals.

Il delay del JavaScript è un termine utilizzato per descrivere il tempo che intercorre tra l’effettivo caricamento di una pagina web e il momento in cui gli script JavaScript in essa contenuti vengono eseguiti.

Il motivo principale per cui il delay del JavaScript può influire sulle performance del sito web è che gli script JavaScript possono rallentare il caricamento della pagina. Se uno script JavaScript deve essere eseguito prima che la pagina sia completamente caricata, questo può causare un ritardo nella visualizzazione della pagina per gli utenti.

Il delay del JavaScript può anche influire sui valori dei Google Core Web Vitals, ovvero una serie di metriche utilizzate da Google per valutare la qualità dell’esperienza utente sui siti web. Tra questi, il tempo di caricamento della prima risposta (First Contentful Paint – FCP), che misura il tempo che intercorre tra l’effettivo caricamento della pagina e il momento in cui il primo elemento visibile viene visualizzato, può risentire del delay del javascript, in quanto un eccessivo tempo di esecuzione degli script javascript può causare un ritardo nell’effettivo rendering della pagina.

Parlare dei delay di Javascript come tecnica, significa necessariamente quanto meno a scopo puramente informativo introdurre Gijo Varghese, un programmatore indiano che ama definirsi blogger (30%), sviluppatore (60%) e imprenditore (10%). Un appassionato di velocità di WordPress.

Questo giovane programmatore focalizzato sull’ottimizzazione dei siti web e delle performance, ad un certo punto ha pensato al fine di migliorare il punteggio PageSpeed (al tempo ancora non era presente il concetto dei Core Web Vitals) di caricare i file Javascript con un ritardo, un delay appunto.

Questa tecnica l’ha chiamata col nome di Flyng Script (probabilmente in onore dei clienti che vogliono i siti che volano).

La motivazione del Delay Javascript è piuttosto facile da capire, uno dei fattori più peggiorativi in termini di punteggio PageSpeed e velocità di caricamento sono appunto i file Javascript.

Le cause sono principalmente le seguenti:

  1. Ne sono normalmente tanti soprattutto su siti WordPress e i numerosi plugin.
  2. Hanno un peso a livello di kilobyte non indifferente.
  3. Non sono linguaggi di markup come HTML o stili come CSS, ma linguaggi di programmazione che vengono elaborati lato client e dunque impattano sia sulle risorse dell’hardware che sulla reattività su dispositivi non velocissimi.

Chiunque abbia provato a fare un test PageSpeed Insight con i Javascript caricati normalmente e i Javascript caricati con un delay si sarà accorto di quanto sia evidente in termini di peso e velocità (nonchè punteggio Pagespeed) un sito caricato con questa tecnica.

È pacifico, dunque, quanto meno nei primi tempi provare a ritardare tutto ciò che è ritardabile cercando di trovare questo semaforo verde che appaga sia il nostro ego che quello del cliente, tuttavia come insegnano nell’arte della guerra, bisogna avere paura di ciò che non si conosce ed è li che iniziano problemi.

Uno sviluppatore oltretutto è uno che fa o sa fare campagne Facebook Advertising? E’ una figura tecnica in grado di capire come dovrebbe funzionare questo meccanismo? No, come è normale che sia, non ha colpe in quanto dovrebbe essere diretto da colui che invece fa advertising che a sua volta è una figura che non ha competenze di programmazione e dunque compartimenti stagni che non comunicano ed ecco che il disastro è servito.

Siamo onesti, profondamente onesti. Nemmeno noi sapevamo dell’implicazione di tale problematica con Facebook Advertiging, perchè non sapevamo come funziona Facebook Advertising e il Pixel di Facebook, siamo sistemisti, un po’ sviluppatori ma non advertiser.

Abbiamo dovuto investire del tempo e delle risorse con dei nostri clienti Affiliate Marketer professionisti per capire dove fosse l’inghippo e comprendere senza rammarico che dovevamo fare un passo indietro e valorizzare gli obiettivi di business piuttosto che un mero punteggio Google Pagespeed.

Altri motivi per cui ritardare l’esecuzione degli script Javascript

I dati scaricati da server di terze parti come Facebook Page Widget, Facebook Messenger, Facebook Comments, iframe o servizi di live chat come Tawk.to sono dati che non puoi controllare. Non puoi comprimerli, unirli o memorizzarli nella cache, semplicemente perché non sono sul tuo host. Questi dati sono spesso molto pesanti e possono causare seri problemi legati alla velocità di caricamento del sito web. Per vederlo chiaramente, puoi utilizzare Google PageSpeed Insights , GTmetrix o qualsiasi altro strumento di test della velocità per verificare.

E poiché non è possibile ottimizzarli, l’unica soluzione per integrare i servizi di cui sopra nel sito Web senza influire sulla velocità della pagina è ritardare l’esecuzione dei loro script. In questo modo, ridurrai il tempo di rendering della tua pagina e migliorerai gli indici di velocità sugli strumenti di test della velocità della pagina come Time to Interactive, First CPU Idle, Max Potential Input Delay, ecc. Ciò ridurrà anche il carico utile iniziale sul browser riducendo il numero di richieste.

Come ritardare l’esecuzione di Javascript ?

Da un punto di vista prettamente tecnico ritardare i Javascript significa semplicemente aggiungere uno script Javascript per ritardare l’esecuzione degli altri script Javascript.

Ad esempio, tutti i plugin per WordPress che ad oggi implementano tale feature si basano sul codice di Flying Scripts scritto da Gijo Varghese. Questo vale per plugin come Flying Scripts, WP Meteor, FlyngPress (un’evoluzoine commerciale di Flyng Script che è free) o anche il più conosciuto Wp Rocket.

C’è da dire che mentre i primi 3 elencati sopra permettono di settare un timeout dopo di che si caricano i file Javascript, Wp Rocket (che è quello più conosciuto e più commerciale) sebbene abbia molte più funzioni è l’unico tra i tanti che non ha e non permette di impostare un timeout. Semplicemente inizierà a caricare gli altri Javascript allo scaturirsi di un’interazione come, ad esempio, un touch del dispositivo o uno scroll.

Questo crea non pochi problemi, ad esempio, a siti che hanno plugin con slider in Javascript che rimangono fuori ed in attesa fino a quando l’utente non interagisce col sito attivando l’evento che porterà al caricamento del sito.

In alcuni casi è veramente fastidioso perchè si crea quel fenomeno in cui l’utente attende che si carichi qualcosa, e lo script attende l’utente che interagisca, ma l’utente sta ancora aspettando che si carichi lo slider. Una situazione tanto goffa quanto spiacevole.

Come il ritardo di Javascript ovvero il Delay dei JS impatta sulle campagne Facebook ADS ?

Se hai seguito bene e con attenzione fino ad ora dovresti esserci già arrivato. Riprendiamo lo schema qui sotto per ripercorrere i vari step e capire il problema del Delay JS e il drop delle campagne Facebook.

Abbiamo detto che che l’utente da Facebook viene inviato sul mio sito che contiene il pixel di Facebook, il browser caricare il sito che però ha il delay del JS attivo, l’utente apre la pagina, guarda l’immagine, legge il testo e se ne esce dopo due o tre secondi e il pixel di Facebook non è stato ancora caricato, non ha scaturito l’evento e non ha comunicato niente a Facebook.

Per Facebook risulta dunque che il visitatore abbia cliccato sull’advertising di Facebook, sia stato inviato al tuo sito, che non si è aperto.

E’ irrilevante se in effetti il visitatore vedeva le immagini, il logo, il testo e la descrizione e solo il pixel di Facebook non veniva caricato, perchè Il Pixel di Facebook è “la prova del nove” che il sito si sia caricato ed abbia scaturito appunto l’evento.

Dovrebbe o non dovrebbe usare la tecnica del Delay JS?

Questa tecnica dovrebbe essere utilizzata per script relativi all’interazione dell’utente o chat dal vivo come Facebook Customer Chat, Facebook Widget, Facebook Comment, iframe (Youtube, Google Maps), Tawk.to, …

In caso contrario, non è consigliato per script come il monitoraggio o l’analisi dei dati dell’utente come Google Analytics, Facebook Pixel, Google Tag Manager, Crazy Egg, Google Remarketing Tag, perché l’applicazione di questa tecnica può causare la mancata registrazione dei dati oppure rendere la stessa incompleta o imprecisa.

Il giusto compromesso qualora si utilizzino i plugin sopra citati, è quello di utilizzare il Delay dei JS ma allo stesso tempo escludere tra le opzioni i plugin che sono implicati nel caricamento del Pixel di Facebook come ad esempio possiamo fare su Wp Rocket (che a me personalmente non piace per la mancanza del timout).

 

È sempre meglio avere un sito con un punteggio PageSpeed più basso che traccia tutti gli eventi e ti permette di avere campagne performanti e un ritorno sull’utile gratificante, che avere un sito web con un punteggio di 100 e avere Facebook che ti fa spendere cifre stratosferiche senza vendere nulla.

 

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Hetzner Online GmbH detiene i diritti su Hetzner®; OVHcloud è un marchio registrato di OVH Groupe SAS; cPanel®, L.L.C. detiene i diritti su cPanel®; Plesk® è un marchio registrato di Plesk International GmbH; Facebook, Inc. detiene i diritti su Facebook®. Questo sito non è affiliato, sponsorizzato o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello europeo da MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italia.

SOLO UN ATTIMO !

Vorresti vedere come gira il tuo WooCommerce sui nostri sistemi senza dover migrare nulla ? 

Inserisci l'indirizzo del tuo sito WooCommerce e otterrai una dimostrazione navigabile, senza dover fare assolutamente nulla e completamente gratis.

No grazie, i miei clienti preferiscono il sito lento.
Torna in alto