Sito web: Stasera in TVCome ridurre il "Tempo per il primo byte" sul mio sito web?
se vai alla home page, vedrete che prima del caricamento della pagina, il browser aspetta ...
come potrei ridurre Tempo per il primo byte?
Nessuno può darti una risposta dettagliata senza che tu mostri il codice responsabile della generazione del contenuto del sito - perché è lì che si trova il ritardo.
Tuttavia, dal momento che il sito utilizza PHP, si hanno più probabilità utilizzando output buffering
Dato che è il caso, il seguente codice darà un TTFB di (rete di latenza +) 2s:
<?php ob_start(); ?>
<!doctype html>
<html>
<head>
<title>Slow to Load, Slow to finish</title>
</head>
<body>
<?php
sleep(2); // Simulate slow processing
echo "Body"
?>
</body>
</html>
considerando che la presente vi darà una TTFB di rete (latenza) + 0s:
<!doctype html>
<html>
<head>
<title>Fast to load, Slow to finish</title>
</head>
<body>
<?php ob_start(); ?>
<?php
sleep(2); // Simulate slow processing
echo "Body"
?>
</body>
</html>
il momento di caricare l'intera pagina è lo stesso in entrambi i casi - solo se il ritardo è c HANGES. Se ti concentri specificamente sulla riduzione del TTFB (perché), questo dovrebbe darti informazioni sufficienti per investigare ulteriormente.
IMPORTANTE: Ci sono un sacco di frontend changes che dovresti fare prima di concentrarti su TTFB.
Il ritardo è causato dallo script lato server che genera la pagina indice.
Da un rapido sguardo al tuo sito web, posso indovinare che il sito Web utilizza PHP. Quindi, il ritardo è causato da qualcosa contenuto nel tuo script index.php.
L'hosting, la rete, l'hardware e il server HTTP (Apache) NON sono sicuramente la causa. Il tuo grafico mostra che i file statici (.css, .js e così via) vengono consegnati piuttosto velocemente.
Quindi, per maggiori dettagli è necessario fornire maggiori informazioni (l'esecuzione lenta di index.php può avere molte ragioni diverse ...).
Penso che dipenda da quali strumenti si utilizzano per misurare questo tipo di dati. Quando ho usato webpagetest.org - il tempo per il primo byte era 292 ms che è buono. Forse dovresti rieseguire il tuo assegno?
Parte di questo numero è giù fino al punto in cui ci si trova in relazione al server - maggiore è il numero di salti che devi fare - maggiore è il numero. Riguarda anche l'hardware del server e la connettività, di solito questo è qualcosa che non puoi controllare. Potresti voler esaminare altri host, ma prima dovrei eseguire alcuni altri test: far provare i tuoi amici su webpagetest.org (o simili) e vedere quali valori ottengono.
Probabilmente la soluzione più efficace è l'utilizzo di un CDN con funzionalità di memorizzazione nella cache HTML nativa (statiche e dinamiche). TTFB si basa sulla capacità di elaborare rapidamente l'HTML sul server di origine, è possibile saltare del tutto il tempo di elaborazione servendo una copia aggiornata nella cache da CDN.
Ho scritto un post su di esso di recente, che esamina i fattori di ritardo TTFB e il tempo di caricamento medio di diverse risorse (in base ai dati raccolti in sessioni 1B). Potrebbe essere utile: http://www.incapsula.com/the-incapsula-blog/item/809-using-cdn-to-improve-seo-and-ttfb
Cosa sono le" funzionalità di caching HTML nativo "? Gli unici riferimenti che riesco a trovare in questo termine sono due delle tue risposte qui su Stack overflow =). – AD7six
Probabilmente il cattivo fraseggio da parte mia. :) Intendevo solo che poteva fare il caching statico e dinamico come predefinito. –
Questi termini non significano molto quando girati senza spiegazioni. Suppongo che i mezzi statici siano "normali", cioè il CDN onora semplicemente le intestazioni di scadenza della cache e mezzi dinamici per es. il cdn riconosce che la risposta non cambia, ignorando comunque eventuali intestazione della cache e cache, e serve il risultato memorizzato nella cache immediatamente mentre nel backend effettua una richiesta per ottenere una nuova copia del contenuto (sostituendo la copia memorizzata nella cache per richieste future) - cioè simile a [meccanismo di grazia di vernice] (https://www.varnish-software.com/static/book/Saving_a_request.html#core-grace-mechanisms). – AD7six
è possibile utilizzare i servizi cloudflare e cdn per TTFB. Se non si accetta il feedback appropriato, modificare il server host.
Si prega di elaborare un po 'di più su quali servizi cloudflare e cdn sono e cosa fanno. E come risolvono il problema in questione. Fornisci anche i link, per favore - ma non rendi questo un "link only answer". – TobiMcNamobi
Mi sono occupato dello enorme TTFB (8-10 secondi) e alla ricerca disperata di una soluzione. Dopo aver effettuato ricerche e ricerche senza esito positivo, ho deciso di fare il per dare un'occhiata più da vicino al mio codice PHP e agli indici di database.
La soluzione di buffer di uscita riduce leggermente il mio TTFB ma non abbastanza. Ho avuto di nuovo lamentele da parte degli utenti.
Il vero problema è il tempo di elaborazione del server (query DB e PHP loop) e la fonte HTML generato.
Ora, suggerisco prendere questi passaggi:
Nel mio caso, restituisco una matrice di oggetti e ho controllato i miei indici per la mia tabella principale. Tutto sembrava OK ma ho dimenticato che i miei oggetti includono altri oggetti più piccoli da altri tavoli. Queste tabelle non sono state indicizzate correttamente. Da qui il mio enorme TTFB. Ho appena passato da 8 secondi a 2 secondi solo aggiungendo l'indice corretto ai tavoli giusti.
si può avere qualche ciclo in ciclo che può essere lento da elaborare. Dovresti usare un framework MVC PHP. La tua scelta. Non chiamerò nessuno.
Evitare tale codice anche se funziona. Lo so, alcuni programmatori PHP4 diranno che è buono. :)
$query = "SELECT something FROM table";
$result = mysqli_query($mysqli, $query);
if($result) {
while($row = mysqli_fetch_assoc($result)) {
$query = "UPDATE other_table SET something_else = "'.$row['something'].'";
$result2 = mysqli_query($mysqli, $query)
}
}
Ad esempio, si generare codice Javascript tramite loop PHP. La logica è OK. Il tempo di caricamento non è. Diciamo che restituisci 100 righe in un tavolo. Per ogni riga hai solo 5 azioni possibili (cambia stato, modifica, cancella, duplica, stampa). Ciò significa 5 finestre di dialogo jQuery (div HTML, con controlli) e 5 script JS moltiplicare per 100 righe = migliaia di righe di codice da scrivere su quella pagina. Il mio caso, oltre 32.000 righe sul mio codice HTML di 4 MB. Appena passato da 2 secondi a meno di 1 secondo dopo aver messo tutte queste finestre di dialogo su funzioni JS corrette.
In conclusione, (se stai ancora leggendo questo :)) non cercare alcune funzioni magiche per ridurre il tuo TTFB. Cerca il tuo codice e il tuo database.
PS: Alcune cose vi aiuterà a velocità crescente: la cache del browser e la compressione, l'uso di CDN, Minimizza HTML, CSS e JS, rinviare analisi del codice JavaScript, combinare immagini in sprite CSS ecc velocità Usa Google Page e Google Audit per ulteriori suggerimenti sul rendimento.
Gli errori in .htaccess possono anche aumentare notevolmente il TTFB.
Ho dovuto rimuovere alcune vecchie righe di codice lasciate da Wordfence per risolvere il mio TTFB di 8-12 secondi (ora 500 ms).
Questo è quello che era per me. Ho avuto un brutto file .htaccess che ha aumentato il mio TTFB di 1000ms. – Ken
Emettere la testa il più presto possibile, può essere un grande guadagno in termini di prestazioni. Se la tua testa contiene file css o script (anche se non dovrebbe), il browser potrebbe essere in parallelo con questi download. Se il browser deve attendere per analizzare il documento, non sa nemmeno cosa potrebbe scaricare. –
invia il primo byte prima di 'ob_start'' ' – ar099968