Total Blocking Time (TBT): Τι Σημαίνει για το SEO

Το Total Blocking Time είναι μία από τις πιο παρεξηγημένες μετρήσεις απόδοσης, γιατί δεν περιγράφει πόσο γρήγορα φαίνεται μια σελίδα αλλά πόσο γρήγορα αντιδρά. Πολλά sites φορτώνουν οπτικά αστραπιαία και παρ’ όλα αυτά «κολλάνε» όταν ο χρήστης πατήσει ένα κουμπί, και αυτό ακριβώς το κενό μετρά το TBT. Στη SEO πρακτική, η διαφορά ανάμεσα στο «φαίνεται» και στο «λειτουργεί» είναι κρίσιμη, και γι’ αυτό η ομάδα της Netstar SEO δίνει στο Total Blocking Time την προσοχή που του αξίζει.

Ο όρος προέρχεται από τον τρόπο που ένας browser εκτελεί κώδικα. Το JavaScript τρέχει στο main thread, το ίδιο νήμα που χειρίζεται και τις αλληλεπιδράσεις του χρήστη. Όταν ένα κομμάτι κώδικα μονοπωλεί αυτό το νήμα για πολλή ώρα, ο browser δεν μπορεί να απαντήσει σε clicks, taps ή scrolls. Αυτές οι περίοδοι αδράνειας αθροίζονται και σχηματίζουν το Total Blocking Time.

Σε αυτό το άρθρο εξηγούμε τι μετρά ακριβώς το TBT, πώς συνδέεται με το TTI και γιατί λειτουργεί ως το lab proxy για τη μέτρηση πεδίου INP. Θα δούμε τις βασικές αιτίες ενός υψηλού Total Blocking Time, τις τεχνικές μείωσής του, τη σχέση του με τα σήματα κατάταξης της Google και τον πρακτικό τρόπο μέτρησης στο Lighthouse με τα σωστά thresholds.

Τι είναι το Total Blocking Time και γιατί αφορά το SEO;

Το Total Blocking Time είναι μια lab metric που μετρά το συνολικό διάστημα κατά το οποίο το main thread ήταν μπλοκαρισμένο από long tasks ανάμεσα στο First Contentful Paint και το Time to Interactive, με αποτέλεσμα η σελίδα να μην μπορεί να απαντήσει σε input.

Κάθε task που τρέχει στο main thread και διαρκεί πάνω από 50ms θεωρείται long task. Το TBT δεν μετρά ολόκληρη τη διάρκεια αυτών των tasks, αλλά μόνο το «blocking» κομμάτι τους, δηλαδή τον χρόνο πέρα από το όριο των 50ms. Ένα task 70ms συνεισφέρει 20ms blocking time, ενώ ένα task 200ms συνεισφέρει 150ms.

Η λογική πίσω από αυτό το όριο είναι ότι ο ανθρώπινος εγκέφαλος αντιλαμβάνεται καθυστερήσεις κάτω των 50ms ως άμεσες. Πάνω από αυτό το κατώφλι, η σελίδα αρχίζει να γίνεται αισθητά μη responsive. Το άθροισμα όλων αυτών των blocking κομματιών δίνει μια μοναδική τιμή σε χιλιοστά του δευτερολέπτου που περιγράφει με ακρίβεια πόσο «κουμπωμένη» ήταν συνολικά η σελίδα κατά τη διάρκεια της φόρτωσης και πριν γίνει πλήρως διαδραστική.

Η σύνδεση με το SEO προκύπτει επειδή η responsiveness αποτελεί πλέον μετρήσιμο τμήμα της εμπειρίας χρήστη. Μια σελίδα που εμφανίζεται γρήγορα αλλά αγνοεί τα clicks για δευτερόλεπτα δημιουργεί απογοήτευση, αυξάνει την εγκατάλειψη και αποδυναμώνει τα σήματα συμπεριφοράς που η Google παρακολουθεί έμμεσα μέσω της συνολικής ποιότητας της σελίδας.

Πώς σχετίζεται το Total Blocking Time με το TTI και το SEO;

Το Total Blocking Time και το Time to Interactive μετρούν την ίδια περίοδο φόρτωσης από διαφορετική οπτική: το TTI ορίζει πότε η σελίδα γίνεται πλήρως διαδραστική, ενώ το TBT ποσοτικοποιεί πόσο μπλοκαρισμένο ήταν το main thread μέχρι εκείνη τη στιγμή.

Το Time to Interactive σηματοδοτεί το χρονικό σημείο όπου η σελίδα έχει εμφανίσει περιεχόμενο, έχει συνδέσει τους περισσότερους event handlers και απαντά σε αλληλεπιδράσεις μέσα σε 50ms. Είναι ένα σημείο στον χρόνο, μια στιγμή. Δίνει την απάντηση στο ερώτημα «πότε», αλλά όχι στο ερώτημα «πόσο άσχημα».

Το TBT συμπληρώνει αυτή την εικόνα μετρώντας την ένταση του προβλήματος. Δύο σελίδες μπορεί να έχουν παρόμοιο TTI, αλλά η μία να είχε λίγα μικρά μπλοκαρίσματα και η άλλη μερικά τεράστια long tasks. Το TBT αποκαλύπτει αυτή τη διαφορά, γι’ αυτό και θεωρείται πιο χρήσιμος δείκτης για βελτιστοποίηση από το ίδιο το TTI.

Από πλευράς διάγνωσης, το ζεύγος TTI και TBT καθοδηγεί τις προτεραιότητες. Ένα υψηλό TBT υποδεικνύει βαριά εκτέλεση κώδικα κατά τη φόρτωση, κάτι που οι υπηρεσίες SEO αντιμετωπίζουν με τεχνικές βελτιστοποίησης του JavaScript και αναδιάρθρωσης του φόρτου εργασίας στο main thread.

Γιατί το Total Blocking Time είναι το lab proxy για το INP στο SEO;

Το Total Blocking Time λειτουργεί ως lab proxy για το INP, επειδή και τα δύο μετρούν την ικανότητα της σελίδας να απαντά σε αλληλεπιδράσεις: το TBT στο lab περιβάλλον κατά τη φόρτωση και το INP στο field data καθ’ όλη τη διάρκεια της επίσκεψης.

Το Interaction to Next Paint είναι μια μέτρηση πεδίου που καταγράφει πόσο αργεί η σελίδα να ανταποκριθεί οπτικά στις αλληλεπιδράσεις πραγματικών χρηστών. Επειδή απαιτεί ανθρώπινο input, δεν μπορεί να μετρηθεί άμεσα σε ένα συνθετικό lab test, όπου δεν υπάρχει χρήστης που να πατάει κουμπιά. Εδώ το TBT καλύπτει το κενό.

Η συσχέτιση δεν είναι τυχαία. Και τα δύο εξαρτώνται από το πόσο απασχολημένο είναι το main thread. Ένα site με πολλά long tasks θα έχει υψηλό TBT στο lab και, σχεδόν πάντα, κακό INP στο πεδίο, γιατί τα ίδια long tasks μπλοκάρουν και τις μεταγενέστερες αλληλεπιδράσεις. Η βελτίωση του ενός τραβά συνήθως μαζί του και το άλλο.

Αυτή η σχέση κάνει το TBT πολύτιμο εργαλείο πρόβλεψης. Πριν μια σελίδα συγκεντρώσει αρκετή κίνηση ώστε να υπάρξουν αξιόπιστα field data για το INP, η ομάδα ανάπτυξης μπορεί να βασιστεί στο TBT για να εντοπίσει και να διορθώσει προβλήματα responsiveness. Η σύνδεση του INP ως Core Web Vital με το TBT είναι η γέφυρα ανάμεσα στο εργαστηριακό και το πραγματικό περιβάλλον.

Ποιες είναι οι βασικές αιτίες υψηλού Total Blocking Time στο SEO;

Οι βασικές αιτίες υψηλού Total Blocking Time είναι η βαριά εκτέλεση JavaScript, τα third-party scripts που μονοπωλούν το main thread και οι render-blocking resources που καθυστερούν τη διαδραστικότητα, μετατρέποντας τη φόρτωση σε σειρά από long tasks.

Η κύρια πηγή είναι σχεδόν πάντα το ίδιο το JavaScript και το SEO. Όταν ο browser κατεβάζει ένα μεγάλο bundle, πρέπει να το κάνει parse, compile και execute, και όλη αυτή η εργασία τρέχει στο main thread. Ένα μονολιθικό bundle εκατοντάδων kilobytes παράγει long tasks που μπλοκάρουν το νήμα για εκατοντάδες χιλιοστά.

Η δεύτερη μεγάλη πηγή είναι τα third-party scripts: tag managers, analytics, chat widgets, διαφημιστικά δίκτυα και κουμπιά κοινωνικών δικτύων. Αυτά εκτελούνται στο ίδιο main thread με τον δικό σας κώδικα, αλλά βρίσκονται εκτός του ελέγχου σας ως προς το πόσο βαριά είναι. Ένα μόνο κακογραμμένο third-party tag μπορεί να εκτοξεύσει το TBT.

Η τρίτη αιτία αφορά τους render-blocking resources, δηλαδή synchronous scripts και stylesheets που εμποδίζουν τον browser να προχωρήσει. Αυτά καθυστερούν τόσο το rendering όσο και τη στιγμή που το main thread ελευθερώνεται, παρατείνοντας το παράθυρο μέσα στο οποίο συσσωρεύεται blocking time.

Πώς μειώνετε το Total Blocking Time για καλύτερο SEO;

Το Total Blocking Time μειώνεται με code splitting, deferring και async φόρτωση scripts, σπάσιμο των long tasks σε μικρότερα κομμάτια, μεταφορά εργασίας σε web workers, αφαίρεση unused JavaScript και ταχύτερη απόκριση server, ώστε το main thread να μένει ελεύθερο.

Το code splitting χωρίζει το μονολιθικό bundle σε μικρότερα τμήματα που φορτώνουν μόνο όταν χρειάζονται. Αντί να εκτελείται όλος ο κώδικας στην αρχική φόρτωση, μεταφέρεται μέρος του σε on-demand chunks. Παράλληλα, οι ιδιότητες defer και async απομακρύνουν τα scripts από το critical path, ώστε να μην μπλοκάρουν το parsing του εγγράφου.

Το σπάσιμο των long tasks είναι η πιο άμεση τεχνική. Ένα task που τρέχει 300ms συνεχόμενα μπλοκάρει το νήμα για 250ms blocking time. Διασπώντας το σε πέντε κομμάτια των 60ms με yielding ανάμεσά τους, ο browser αποκτά ευκαιρίες να απαντήσει σε input μεταξύ των tasks, και το συνολικό blocking time καταρρέει. Η μεταφορά υπολογιστικά βαριάς λογικής σε web workers απελευθερώνει τελείως το main thread, αφού οι workers τρέχουν σε ξεχωριστό νήμα.

Η αφαίρεση unused JavaScript μέσω tree-shaking και η ελάφρυνση των dependencies μειώνουν τον συνολικό όγκο κώδικα προς εκτέλεση. Τέλος, μια ταχύτερη απόκριση από τον server, που εξετάζεται μέσω του TTFB και της απόκρισης διακομιστή, στέλνει νωρίτερα το HTML και τα assets, ώστε ο browser να ξεκινά την επεξεργασία πιο σύντομα και να ολοκληρώνει τα tasks πριν ο χρήστης προσπαθήσει να αλληλεπιδράσει.

Είναι το Total Blocking Time παράγοντας κατάταξης για το SEO;

Το Total Blocking Time δεν είναι άμεσος παράγοντας κατάταξης, αλλά μια lab metric του Lighthouse που προβλέπει το INP, τη μέτρηση πεδίου που ανήκει στα Core Web Vitals και τροφοδοτεί τα page experience signals που η Google αξιολογεί.

Η Google έχει δηλώσει με σαφήνεια ότι τα lab scores του Lighthouse δεν χρησιμοποιούνται απευθείας στον αλγόριθμο κατάταξης. Αυτό που μετράει ως σήμα είναι τα field data των πραγματικών χρηστών, όπως καταγράφονται στο Chrome User Experience Report. Το TBT δεν εμφανίζεται εκεί, επομένως η Google δεν το «βλέπει» άμεσα.

Παρ’ όλα αυτά, η σημασία του παραμένει τεράστια, γιατί προβλέπει το INP, που πράγματι ανήκει στα σήματα. Όταν βελτιώνετε το TBT στο lab, βελτιώνετε σχεδόν πάντα και το INP στο πεδίο, και αυτό το πεδιακό INP είναι που ενισχύει τα page experience signals. Με άλλα λόγια, το TBT είναι το τιμόνι και το INP το ταχύμετρο.

Αυτή η διάκριση αλλάζει τον τρόπο εργασίας. Αντί να κυνηγάτε ένα τέλειο lab score ως αυτοσκοπό, χρησιμοποιείτε το TBT ως διαγνωστικό εργαλείο που οδηγεί σε μετρήσιμη βελτίωση του πραγματικού INP. Η ομάδα ανάπτυξης κερδίζει έναν γρήγορο, επαναλήψιμο δείκτη που δεν απαιτεί να περιμένει εβδομάδες συσσώρευσης field data για να επιβεβαιώσει μια διόρθωση.

Πώς μετράτε το Total Blocking Time στο Lighthouse για το SEO;

Το Total Blocking Time μετριέται στο Lighthouse, στο PageSpeed Insights και στο Performance panel των Chrome DevTools, όπου εμφανίζεται ως μία τιμή σε χιλιοστά του δευτερολέπτου μαζί με ανάλυση των long tasks που το προκάλεσαν.

Το πιο προσιτό σημείο μέτρησης είναι το PageSpeed Insights, που τρέχει Lighthouse σε συνθετικό περιβάλλον και επιστρέφει το TBT μέσα στο τμήμα των lab metrics. Δίπλα του εμφανίζεται και η διάγνωση «Total Blocking Time» με λίστα των βαρύτερων tasks, ώστε να εντοπίσετε ποιο script ευθύνεται.

Τα thresholds που ορίζει το Lighthouse είναι σαφή. Ένα TBT κάτω από 200ms θεωρείται καλό, μια τιμή ανάμεσα σε 200ms και 600ms χρειάζεται βελτίωση, ενώ οτιδήποτε πάνω από 600ms κρίνεται κακό. Αυτά τα όρια αφορούν τη συνθετική μέτρηση mobile, που είναι αυστηρότερη από το desktop επειδή προσομοιώνει πιο αδύναμο επεξεργαστή.

Για βαθύτερη ανάλυση, το Performance panel των DevTools καταγράφει ολόκληρη τη ροή εκτέλεσης και επισημαίνει με κόκκινο τα long tasks πάνω από 50ms. Εκεί βλέπετε ποια συναρτήση κρατά το main thread, πόσο διαρκεί και από ποιο αρχείο προέρχεται, μετατρέποντας έναν αφηρημένο αριθμό σε μια συγκεκριμένη, ταξινομημένη λίστα διορθώσεων με σαφείς προτεραιότητες υλοποίησης.

Συχνές ερωτήσεις: Total Blocking Time;

Ποια είναι η ιδανική τιμή Total Blocking Time;

Στο Lighthouse, ένα TBT κάτω από 200ms θεωρείται καλό, ανάμεσα σε 200ms και 600ms χρειάζεται βελτίωση και πάνω από 600ms κρίνεται κακό. Στόχος είναι να μένετε σταθερά στην πράσινη ζώνη κάτω των 200ms σε mobile προσομοίωση, που είναι το αυστηρότερο σενάριο μέτρησης.

Διαφέρει το Total Blocking Time από το First Input Delay;

Ναι, διαφέρουν σημαντικά. Το First Input Delay μετρούσε μόνο την πρώτη αλληλεπίδραση στο πεδίο, ενώ το TBT είναι lab metric που αθροίζει όλο το blocking time κατά τη φόρτωση. Το FID αντικαταστάθηκε από το INP, και το TBT παραμένει ο καλύτερος εργαστηριακός δείκτης πρόβλεψης αυτού του νέου INP.

Μπορεί μια γρήγορη σελίδα να έχει υψηλό Total Blocking Time;

Απολύτως. Μια σελίδα μπορεί να εμφανίζει το περιεχόμενό της οπτικά σε λιγότερο από δύο δευτερόλεπτα και ταυτόχρονα να έχει υψηλό TBT, αν βαρύ JavaScript εκτελείται στο παρασκήνιο. Η οπτική φόρτωση και η διαδραστικότητα είναι δύο ξεχωριστές διαστάσεις της απόδοσης που δεν συμβαδίζουν πάντα.

Πώς επηρεάζουν τα third-party scripts το Total Blocking Time;

Τα third-party scripts εκτελούνται στο ίδιο main thread με τον κώδικά σας, οπότε ένα βαρύ tag, widget ή διαφημιστικό δίκτυο προσθέτει long tasks εκτός του ελέγχου σας. Η καθυστερημένη φόρτωση, η χρήση facades για embeds και ο αυστηρός έλεγχος των tags στον tag manager περιορίζουν αυτή τη συνεισφορά.

Βελτιώνει το server-side rendering το Total Blocking Time;

Όχι αυτόματα. Το server-side rendering στέλνει έτοιμο HTML νωρίτερα, αλλά αν ακολουθεί βαρύ hydration με πολύ JavaScript, το main thread μπλοκάρει ξανά και το TBT παραμένει υψηλό. Η ουσιαστική βελτίωση προέρχεται από λιγότερο και πιο αποδοτικό client-side JavaScript, ανεξάρτητα από το πού γίνεται το αρχικό rendering.

Κάθε πόσο πρέπει να ελέγχω το Total Blocking Time;

Ιδανικά σε κάθε σημαντική αλλαγή κώδικα και πριν από κάθε deployment. Η ένταξη ελέγχου TBT στο CI/CD pipeline εντοπίζει regressions πριν φτάσουν στην παραγωγή. Παράλληλα, παρακολουθείτε το πεδιακό INP μηνιαία, ώστε να επιβεβαιώνετε ότι οι εργαστηριακές βελτιώσεις μεταφράζονται σε πραγματικό όφελος για τους χρήστες.

Συμπέρασμα

Το Total Blocking Time είναι ο πιο καθαρός εργαστηριακός δείκτης για το αν μια σελίδα είναι πραγματικά responsive ή απλώς δείχνει γρήγορη. Μετρώντας πόσο μπλοκάρει το main thread από long tasks ανάμεσα στο FCP και το TTI, αποκαλύπτει προβλήματα διαδραστικότητας που η οπτική ταχύτητα κρύβει. Επειδή προβλέπει αξιόπιστα το INP, η βελτίωσή του οδηγεί άμεσα σε ισχυρότερα page experience signals και καλύτερη πραγματική εμπειρία χρήστη.

Η πρακτική προσέγγιση είναι ξεκάθαρη: μετρήστε με Lighthouse, εντοπίστε τα long tasks, σπάστε τα, αφαιρέστε unused JavaScript, ελέγξτε τα third-party scripts και επιταχύνετε τον server. Αυτή η μεθοδική δουλειά μετατρέπει έναν αφηρημένο αριθμό σε απτό όφελος κατάταξης και μετατροπών, και είναι ακριβώς το είδος τεχνικής βελτιστοποίησης που η Netstar SEO Agency εφαρμόζει σε κάθε project.