• Admin

    @andreabo in generale le CDN sono pensate proprio per gli asset statici che di solito hanno scadenze lunghe e spesso addirittura infinite quindi assolutamente sì è un caso d'uso dove non sbagli mai.


  • User

    Domanda da ignorante: se il sito è solo "locale" (e in hostato da un'azienda italiana), ossia per pubblico solo italiano, ha senso mettere su un CDN come cloudflare? Oppure servono solo se il sito è visitato da più paesi quindi le risorse vengono caricate da un punto più "vicino" all'utente?


    mangi-1 1 Risposta
  • Moderatore

    @jabba se la composizione dei suoi visitatori è fortemente localizzata in italia non ha senso mettere una CDN, i contenuti statici sarebbero comunque serviti dall'Italia (se va bene), come abbiamo visto all'inizio di di questo post attualmente per cloudflare non è così, quindi anche peggiorativo


    juanin 1 Risposta
  • Admin

    @mangi-1 @jabba diciamo che probabilmente il vantaggio della CDN è più il dynamic serving di formati più idonei in base al browser senza che tu debba muovere un dito se non hai necessità di cachare anche le pagine HTML di contenuto, ma quindi sfruttare CDN solo per immagini, video, css, js etc.

    Altro vantaggio è che scarichi il numero di richieste che arrivano ai tuoi server.

    Sul tempo di risposta degli asset statici poi dovresti fare un po' di test e vedere se è più performante la risposta dai nodi in edge oppure la tua. Non è da escludere che se anche più distante l'edge che viene colpito sia più rapida l'erogazione della CDN rispetto alla tua.

    Diciamo che vale la pena fare dei test comparativi in quel caso e mettere sulla bilancia il vantaggio del mero response time rispetto all'eventuale vantaggio di poter sfruttare il dynamic serving, brotli etc.

    Parlando di brotli e gzip ad esempio posso dirti certamente che se lavori senza CDN puoi avere risultati migliori perché puoi "pre-brotlizzare" o "pre-gzippare" a livello massimo quindi 10 e 9 rispettivamente mentre invece con CDN fanno on-the-fly con una compressione solitamente sui 5/6.

    Se hai dei bundle corposi con pre-compressione puoi guadagnare tanto e con la CDN diciamo che perdi questa opportunità. Dall'altro lato se ad esempio non hai supporto brotli sulla tua macchina e non puoi fare pre-compressione magari la CDN ti aiuta...

    In sostanza: "Dipende" :d:


    MaxxG 1 Risposta
  • Admin

    Proprio ieri mi sono imbattuto poi in un post curioso dove non necessariamente una immagine in formato più compresso e moderno porti un reale beneficio lato percezione di velocità...è un mondo difficile, ma è bello per questo.

    Fascinating issue on a current client site where we reduced their masthead image weight by over 20% by switching it to WebP. It’s now rendering almost 2× later because WebP doesn’t offer progressive rendering like the previous JPG did.

    progressive rendering

    https://twitter.com/csswizardry/status/1324440103792578562

    In sostanza il mantra è "SPORCATEVI LE MANI".


  • Moderatore

    Mi sono messo in sordina, anche perchè ognuno tende a dare esperienze proprie come massime assolute, che in vece, diciamocelo, non sempre lo sono 😉

    Tenendo conto di ciò posso solo dare la mia esperienza su

    • Argo Smart Routing

    In caso di traffico intenso, CloudFlare e il suo Argo potrebbero generare un flusso continuo di richieste anche a riposo per mantenere - passatemi il termine - cachato il tutto. In particolare, son stato contattato dalla sala dati a Zurigo (dove CloudFlare ha un tempo di risposta ancora migliore di diversi point locali comunemente usati( perchè a riposo, c'era un flusso costante da 500Mb/s a 1Gb/s, il tutto generato unicamente dalle richieste di CloudFlare. Ovviamente anche la macchina ne risentiva.

    Ora tenendo conto di ciò, e del fatto che ormai il POP di Milano dava (questo ancora prima andasse giù) sempre problemi, abbiamo fatto delle prove, e dopo mesi, posso solo dire che sia a livello di utilizzo della banda, carico della macchina, e anche SEO i benefici hanno superato ampiamente le aspettative rispetto alla situazione iniziale.

    Se si hanno particolari esigenze, un Firewall hardware e una bel sistema di ridondanza progettato accuratamente è la cosa migliore, anche perchè in tanti sono veramente convinti che anche se la macchina andasse giù, col solo CloudFlare, si potrebbe andare avanti ad offrire contenuti come se nulla fosse, magari su un e-commerce.

    Tra l'altro, in sistemi di billing, ambienti quali Varnish e CDN tenderei ad escluderli quanto più possibile, in quanto generano solo problemi, se la macchina non regge, fate un benedetto upgrade. Ma implementare una CDN su tutto il sito, è una pugnalata nello stomaco.... in sintesi rogne all'infinito, e per un hoster significa
    ticket su ticket per un problema che nemmeno ci sarebbe stato.
    Abilitare CloudFlare offrendolo come miglioria invece di upgradare il parco macchine e il network, è un tampone a breve termine, diciamocelo, prima o poi si ritorce contro come un boomerang se tutto si basa sulla CDN.

    Per il resto, ci sono casi dove può servire. Altri no. Non è il Male assoluto, ma neanche una soluzione ai problemi di rallentamento quando è la rete a far schifo 🙂

    Quanto sopra, si basa unicamente su fatti e riscontri e opinioni puramente personali, e tali intendono rimanere.


  • Admin

    Grazie del contributo @vedova a riprova che "DIPENDE" :d:

    Qui poi abbiamo preso di mira Cloudflare, ma di base il concetto è sempre valido in generale.

    Poi come dici bene ci sono siti e siti e come già inizialmente detto bisogna vedere gli specifici use cases. Riguardo al pensare che un sito possa rimanere UP anche quando sotto è tutto giù solamente grazie a una CDN è follia pure a meno di non avere uno static site generator che usa l'edge come hosting.

    Addirittura io ho notato che i vari servizi di CF tipo Argo Smart Routing, Always online etc etc su siti ben trafficati spesso causano più problemi che altro. Ad esempio errori di Origin Connection Timeout 52x che in realtà non esistono.


  • Moderatore

    @juanin ha detto in Cloudflare per velocizzare il proprio sito? Ne siete veramente sicuri?:

    quindi sfruttare CDN solo per immagini, video, css, js

    Quindi per blog, anche con sola audience italiana, va comunque bene attivare la cdn per le immagini (nel mio caso quella di shortpixel tramite il plugin su wp)?


    juanin 1 Risposta
  • Admin

    @MaxxG non vedo particolari controindicazioni


  • Moderatore

    sistemando la playlist performance ho ritrovato questo -->

    Sempre con la premessa di @juanin "DIPENDE", nel VLOG ho semplificato anche con infografica per i più profani.


  • Admin

    Vi porto un contributo interessante su Cloudflare e l'impatto sui tempi di download Googlebot con una opzione piuttosto che un'altra.

    Quando inizia la salita viene disabilitato Argo Smart Routing + Tiered Caching impostando solo Tired Caching per diagnosticare dei problemi di 524 Origin Timeout.

    Quando inizia la discesa viene riattivato Argo Smart Routing + Tiered Caching
    argo-smart-routing.jpg

    Questa parte di Argo è tutta relativa agli aspetti di instradamento quindi l'impatto è notevole.

    Considerando dunque che Argo è un prodotto Enterprise in generale nei confronti di Googlebot e in generale di accessi da zone lontane dalla location del nostro server con Cloudflare le cose non sono affatto belle ipotizzando il piano FREE utilizzato da tutti.

    Confermando le remore delle persone intervenute. Se le pagine non sono dunque cachate in EDGE al momento del passaggio in scansione di Googlebot il degrado risulta notevole senza ottimizzazioni Enterprise.


    mangi-1 1 Risposta
  • Moderatore

    @juanin ha detto in Cloudflare per velocizzare il proprio sito? Ne siete veramente sicuri?:

    Vi porto un contributo interessante su Cloudflare e l'impatto sui tempi di download Googlebot con una opzione piuttosto che un'altra.

    Quando inizia la salita viene disabilitato Argo Smart Routing + Tiered Caching impostando solo Tired Caching per diagnosticare dei problemi di 524 Origin Timeout.

    Quando inizia la discesa viene riattivato Argo Smart Routing + Tiered Caching
    argo-smart-routing.jpg

    Questa parte di Argo è tutta relativa agli aspetti di instradamento quindi l'impatto è notevole.

    Considerando dunque che Argo è un prodotto Enterprise in generale nei confronti di Googlebot e in generale di accessi da zone lontane dalla location del nostro server con Cloudflare le cose non sono affatto belle ipotizzando il piano FREE utilizzato da tutti.

    Confermando le remore delle persone intervenute. Se le pagine non sono dunque cachate in EDGE al momento del passaggio in scansione di Googlebot il degrado risulta notevole senza ottimizzazioni Enterprise.

    già! il problema è proprio questo, la maggior parte delle persone usa cloudflare perchè ha letto su un blog che va usato, ma il piano free è pieno di insidie sopratutto per i poco esperti.

    Quindi: niente bacchetta magica, olio di gomito e rendere i siti più veloci! 🙂


  • User

    Giusto un commento perchè mi ricordavo della discussione: Milan ora appare come "operational" sul sito di Cloudflare, magari torna utile a qualcuno (non so da quando).


  • Moderatore

    il potere di connect!!! da CF hanno letto e si sono vergognati! e lo hanno riabilitato 🙂


    vedova 1 Risposta
  • Moderatore

    @mangi-1 ha detto in Cloudflare per velocizzare il proprio sito? Ne siete veramente sicuri?:

    il potere di connect!!! da CF hanno letto e si sono vergognati! e lo hanno riabilitato 🙂

    Sappiamo che purtroppo queste cose succedono, tristemente 😕


    juanin 1 Risposta
  • Admin

    @vedova @mangi-1 in realtà ve lo dico io come è andata. Ho segnalato io a dei contatti diretti in Cloudflare questa cosa e mi hanno detto che in realtà quella dashboard mostrava "Non operational" anche se in realtà il nodo è "Operational" nel senso che lo mostrano solo se tutti i nodi sono operational.

    In quel caso infatti di Milano ci sono 2 nodi. Uno re-routed e l'altro no. Quindi ora hanno cambiato lo status per rispecchiare la cosa diversamente. Di fatto solo 1 nodo era re-routed mentre l'altro ok non influendo dunque sul suo corretto funzionamento.