add_header Cache-Control \"max-age=31536000, immutable\";<\/code><\/div>\nD’ora in poi, il browser ha il diritto di memorizzare le risorse per un massimo di un anno (che \u00e8 quasi come dire per sempre). Il nuovo parametro “immutable” indica che la risorsa non verr\u00e0 modificata.<\/p>\n
Ovviamente, la domanda sorge spontanea: cosa succede se abbiamo bisogno di cambiare la risorsa memorizzata nella cache? La risposta \u00e8 semplice: cambia il suo indirizzo, URL. Ad esempio, \u00e8 possibile aggiungere una versione al nome di un file. Per i documenti HTML, anche questo metodo \u00e8 applicabile, ma, di regola, viene utilizzato un periodo di memorizzazione nella cache pi\u00f9 breve (ad esempio, un minuto o un’ora).<\/p>\n
Compressione dati<\/h3>\n
Una pratica obbligatoria, \u00e8 la compressione di tutti i dati di testo quando vengono trasferiti dal server al browser. La maggior parte dei server ha un’implementazione di risposte con compressione gzip.<\/p>\n
Tuttavia, la semplice attivazione della compressione non \u00e8 sufficiente.<\/p>\n
Innanzitutto, il rapporto di compressione \u00e8 regolabile e dovrebbe essere vicino al massimo.<\/p>\n
In secondo luogo, \u00e8 possibile utilizzare la compressione statica, ovvero, pre-comprimere i file e inserirli sul disco. Dopodich\u00e9, il server cercher\u00e0 la versione compressa e la restituir\u00e0 immediatamente. In terzo luogo, \u00e8 possibile utilizzare algoritmi di compressione pi\u00f9 efficienti: zopfli (compatibile con gzip) e brotli (nuovo algoritmo di compressione). Brotli funziona solo con HTTPS. Dato che questi algoritmi (specialmente zopfli) sono costosi da comprimere, li usiamo sempre nella versione statica.<\/p>\n
Per massimizzare l’effetto della compressione dei file, il processo di minimizzazione viene applicato in maniera preliminare: eliminando le traduzioni di stringhe, spazi e altri caratteri non necessari. Questo processo \u00e8 specifico per ogni formato. Inoltre, dovresti occuparti della compressione di altri dati di testo sul sito.<\/p>\n
Utilizzare il CDN<\/h2>\n
L’applicazione del CDN (content delivery network) per accelerare i siti web, \u00e8 una misura molto pubblicizzata, con tanto marketing attorno all’essenza della tecnologia.<\/p>\n
Teoria: perch\u00e9<\/h3>\n
Inizialmente, i CDN sono stati progettati per scaricare i canali internet dei siti di broadcast media. Ad esempio, guardando un video dal vivo, diverse migliaia di spettatori creano un carico molto pesante sulla larghezza di banda del server. Inoltre, garantire una elevata qualit\u00e0 di comunicazione ininterrotta con la rimozione di client e server di grandi dimensioni, \u00e8 estremamente difficile (a causa di ritardi e instabilit\u00e0 della rete).<\/p>\n
La soluzione a questo problema \u00e8 stata creare il CDN, cio\u00e8 una rete distribuita a cui erano connessi i client (ad esempio i visualizzatori) mentre gli host di questa rete sono gi\u00e0 sul server (origine). Allo stesso tempo, il numero di connessioni al server \u00e8 stato ridotto a uno (diversi) e il numero di connessioni al CDN potrebbe raggiungere milioni, a causa della memorizzazione nella cache del contenuto da parte della rete.<\/p>\n
Oggi, la maggior parte dei CDN si posiziona come mezzo per accelerare i siti, riducendo la distanza dal contenuto al client (il visitatore del sito).<\/p>\n
Possibili effetti<\/h3>\n
Come posso velocizzare un sito usando il CDN?<\/p>\n
L’utente, di regola, si collega al server di rete pi\u00f9 vicino (in termini di tempo d’accesso) e ottiene un’elaborazione rapida per la creazione delle connessioni TCP e TLS. Inoltre, se il contenuto si trova sul server CDN, l’utente pu\u00f2 riceverlo rapidamente. Pertanto, il carico sul nostro server \u00e8 ridotto.<\/p>\n
In secondo luogo, il CDN non pu\u00f2 distribuire il contenuto senza modifiche, ma bisogna ottimizzarlo su un lato e dargli una forma pi\u00f9 compatta: comprimere le immagini, applicare la compressione al test, ecc. Grazie a tali ottimizzazioni, \u00e8 possibile ottenere un tempo di download pi\u00f9 breve.<\/p>\n
Svantaggi nell’uso di CDN<\/h3>\n
Come al solito, ai tanti vantaggi, corrispondono altrettanti svantaggi: l’oggetto potrebbe non essere nella cache del nodo CDN. Ad esempio, non \u00e8 stato ancora richiesto o non pu\u00f2 essere memorizzato nella cache (documento HTML). In questo caso, ci sono ulteriori ritardi tra il nodo CDN e il nostro server.<\/p>\n
Nonostante i CDN siano progettati per accelerare l’accesso al sito, ci sono situazioni in cui il percorso di rete sar\u00e0 meno ottimale rispetto al CDN. \u00c8 particolarmente importante per i CDN globali, per i quali la Russia non \u00e8 un mercato prioritario.<\/p>\n
Infine, le reti di distribuzione dei contenuti sono sistemi molto complessi, dove sono possibili anche crash, instabilit\u00e0 e altri problemi. Usando il CDN, aggiungiamo un ulteriore livello di complessit\u00e0.<\/p>\n
Fissiamo il risultato<\/h2>\n
Diciamo che sei riuscito a raggiungere una buona velocit\u00e0 del sito. Gli utenti e i proprietari della risorsa sono felici. Ora puoi dimenticare il problema della velocit\u00e0? Ovviamente no. Per ottenere una qualit\u00e0 costante del sito, \u00e8 necessario sviluppare e monitorare costantemente il sito<\/a>.<\/p>\nSupporto di accelerazione<\/h3>\n
Qualsiasi progetto web live viene aggiornato regolarmente, le modifiche avvengono sia nei modelli comuni (temi di design, interfacce), sia nei contenuti. Inoltre, il codice del programma (sia client che server) cambia attivamente.<\/p>\n
Ogni modifica pu\u00f2 influire sulla velocit\u00e0 del sito. Per monitorarne l’impatto, \u00e8 necessario implementare un sistema di monitoraggio della velocit\u00e0 del sito sintetico in fase di sviluppo. Pertanto, i problemi di velocit\u00e0 possono essere intercettati prima che gli utenti li notino.<\/p>\n
Per ottimizzare il contenuto in entrata, \u00e8 richiesta l’integrazione delle procedure di ottimizzazione nel sistema di gestione dei contenuti. Prima di tutto, ci\u00f2 riguarda l’elaborazione delle immagini.<\/p>\n
L’accelerazione dei siti \u00e8 un’area molto dinamica: stanno emergendo nuovi standard, il loro supporto da parte dei browser sta cambiando. Pertanto, \u00e8 importante verificare regolarmente la tecnologia del progetto, i processi e il software utilizzati.<\/p>\n
Monitorare la reale velocit\u00e0 dell’utente<\/h3>\n
Il test sintetico in condizioni di laboratorio ideali, \u00e8 estremamente utile per valutare i cambiamenti nel codice di sistema, ma non \u00e8 sufficiente. Alla fine, vogliamo che il sito funzioni in modo veloce per gli utenti reali. Per raccogliere tali dati, \u00e8 possibile monitorare la velocit\u00e0 dal lato utente (RUM – monitoraggio utente reale).<\/p>\n
Per organizzare il RUM, \u00e8 sufficiente collegare uno dei sistemi di analisi web (Yandex.Metrica, Google Analytics) e consultare i rapporti sull’ora del download del sito. Per ricevere dati pi\u00f9 dettagliati e accurati, \u00e8 possibile utilizzare servizi di monitoraggio della velocit\u00e0 specializzati.<\/p>\n
Conclusioni<\/h3>\n
Il tema della velocit\u00e0 del sito \u00e8 ampio e abbraccia molti aspetti dello sviluppo e del supporto di un’applicazione web: dal codice del server al contenuto. Ci\u00f2 significa che ottenere buoni risultati, \u00e8 impossibile non coinvolgere tutto il team di sviluppo.<\/p>\n
La cosa pi\u00f9 importante \u00e8: ricordarti degli utenti, prendendo in considerazione le varie condizioni di utilizzo del sito. L’accelerazione del sito \u00e8 un processo che si verifica con intensit\u00e0 diverse durante tutto il ciclo di vita del progetto.<\/p>","protected":false},"excerpt":{"rendered":"Tutti sanno che un sito lento non \u00e8 bello. Per questo motivo, diventa problematico risolvere problemi di tutti i giorni. A volte \u00e8 semplicemente noioso. Spesso, un sito lento \u00e8 una vera e propria rottura, tutto questo, comporta il rifiuto del servizio dell’utente, che non attende il download e va via. Questo \u00e8 importante in…","protected":false},"author":10380808,"featured_media":3348,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"pages-templates\/pages-minitools-3.php","meta":[],"categories":[60],"tags":[],"_links":{"self":[{"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/pages\/1063"}],"collection":[{"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/users\/10380808"}],"replies":[{"embeddable":true,"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/comments?post=1063"}],"version-history":[{"count":0,"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/pages\/1063\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/media\/3348"}],"wp:attachment":[{"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/media?parent=1063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/categories?post=1063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/test.sitechecker.pro\/it\/wp-json\/wp\/v2\/tags?post=1063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}