Hosting per Affiliate Marketer, vediamo quali sono le caratteristiche ideali.

In questo articolo andremo a vedere quali sono le prerogative e le necessità di chi fa affiliate marketing e alcune delle caratteristiche purtroppo non prese in considerazione dai normali hosting che non conoscono il mondo dell’affiliazione, ne tantomeno le problematiche tecniche e le necessità che ogni buon affiliato dovrebbe disporre.

In realtà il problema non è solo delle aziende di Hosting ma anche degli affiliate Marketer che spesso non sono figure tecniche ma più esperti di Advertising come FB ADS, Google AdSense, Outbrain e simili, e riescono si a misurare per decidere, ma senza addentrarsi troppo nei virtuosismi tecnici alla base della professione dell’affiliate marketer professionista.

Se spendi 100 euro al giorno in advertising, massimizzare un 5% di ROI potrebbe essere piuttosto irrilevante, ma se fai come alcuni nostri clienti che muovono centinaia di migliaia di euro AL GIORNO in advertising, quel 5% è la differenza tra un business profittevole, non profittevole o estremamente profittevole.

Dal 2017 abbiamo collaborato con Affiliation Park in vesti di sistemisti, allo stesso tempo siamo attualmente fornitori di Top Affiliate italiani (di cui non possiamo svelare i nomi per ovvi motivi di riservatezza e privacy), ma basti pensare che sono quelli che fanno i record in WorldFilia.

Insomma, conosciamo molto bene il settore, i player in gioco, le casistiche, le necessità, i dispetti che i vari affiliate marketer subiscono (e si fanno) tra DDOS e lead fasulli e abbiamo creato un sistema di fornitura servizi di Hosting rivolto proprio a quella nicchia estremamente delicata ed esigente visto i budget in gioco.

Un breve ripasso è d’obbligo per chi non è esperto del settore e non sa cosa sia l’affiliate marketing, (o la lead generation come piace definirla a noi).

Che cos’è l’affiliate Marketing?

Il marketing di affiliazione o affiliate marketing è il processo di guadagnare una commissione promuovendo i prodotti di altre persone (o società). Trovi un prodotto che ti piace, lo promuovi agli altri e guadagni una parte del profitto per ogni vendita che fai.

Ovviamente promuovere un prodotto significa “mostrarlo” in modo accattivante ad un potenziale acquirente e tramite comunicazione, copywriting, immagini e creatività varie indurlo all’acquisto.

Per ogni vendita che faremo, riceveremo una provvigione che normalmente si aggira sul 33% dell’importo venduto.

Una parte va al produttore, una parte va alla piattaforma di affiliazione (vedi WorldFilia ad esempio), una parte va all’affiliato.

Ovviamente l’affiliato per far conoscere i prodotti ad un pubblico cerca di targettizarlo, profilarlo e mostrargli un’inserzione inerente ed in target.

Molto spesso, praticamente sempre si utilizzano le ADS di Facebook per veicolare traffico come quella che stai vedendo.

Ovvero Facebook a tutti gli effetti è una fonte di traffico.

Ovvero è il mezzo a pagamento tramite cui vengono veicolati i nostri messaggi promozionali e invitato l’utente al nostro sito web o landing page per completare la vendita.

Ovviamente se il sito non è veloce, non si apre, non si vede non ci sarà alcuna vendita, ma solo un click a pagamento su Facebook che non porterà ad una conversione, ovvero una vendita.

Brevemente si crea una campagna ADS, si seleziona il tuo pubblico ideale, si imposta il budget giornaliero. Facebook ti mostrerà la portata stimata dei tuoi annunci. Puoi scegliere di mostrare i tuoi annunci a determinate persone e filtrarli per età, sesso, posizione e interessi.

Una volta avviata la campagna inizierà a raggiungere gli utenti. Ovviamente avrai una spesa derivata dai costi delle campagne Facebook, e un relativo guadagno delle provvigioni.

Se immaginiamo il costo delle campagne è stato di 1000 euro e hai ricavato in provvigioni 1000 euro, il tuo ROI è stato 0 (sei andato in pareggio), se hai speso 1000, e hai guadagnato 2000, il tuo ROI è del 100%.

È pacifico dire che su grossi volumi e grossi numeri spesi in ADS un ritorno buono medio si attesa tra il 25 e il 33%.

Adesso immagina che a causa di un banalissimo errore (costo di risoluzione 4 euro) il 10% delle “casalinghe” non riescono a vedere e ad usare il tuo sito, (ma ovviamente l’annuncio FB ADS lo paghi comunque a Facebook).

Immagina che a causa di un altro errore perdi il 5% delle conversioni, sempre sulla stessa campagna e sullo stesso pubblico.

Immagina anche che a causa di altri 2 piccoli errori, perdi un altro 5% di conversioni.

Conto della serva: hai perso il 20% di conversioni. Ovvero il 20% di vendite. Ovvero il 20% di guadagni.

Il sito ideale per ogni affiliate Marketer

Raramente un Affiliate Marketer si preoccuperebbe degli aspetti tecnologici se un sito convertisse abbastanza. Quello che conta in fondo in questo tipo di attività imprenditoriale sono i guadagni, gli utili, i profitti.

Per quanto possa sembrare banale nella definizione stessa, il sito ideale per ogni affiliate marketer è un sito che vende, un sito che converte traffico in vendite e permette di avere un ritorno sull’investimento positivo, ovvero poter ottenere dei profitti e non delle perdite.

Siccome però i soldi non cadono dal cielo e nessun funnel di vendita è perfetto esistendo sempre un margine di miglioramento, ecco che gli affiliate marketer diventano dei veri e propri segugi nell’individuare tutte le problematiche e anomalie nel funnel di vendita, aiutandoci a determinare quali siano le migliori best practice per un hosting adatto alle loro esigenze.

Questo però cosa significa? Significa che un sito dovrà essere veloce, estremamente veloce, compatibile con tutti i dispositivi (avete presente Android 6 installato sul vecchio modello Samsung Galaxy della casalinga 60enne di turno a cui state proponendo la crema per la cura dell’alluce valgo?), e tutte le piattaforme.

Allo stesso modo deve funzionare benissimo con le piattaforme di affiliazione, social network e azioni di remarketing, con Google Tag Manager, ad esempio, e non subire un drop elevato nel tracciamento dei click.

Ovviamente l’uptime deve essere al 100%, e bisogna avere un’assistenza H24 su problematiche importanti come attacchi DDOS Layer3 o applicativi Layer7 in grado di filtrare nel giro di 15 minuti attacchi mirati di questo tipo.

Gli errori più comuni degli Hosting per chi fa Affiliate Marketing

Tralasceremo in questo capitolo tutti gli aspetti che concernono una campagna di successo.

La creatività, la copy, i colori, la posizione dei bottoni e le call to action, i font da scegliere, e via dicendo, in fondo siamo sistemisti orientati alle performance e non vogliamo mica ritenerci esperti di lead generation, ci mancherebbe.

Però vogliamo elencare i principali errori che vengono comunemente commessi dagli affiliate marketer, spesso in maniera del tutto inconsapevole dato che nessuno lo ha mai comunicato e ovviamente non sempre ne sono coscienti.

Va detto che i punti da trattare sono parecchi per cui il proseguo dell’articolo sarà così strutturato: un elenco puntato, con relativo titolo, descrizione più o meno ampia della problematica e ove richiesto un rimando ad un eventuale link interno al blog come approfondimento specifico dell’argomento.

Così facendo potrete prendere questa guida come un decalogo con i vari punti da depennare una volta che vorrete portare in produzione un progetto di lead generation basato su siti Web (magari WordPress) o landing page generate in modalità self-hosted con le accoppiate standard WordPress più qualche Tool WYSIWYG come Elementor, Brizy, Divi, BeaverBuilder o simili.

In ogni caso tratteremo a livello puramente teorico gli argomenti, ricordandovi che quanto qui espresso vale in linea generale per ogni sito Web presente online, che sia esso un sito per fare affiliate marketing o lead generation o altro.

1. Uptime basso e frequenti Downtime.

Avere un sito che è frequentemente down significa avere un sito che ti fa sprecare budget inutilmente, le campagne rischiano oltretutto di essere stoppate in quanto il sito non risulta raggiungibile e ti mette anche nella condizione psicologica di non vivere sereno. È ovvio che bisogna quanto meno avere un fornitore di Hosting con un Uptime di almeno il 99.99% dichiarato e un sistema di motoring proattivo che vi segnali ogni downtime come Uptime Robot o se volete fare da soli l’ottimo Uptime Kuma che abbiamo recensito qui Uptime Kuma, alternativa Open Source e Self Hosted a Uptime Robot e Status Cake.

Se vi rendete conto che il vostro Hosting Provider tende ad avere molti downtime, sia in termini di frequenza, sia in termini di durata, valutate intelligentemente di cambiare hosting provider. Nel 2022 gli standard sono ormai molto elevati e trovare un’infrastruttura di rete che garantisca un uptime come indicato non è assolutamente difficile.

2. Reperibilità dell’assistenza tecnica

Qualora non lo facciate già, dovete iniziare a tenere in considerazione la Legge di Murphy: se qualcosa può andare storta, prima o poi succederà. Valutate insomma la situazione peggiore che potrebbe capitare al vostro sito web e alla vostra landing page, downtime, un attacco hacker, un defacement, può capitare a qualsiasi ora in qualsiasi giorno. Mettete in considerazione di avere un referente tecnico e tecnologico con alta competenza che possa assistervi per problemi gravi e bloccanti a qualsiasi ora della giornata anche all’ora di pranzo il giorno di Natale o al veglione di Capodanno per intenderci. Valutate un servizio sistemistico managed piuttosto che un normale webmaster, perchè in caso di problemi gravi sopratutto di carattere di networking o hardware è molto più probabile che sia il sistemista a togliervi le castagne dal fuoco piuttosto che uno sviluppatore web. Se avete entrambe le figure disponibili e reperibili, ben per voi: “Two is meglio che one” (Cit.).

Valutate sempre di avere la possibilità di scalare nel giro di 15 minuti ad un supporto di secondo o terzo livello, ovvero riuscire a parlare non solo con l’helpdesk dell’azienda su cui siete ospitati, ma di potervi interfacciare con una figura tecnica che possa comprendere e soprattutto risolvere la problematica nel giro di pochi minuti. Avere l’assistenza reperibile e che risponda H24 è sicuramente utile, ma è più utile che oltre alla pronta risposta ci sia anche una pronta risoluzione alla problematica.

Esistono servizi managed come il nostro in cui potrai disporre di reperibilità H24 con figure tecniche e sistemisti linux senior.

Costa leggermente più di un hosting classico, ma nel momento del bisogno capirai la differenza.

3. Mancanza di strumenti di protezione e mitigazione DDOS a livello di rete ed applicativo

Purtroppo, l’ambiente dell’affiliate marketing è un ambiente problematico, molto problematico. Alla stregua del mondo del gaming online, anche il mondo dell’affiliate è preso di mira da attacchi DDOS anche piuttosto elaborati. Bisogna necessariamente che un Affiliate Marketer di successo metta in preventivo che prima o poi sarà vittima di attacchi di questo tipo, sia a livello di rete che a livello applicativo.

È importante, pertanto, che il suo hosting disponga di adeguate misure tecnologiche per limitare e mitigare il danno e respingere con successo tutti i tentativi portati a segno.

Per ciò che concerne gli attacchi di rete a livello 3 dello stack ISO/OSI è bene verificare che il provider di riferimento abbia oltre che alla capacità volumetrica per assorbire il tentativo di attacco, anche le giuste contromisure.

Noi, ad esempio, pur essendo Vendor Indipendent di fatto, preferiamo sempre disporre di datacenter che hanno una collaborazione con Arbor Networks (l’attuale Netscout). I vantaggi sono molteplici come, ad esempio, poter mitigare attacchi di svariati centinaia di gigabit in modo assolutamente automatizzato senza dover fare assolutamente niente.

Ci limitiamo insomma a prendere atto delle notifiche via mail di quando l’attacco comincia, dell’entrata in funzione dei sistemi automatici di mitigazione, e di quando l’attacco cessa.

Per gli attacchi DDOS a Livello 7 del modello ISO/OSI, ovvero quelli applicativi la cosa è diversa e raramente ci si può imbattere in sistemi di mitigazione automatizzati in quanto bisogna prima analizzare l’attacco (o gli attacchi, plurale), i relativi pattern e poi procedere col l’applicazione delle varie regole di filtering.

Bisogna avere in primis la capacità di analisi e un metodo collaudato, nonché anche gli strumenti giusti. Per ciò che riguarda l’analisi è ovvio che ci si deve rivolgere ad un fornitore che sappia fare analisi, capire dunque la portata e la tipologia dell’attacco, l’origine a livello geografico, e saper successivamente fare il deploy di regole firewall su quello che abbiamo scelto come tool di eccellenza, ovvero CloudFlare.

Di CloudFlare ne abbiamo parlato bene in diversi articoli, tra cui questo: Attacchi DDOS ed estorsioni di pagamenti in Bitcoin ? Come proteggersi con CloudFlare

L’alternativa alla mitigazione DDOS sarebbe sospendere tutte le campagne, cercare di fretta e furia un hosting come il nostro, migrare tutto con urgenza (sostenere almeno 500€ solo per il supplemento urgenza in fase onboarding del nuovo cliente) e ripartire avendo perso vendite e budget.

Ovviamente tra i criteri di scelta va necessariamente valutato anche il costo ed i costi nascosti nelle soluzioni di mitigazione DDOS. Ci sono aziende lì fuori che si fanno pagare dai 500 dollari ai 1000 dollari l’ora per il servizio di mitigazione DDOS Managed. Questo può sicuramente andar bene per una multinazionale o un’azienda di una certa importanza o dimensione, ma non è minimamente possibile ad aziende non strutturate e con budget adeguati.

Basti pensare che nel nostro servizio managed la gestione dei DDOS è inclusa senza costi aggiuntivi come valore aggiunto per il cliente finale.

4. Elevata Latenza DNS

Ci abbiamo scritto un intero articolo in merito alla scelta di Nameserver efficienti ad alta velocità e bassa latenza: L’importanza di un DNS Autoritativo veloce per la velocità del tuo sito Web.

Brevemente possiamo dire che avere un tempo di risoluzione DNS di 10ms invece di 200 ms significa risparmiare 0,2 secondi che a loro volta si vanno a sommare ad altri fattori e ad altri timing. Se ti rivolgi anche a connessioni 3G problematiche in zone con coperture non proprio ideali (hai mai visto quelle strutture ottocentesche italiane con i muri in mattone pieno spesse mezzo metro?) avere DNS veloci è sempre buona cosa.

Ti rimandiamo all’articolo sopra, liquidando questo capitolo con un consiglio davvero spassionato; Usa i Nameserver di CloudFlare.

5. Mancanza di TCP BBR per il controllo di Congestione TCP

Se ti dicessi che nel 2022 la maggior parte delle connessioni TCP/IP vengono gestite da un algoritmo di controllo chiamato CUBIC sviluppato negli anni 80?

Anche per questo argomento abbiamo scritto un articolo in merito: BBR TCP: la formula magica per le prestazioni della rete.

Negli anni 80 si può dire che non esisteva l’informatica a momenti, figuriamoci il Wi-Fi. Per questo motivo è pacifico ed ovvio che gli algoritmi di controllo della congestione del traffico fossero progettati e sviluppati pensando che tutto fosse connesso con cavo. Se c’è un ritardo di comunicazione o perdita di pacchetti, forse il cavo degrada il segnale e non supporta la velocità che è stata negoziata inizialmente per cui CUBIC permetteva di rinegoziare la velocità di trasmissione tra due host abbassando la velocità di trasmissione fino a quando questi errori e perdite di pacchetti fossero ridotti a zero o quasi.

Ad oggi le cose sono cambiate, è tutto senza fili, tutto wi-fi, 3g, 4g, 5g, una perdita di pacchetti o un aumento di latenza non significa necessariamente che “il cavo non supporta quella velocità”, pertanto non ha senso rinegoziare la velocità se effettivamente non è realmente necessario rinegoziarla. TCP BBR è un protocollo di controllo congestione scritto da Google che permette di spremere al massimo una connessione evitando di rinegoziare se non necessario la velocità nominale.

Facciamo un esempio pratico: hai una connessione 3G in un punto schifoso dello scantinato dove hai deciso di spostare l’ufficio d’estate per rimanere fresco, riesci tuttavia ad avere un’ampiezza di banda di 1megabit, poco, ma non pochissimo. La latenza aumenta a 500 ms invece dei 10ms standard, e il server con cui stai visualizzando l’ultimo elettrostimolatore per gli addominali made in China ma sponsorizzato da Cristiano Ronaldo, decide che siccome sei lento di rinegoziare la velocità a 0,1megabit ovvero 100kbit secondo.

Il sito diventa ancora più lento, tu ti spazientisci, chiudi il sito e lui perde una vendita.

Pensa ora se invece dell’algoritmo CUBIC degli anni 80, il server dove gira il sito avesse usato TCP BBR. Esso avrebbe ragionato diversamente e avrebbe capito di poter continuare a mantenere una connessione ad un megabit invece di ridurlo erroneamente a 0,1. Tu non avresti chiuso la connessione a causa del sito lento e il sito avrebbe fatto una vendita in più.

TCP BBR riguarda non solo connessioni 3G scrause come l’esempio sopra riportato, ma tutte le connessioni wi-fi, 3g, 4g, 5g, che in alcuni momenti possono rinegoziare la velocità di connessione. 100 megabit sono il doppio di 50 megabit e permette sempre di scaricare al doppio della velocità.

Sebbene TCP BBR sia un prodotto voluto ed ideato da Google e utilizzato su tutti i suoi prodotti nonchè su Google Cloud, oggi l’implementazione è molto facile a partire da Kernel 4.10 in su.

Accertati che il tuo hosting lo utilizzi nel suo e nel tuo interesse. Noi lo facciamo come pratica SEMPRE.

TCP BBR, insomma, sempre.

6. Mancanza di compressione BROTLI

Brotli è un algoritmo di compressione sviluppato da Google, che viene utilizzato per ridurre la dimensione dei file inviati ai browser web. L’algoritmo è stato rilasciato come open source nel settembre 2015, e da allora è stato adottato dalla maggior parte dei principali browser.

Brotli può comprimere i file fino al 20% più piccoli di gzip. Questo potrebbe non sembrare molto, ma ogni kilobyte conta quando si tratta di velocità del sito. Questa statistica proviene da una ricerca di Google, dove hanno testato Brotli contro gzip su un certo numero di siti web diversi e hanno scoperto che Brotli è sempre stato migliore.

Il vantaggio di Brotli rispetto a gzip è che usa un dizionario e quindi ha bisogno di inviare solo le chiavi in quel dizionario invece che l’intera frase. Questo migliora la comprimibilità, specialmente sui file che contengono molto testo ripetuto. Lo svantaggio di Brotli è che può essere più costoso in termini di tempo di CPU per comprimere, ma questa è una considerazione relativamente minore dato che il tempo di CPU è economico.

Se vuoi verificare la compressione Brotli di un sito di consigliamo questo Tool Online: https://tools.keycdn.com/brotli-test

7. Mancanza di HTTP/2

Se volessimo associare una canzone per spiegare il concetto di HTTP/2 sceglierei “I Want it all” dei Queen. Soprattutto nel ritornello “I want it all, and i want it NOW” (voglio tutto e lo voglio ora).

HTTP/2 (originariamente chiamato HTTP/2.0) è una revisione importante del protocollo di rete HTTP utilizzato dal World Wide Web. È stato derivato dal precedente protocollo sperimentale SPDY, originariamente sviluppato da Google.

HTTP/2 permette un uso più efficiente delle risorse di rete e una ridotta percezione della latenza introducendo la compressione dei campi di intestazione e permettendo scambi multipli simultanei sulla stessa connessione. Introduce anche il push non richiesto di rappresentazioni dai server ai client.

L’obiettivo principale di HTTP/2 è quello di ridurre la latenza consentendo il multiplexing completo di richieste e risposte, minimizzando l’overhead del protocollo attraverso la compressione efficiente dei campi dell’intestazione HTTP, e aggiungendo il supporto per la prioritizzazione delle richieste e il push del server.

Rispetto a HTTP/1.1, le differenze principali sono:

Multiplexing delle richieste su una singola connessione TCP rispetto alle connessioni multiple in parallelo in HTTP 1.1;

Frammentazione binaria invece di intestazioni testuali;

Codifica Huffman per una codifica più efficiente dei dati testuali;

Meccanismo di push del server che permette ad un server di inviare risposte aggiuntive prima di ricevere una richiesta corrispondente da un endpoint;

Compressione dell’intestazione utilizzando HPACK per ridurre l’overhead.

La nuova versione permette infatti di ottenere:

• prestazioni migliori,
• richieste e ricezione di più oggetti in una singola connessione TCP grazie al multiplexing,
• minore latenza,
• compressione degli header HTTP,
• un uso più efficiente delle risorse.

 

8. Mancanza utilizzo immagini Webp

Sappiamo tutti quanto siano importanti le immagini nella comunicazione “un’immagine vale più di mille parole” (Cit.) ma pochi sanno che la stessa immagine può pesare 1 Mega oppure 100Kbyte, ovvero 10 volte meno.

Soprattutto se parliamo di immagini PNG ad alta risoluzione che avrebbero potuto tranquillamente essere servite in formato webp ottimizzato.

Si può pensare al formato .WebP come a qualsiasi altro formato di immagine (JPG, GIF, PNG…) ma con caratteristiche di compressione e qualità superiori. In altre parole, le immagini in formato .WebP possono essere di dimensioni più piccole pur rimanendo ad un alto livello di qualità.

Il vantaggio principale dell’uso di .WebP è che puoi avere immagini di alta qualità con dimensioni più piccole, il che è ottimo per le prestazioni del tuo sito web. Le dimensioni più piccole significano tempi di caricamento più veloci e più traffico verso il tuo sito web poiché gli utenti non hanno bisogno di aspettare molto tempo per vedere il contenuto.

La qualità di un’immagine webp è decisamente elevata tanto che in un nostro precedente tutorial lo abbiamo utilizzato su un sito di Fotografi per matrimoni senza degradare minimamente le immagini e risparmiando importanti megabyte: Diminuire il peso di un sito Web con immagini WebP

Ci sarà sempre qualcuno che dirà che è impossibile usare le webp perchè Safari e iOS non le visualizzano per motivi di compatibilità o che CloudFlare nella versione Free, non permette di utilizzarle con successo. Sono leggende metropolitane piuttosto diffuse che significa solamente che non sanno farlo, non che non si possa fare, per cui contattaci pure.

9. Mancanza di un adeguato dimensionamento delle risorse hardware

Se parliamo di soluzioni self hosted sicuramente terremo presenti sistemi di gestione dei contenuti come WordPress e relativi plugin. Ovviamente non possiamo dire che WordPress sia basato su tecnologie moderne e veloci. Se dovessimo paragonare le moderne tecnologie asincrone come Node.js, Golang e DB noSQL come MongoDB, a PHP e MYSQL sarebbe un po’ come mettere a confronto un aereo supersonico e una utilitaria come la Fiat Punto. Tuttavia, la Fiat punto è alla portata di tutti, sia dei costi che della guida e pertanto non c’è tanto da stupirsi se al mondo ci siano più fiat punto che aerei supersonici, né tantomeno che la maggior parte delle soluzioni self hosted di landing page siano realizzate su WordPress.

Tuttavia, c’è un prezzo da pagare che è quello del corretto dimensionamento hardware e software (quello software lo vedremo in seguito). Può capitare infatti che in fase di scelta dell’istanza (dedicata o virtuale) si faccia acquisti sottodimensionati alle reali necessità che possono essere ampiamente diverse in base ai plugin utilizzati e in base alla mole di traffico che riusciamo a portare al nostro sito.

Di sicuro per lavorare bene, con la giusta memoria riservata per le varie cache software, le cache del DB, e lo spazio di esecuzione dell’interprete PHP, non si dovrebbe MAI scendere sotto ad una configurazione con 4core e almeno 8GB e dischi quantomeno SSD, meglio se nVME.

Quindi se pensate di andare su Amazon AWS, ad esempio, e cavarvela con un’istanza economica ma inferiore a quella sopra proposta, iniziate a preventivare un budget di 80 dollari al mese SOLO per l’istanza. Il sistemista vi richiederà più o meno altrettanto per una spesa mensile di circa 150 dollari.

Se optate per fornitori diversi come ad esempio Hetzner.de (il nostro fornitore di riferimento per circa il 90% dei servizi offerti) i costi sono ampiamente differenti e molto più economici.

Ovviamente almeno in linea teorica i servizi di Amazon AWS sono il non plus ultra in termini di disponibilità ed Uptime, per cui se davvero volete evitare (sempre in linea teorica) anche quei 5 minuti di downtime l’anno, l’unica soluzione ad oggi presente sul mercato sembra essere Amazon AWS. Parliamo sempre di linea teorica, poichè nella pratica abbiamo visto Amazon AWS fare down da oltre 4 ore e portare down tutti i loro clienti più importanti

Tuttavia, scegliere AWS almeno per un manager significa fare la scelta del mercato, ovvero aver scelto la migliore soluzione che chiunque avrebbe scelto, ed è una bella manleva nel caso di failure del servizio mettendo avanti le proprie ragioni: “Io ho scelto Amazon ed ho fatto la scelta del mercato“.

Che in fondo suona un po’ come dire che nessuno è mai stato licenziato per aver comprato Microsoft.

Alcuni affiliate Marketer novizi avranno sicuramente la tentazione di risparmiare sui costi scegliendo un Hosting Shared, ebbene non potrebbe esistere scelta peggiore di questa di mischiare un business performante ed esigente con siti del baretto sotto casa, della lavanderia e del blogghetto della signora Pina da Mostrapiedi in provincia di Macerata che ci parla dei suoi 4 amici pelosoni.

Dovete scegliere istanze dedicate. Che siano VPS, Cloud, Server dedicati, comunque un solo IP dedicato a voi e potenza completamente disponibile senza le limitazioni di sorta che avvengono su servizi scrausi che al primo picco vi mettono offline il sito.

 

10. Mancanza di un adeguato tuning dell’interprete PHP

Qui potremmo spendere un libro da 1000 pagine tanto ci sarebbe da dire. In primis dovete cercare di utilizzare l’ultima versione PHP che risulti compatibile col vostro sito senza dare errori di funzionamento. Ad oggi, ad esempio, PHP 8.2 sembra essere ancora incompatibile con la maggior parte dei plugin WordPress; pertanto, la scelta migliore è quella di orientarsi sulla versione di PHP 7.4.

Abbiate l’accortezza di avere un sistema di Caching PHP per velocizzare l’esecuzione del codice. L’attuale scelta standard è basata su Zend OpCache distribuito con tutte le ultimi versioni PHP di cui potrete trovare una descrizione e spiegazione in questo articolo Zend OpCache. Come accelerare PHP ?

Un altro aspetto di cui dovreste preoccuparvi è quello di usare un metodo di spawn dei processi PHP il più veloce possibile. Sappiamo che esistono 3 modalità predefinite:

• Dynamic
• On Demand
• Static

Ebbene ognuna di queste modalità hanno un lag nello spawn del processo dell’interprete PHP ad ogni richiesta e pertanto utilizzare la modalità static, ovvero già pronta spawnata e in attesa di servire nuove richieste è sicuramente più veloce delle altre due modalità.

Come potete vedere dal benchmark di seguito all’aumentare del numero di richieste concorrenti, il tempo di delay tra modalità static e le altre possono variare anche nell’ordine di 0,2 secondi (che in termini di performance è un’eternità).

Se siete dei temerari fai da te e utilizzate pannelli scrausi come Plesk o cPanel, abbiate l’accortezza di modificare le impostazioni portando lo spawn dei processi in modalità static.

11. Mancanza di un adeguato tuning del DMBS MySQL.

Ovviamente se stai usando WordPress, userai anche un Database come MySQL o suoi fork e derivati (MariaDB, Percona Server ad esempio).

Per avere delle buone performance MySQL dovresti usare un tuning adhoc della configurazione personalizzando sapientemente il my.cnf.

Va settato in maniera adeguata l’innodb cache, il numero di thread, la gestione delle Join in memoria piuttosto che su disco e molti altri parametri che vanno a determinare la velocità e l’efficienza di un database.

Oltretutto bisogna accertarsi che il vostro database NON utilizzi tabelle MyISAM ma le moderne e performanti tabelle InnoDB. Insomma, quando caricate un Database il vostro sistemista di fiducia dovrebbe anche ottimizzare ed eventualmente convertire queste tabelle ai nuovi formati.

MyISAM è il motore di archiviazione predefinito a partire da MySQL 3.23 con grandi prestazioni per la velocità di lettura. Tutte le tabelle MyISAM sono memorizzate su disco in tre file. I file hanno nomi che iniziano con il nome della tabella e hanno un’estensione che indica il tipo di file. Un file .frm memorizza il formato della tabella; un file di dati ha un’estensione .MYD (MYData); e un file indice ha un’estensione .MYI (MYIndex).

InnoDB supporta le transazioni con capacità di committing, rollback e crash-recovery per proteggere i dati degli utenti. Il lock a livello di riga di InnoDB (senza escalation a lock di granularità più grossolana) e le letture coerenti non bloccanti in stile Oracle aumentano la concorrenza multiutente e le prestazioni. InnoDB memorizza i dati degli utenti in indici clusterizzati per ridurre l’I/O per le query comuni basate sulle chiavi primarie.

InnoDB è un motore di database completamente compatibile con ACID. ACID sta per Atomicità, Consistenza, Isolamento e Durabilità. Questi sono quattro concetti fondamentali della gestione dei sistemi di database che sono rispettati dal motore di archiviazione InnoDB.

Il vantaggio principale dell’uso di InnoDB rispetto a MyISAM è che si ottiene il blocco a livello di riga quando si usa InnoDB. Questo significa che è possibile avere più utenti che accedono allo stesso database allo stesso tempo senza conflitti. Un altro vantaggio è che con InnoDB, quando un database va in crash, andrà in crash solo per un utente e non per tutti gli utenti del database. Con MyISAM, quando un database va in crash, va in crash per tutti gli utenti di quel database.

12. Mancanza di una Cache statica come Varnish Cache o FastCGI Cache di NGINX

Se stai cercando di ottimizzare e velocizzare l’apertura del tuo sito WordPress, WooCommerce o altro, ti sarai sicuramente imbattuto in post e consigli che ti parlavano di installare software o plugin di Cache.

Se sei stato fortunato avrai ascoltato anche qualche professionista parlare di Varnish Cache, piuttosto che di inutili Cache lato plugin o la più banale e meno funzionale Cache server NGINX FastCGI Cache. È una Cache molto promettente e facile da installare e configurare; tuttavia, NGINX FastCGI Cache ha delle problematiche non proprio banali almeno nella versione Free a differenza della versione NGINX PLUS.

 

 

 

 

Varnish Cache è un software lato server scritto in linguaggio C e dunque davvero molto performante. Esso è stato ideato e sviluppato tenendo a mente i migliori concetti e best practices per lo sviluppo software come la gestione dinamica della memoria, l’utilizzo di thread, memoria condivisa, socket standard POSIX e molte altre accortezze che sarebbero di fatto IMPOSSIBILI con un linguaggio interpretato come PHP.

Mentre le cache PHP sopra menzionate si attivano dopo aver eseguito il codice della cache PHP e dunque aver spawnato (generato) un processo dell’interprete PHP tramite thread PHP-FPM (Fast Process Manager), una cache Varnish risponde per primo nell’immediato senza tirare minimamente in ballo PHP e lo spawn di nuovi thread e processi, e dunque risparmiando moltissima CPU per queste operazioni che possono essere davvero molto pesanti di fronte ad un traffico Web molto elevato di migliaia o decine di migliaia di utenti visitatori.

Se vuoi comprendere meglio Varnish puoi leggere articolo come questo: Varnish Hosting

Oggi si trovano diversi fornitori di Hosting che dicono di usare Varnish ma molti lo usano in maniera non funzionante, con un bassissimo HIT ratio e del tutto inutile per traffico e campagne Facebook Advertising.

13. Utilizzo di Certificati SSL come Lets’Encrypt che non funzionano su vecchi dispositivi.

Immagina di progettare la landing page per il prodotto per l’alluce valgo, e mettere in target sulla campagna FB ADS, tutte le casalinghe italiane con età maggiore ai 50 anni. Adesso immagina che una parte di esse diciamo indicativamente il 5% utilizzino un dispositivo android economico e un po’ attempato. Adesso immaginiamo che la casalinga Carmela interessata dall’annuncio e dalle premesse e promesse miracolose faccia click sull’annuncio per effettuare l’acquisto. Voi usate Lets’Encrypt perchè è gratis e risparmiate 10 euro di certificato SSL per HTTPS, lei utilizza un vecchio Samsung 8 perchè anche lei come voi preferisce risparmiare.

Sapete cosa succede? Che il vostro sito darà errore perchè è scaduta una CA ROOT Authority Let’s Encrypt mesi e mesi fa, e dunque il certificato HTTPS che funziona correttamente su tutti gli altri dispositivi genera un’eccezione di sicurezza sul sito della Signora Carmela di Palermo.

E dunque addio lead, addio vendita, addio ritorno sull’investimento, addio budget per l’advertising. Sia chiaro, un 3-5% potrebbe anche essere un valore ininfluente che potrebbe anche essere ignorato; tuttavia, sono sicuro che certi prodotti per certe buyer persona, piuttosto che altre possono essere sicuramente più soggetti ad incontrare dispositivi datati. E pensare che sarebbe bastato installare un certificato SSL Domain Validated come RapidSSL, Verisign e simili, per risolvere in maniera definitiva il problema.

14. Avere un elevato drop delle campagne Facebook causa del Delay JS degli script di ottimizzazione.

È frequente utilizzare script come Wp Rocket per spingere i valori dei core web vitals. Tuttavia, pochi sanno che un utilizzo malsano del delay dei JS ha come effetto collaterale quello di non attivare il pixel di Facebook, generando una serie di reazioni a cascata che arriva fino alla disattivazione della campagna causa elevato drop.

L’argomento sul Delay JS e degli effetti nocivi su una campagna Facebook non può essere trattato in un paragrafetto di questo post; pertanto, abbiamo volutamente scritto un bell’articolo a proposito che spieghi sia a neofiti che ad esperti alcuni problemi in cui si possono incappare quando si punta ad ottenere un punteggio Google PageSpeed elevato senza tenere conto delle tecniche che si stanno utilizzando come quella del Delay JS : Delay JS per ottimizzare i Core Web Vitals e basse performance delle campagne Facebook ADS.

In conclusione

La filosofia da adottare nel migliorare il rendimento delle landing page per chi fa affiliate marketing non è quello di utilizzare un singolo approccio migliorativo del 50%, ma bensì disporre di tutte quelle best practices da applicare per portare piccoli miglioramenti che una volta sommati tra loro portano a importanti miglioramenti in termini di velocità ed user experience.

Può sembrar scontato, ma fare questa ottimizzazione non è fattibile utilizzando formule magiche o automatismi, ma richiede un’ottimizzazione manuale per ogni singolo sito che nella migliore delle ipotesi può richiedere 30 o 60 minuti di ottimizzazione.

Se stai pianificando una campagna Advertising da scalare e su cui vuoi investire un bel budget, è il caso di valutare tutti questi aspetti fino ad ora citati, al fine di ottenere le migliori performance e cercare di massimizzare il profitto e le conversioni.