{"id":54566,"date":"2019-12-29T00:00:00","date_gmt":"2019-12-28T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj"},"modified":"2020-02-18T14:02:35","modified_gmt":"2020-02-18T11:02:35","slug":"samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj","title":{"rendered":"Hosting indipendente di risorse di terzi: bene, male, cattivo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Negli ultimi anni, sempre pi\u00f9 piattaforme per l'ottimizzazione dei progetti frontend offrono funzionalit\u00e0 di self-hosting o di proxying per risorse di terze parti. Akamai permette di definire parametri specifici<\/a><\/noindex> per URL creati autonomamente. Cloudflare dispone della tecnologia Edge Workers. Fasterzine pu\u00f2 riscrivere<\/a><\/noindex> URL sulle pagine in modo che puntino a risorse di terze parti situate sul dominio principale del sito.<\/p>\n

\"Hosting<\/a><\/noindex><\/p>\n

Se \u00e8 noto che i servizi di terze parti utilizzati nel vostro progetto non cambiano troppo spesso e che il processo di consegna ai clienti pu\u00f2 essere migliorato, \u00e8 probabile che stiate considerando il proxying di tali servizi. Con questo approccio, potete avvicinare queste risorse agli utenti e ottenere un controllo pi\u00f9 completo sulla loro memorizzazione nella cache lato client. Inoltre, questo aiuta a proteggere gli utenti da problemi causati dal 'down' di un servizio esterno o dalla degradazione delle sue prestazioni.
\n<\/a><\/noindex><\/p>\n

Buono: aumento delle prestazioni<\/h2>\n

\nL'hosting autonomo di risorse esterne migliora le prestazioni in modo tutto sommato evidente. Il browser non deve effettuare ulteriori richieste DNS, non \u00e8 necessario stabilire una connessione TCP e non \u00e8 richiesta la handshake TLS su un dominio esterno. L'impatto dell'hosting autonomo delle risorse esterne sulle prestazioni \u00e8 visibile confrontando le due immagini seguenti.<\/p>\n

\"Hosting
\nLe risorse esterne vengono caricate da fonti esterne (prelevate da qui<\/a><\/noindex>)<\/i><\/p>\n

\"Hosting
\nLe risorse esterne sono memorizzate insieme ad altri materiali del sito (prelevate da qui<\/a><\/noindex>)<\/i><\/p>\n

La situazione \u00e8 ulteriormente migliorata dal fatto che il browser sfrutter\u00e0 le capacit\u00e0 di multiplexing e prioritizzazione dei dati della connessione HTTP\/2 gi\u00e0 stabilita con il dominio principale.<\/p>\n

Se non si ospitano risorse esterne, poich\u00e9 verranno caricate da un dominio diverso da quello principale, non sar\u00e0 possibile priorizzarle. Ci\u00f2 porter\u00e0 a una competizione tra di esse per la larghezza di banda del cliente. Questo pu\u00f2 comportare che il tempo di caricamento dei materiali critici per la creazione della pagina sia significativamente pi\u00f9 lungo rispetto al tempo raggiungibile in circostanze ideali. Ecco<\/a><\/noindex> una presentazione sulla prioritizzazione di HTTP\/2, in cui tutto ci\u00f2 viene spiegato molto bene.<\/p>\n

Si pu\u00f2 supporre che l'uso degli attributi nei link a risorse esterne preconnect<\/code> aiuti a risolvere il problema. Tuttavia, se ci sono troppi link a diversi domini, questo potrebbe effettivamente sovraccaricare la connessione nel momento pi\u00f9 critico.<\/p>\n

Se si ospitano risorse esterne in modo autonomo, \u00e8 possibile controllare come queste vengono fornite al cliente. In particolare, si tratta di quanto segue:<\/p>\n