Grazie del contributo @vedova a riprova che "DIPENDE"

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.

@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)?

@MaxxG non vedo particolari controindicazioni

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.

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

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.

@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

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!

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).

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

@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

@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.