Намаляване на TBT времето с отложено зареждане на JavaScript (Defer/Async)

Отложеното зареждане на JavaScript е метод за намаляване на времето за блокиране на страницата (Total Blocking Time, TBT), като се отлага зареждането на JavaScript файловете, които пречат на браузъра да визуализира съдържанието на страницата. С други думи, добавяйки атрибутите defer или async към некритичните скриптове, вие намалявате времето, през което основният поток е блокиран; по този начин потребителят вижда страницата по-бързо, може да кликне по-рано и метриките на Core Web Vitals се подобряват. За да приложите отложено зареждане на JavaScript на вашия сайт, първо трябва да определите кои файлове са критични, за скриптове с зависимости обикновено трябва да се използва defer, а за независими трети страни – предимно async, и след промените трябва да измерите TBT стойността с помощта на PageSpeed Insights, Lighthouse и Chrome DevTools.

Проблемите с производителността на съвременните уебсайтове често произтичат не от изображенията, а от неконтролираното използване на JavaScript. Например, в електронен магазин, ако продуктови филтри, чат на живо, рекламни пиксели, кодове за анализ, приставки за коментари, инструменти за A/B тестове и скриптове на теми се зареждат едновременно, основният поток на браузъра може да бъде блокиран за дълго време. Това явление е особено изразено на мобилни устройства. Дори когато потребителят вижда заглавието на екрана, той може да не получи отговор, когато докосне менюто; в отчета на Lighthouse TBT изглежда висок.

В това ръководство ще разгледаме какво правят атрибутите defer и async, кога да ги използвате, как да ги приложите в WordPress и персонализирани софтуерни проекти, на какво да обърнете внимание при измерване и реалистичните печалби от TBT стъпка по стъпка. Препоръките за сайтове, хоствани на инфраструктурата на Hostragons, са в съответствие с общите уеб стандарти; ще обсъдим и как правилният хостинг, CDN, SSL и кеширане могат да подкрепят оптимизацията на JavaScript. Hostragons пакети за уеб хостинг

Какво е TBT и защо е тясно свързано с JavaScript?

TBT е съкращение от Total Blocking Time и измерва блокировката на основния поток, която забавя готовността на страницата за потребителско взаимодействие. В лабораторните тестове на Lighthouse, излишъкът от дълги задачи, които надвишават 50 милисекунди между First Contentful Paint и Time to Interactive, увеличава TBT стойността. Например, ако една JavaScript задача отнема 180 ms, то 130 ms от това време след първите 50 ms допринася за блокировката.

Тази метрика е критична за потребителското изживяване. Защото, ако един посетител докосне менюто, бутона за добавяне в количката или полето за търсене след отваряне на страницата, а браузърът все още изпълнява JavaScript, взаимодействието се забавя. Потребителят може да интерпретира това като замръзване, бавен отговор или неработещ сайт. Според стандартите за SEO през 2026 г. Google не обобщава опита на страницата в единен рейтинг, но сайтовете, които предлагат бързо и стабилно взаимодействие, осигуряват предимства както за удовлетвореността на потребителите, така и за процента на конверсия.

Обичайни признаци на висока TBT стойност

• TBT стойността в мобилния отчет на PageSpeed Insights надвишава 300 ms.
• В отчета на Lighthouse се появяват предупреждения за намаляване на времето за изпълнение на JavaScript или минимизиране на работата на основния поток.
• Менюто, слайдерът, филтриращите полета или формите реагират бавно, въпреки че страницата е видима.
• Трети страни реклами, чат на живо или скриптове за анализ изглеждат с високи разходи в отчета.
• Особено на входно ниво Android устройства се наблюдават забавяния при скролиране и кликване.

Целта е TBT стойността да бъде под 200 ms, което се счита за здравословно за повечето сайтове с съдържание. За по-сложни интерфейси на електронна търговия или SaaS, просто използването на defer и async може да не е достатъчно; може да се наложи разпределение на кода, премахване на ненужни пакети, кеширане, подобряване на времето за отговор на сървъра и редактиране на критичния CSS. Въпреки това, отложеното зареждане на JavaScript е едно от първите и бързи оптимизации, които да се приложат в повечето проекти.

Какво е Defer и Async?

Когато се използва един скрипт етикет в HTML по подразбиране, браузърът спира парсинга на HTML, изтегля JavaScript файла, изпълнява го и след това продължава с изграждането на страницата. Това поведение е понякога необходимо за критични скриптове; обаче, използването му за всеки файл генерира ненужни забавяния. Атрибутите defer и async променят това поведение, като обвързват изтеглянето и изпълнението на файла с различни правила.

Как работи Defer?

Скрипт файлът с добавен атрибут defer се изтегля на заден план, докато парсингът на HTML продължава; обаче, изпълнението му се извършва след парсинга на HTML документа. Освен това, ако има няколко файла с defer, те запазват реда, в който са написани в HTML. Поради това, той често е безопасен избор за JavaScript файлове с взаимозависимости. Например, ако първо трябва да се изпълни библиотека, след това свързаният скрипт на темата може да бъде подходящ за defer.

Пример за използване е следният: <script defer src=/js/app.js></script>. В този случай файлът app.js се изтегля без да блокира първоначалното чертане на страницата, и се изпълнява последователно, когато DOM е готов. В съвременните браузъри, defer се поддържа широко и е надежден инструмент за оптимизация за класически скрипт файлове.

Как работи Async?

Скрипт с добавен атрибут async също се изтегля, докато парсингът на HTML продължава; обаче, веднага щом изтеглянето приключи, той се изпълнява. Докато това става, парсингът на HTML може да бъде временно спрян. Async не гарантира реда между файловете. Първият изтеглен файл се изпълнява пръв. Поради това, той е по-подходящ за независими скриптове за анализ, реклама, пиксели, външни джаджи или скриптове за социални медии.

Пример за употреба: <script async src=/js/analytics.js></script>. Този файл не трябва да изчаква да се изпълни друг локален скрипт. Ако analytics.js е свързан с променлива, която е определена по-късно в страницата, или с друга библиотека като jQuery, async може да доведе до грешки. Следователно async е бърз, но изисква внимателна класификация.

Сравнителна таблица на Defer и Async

Практичното правило е следното: Ако файлът ви трябва да работи в ред, започнете с defer. Ако файлът ви е напълно независим, обмислете async. Ако не сте сигурни, първо изпробвайте defer в тестовата среда, проверете за грешки в конзолата и критични взаимодействия. Ръководство за стейджинг среда и архивиране

Стъпка по стъпка план за прилагане на отложено зареждане на JavaScript

Добавянето на defer или async към произволен скрипт етикет може да изглежда, че веднага повишава резултата, но на производствения сайт може да наруши критични функции като плащане, търсене, меню, проверка на формуляри или количка. За здравословно приложение трябва да се използва цикъл на измерване, класификация, малки промени, тест и наблюдение.

1. Измерете текущата производителност

Преди да започнете, създайте базова стойност. Запишете мобилните и десктоп оценките с PageSpeed Insights. Запишете TBT, First Contentful Paint, Largest Contentful Paint и Speed Index стойностите в отчета на Lighthouse. Проверете основния поток в раздела Performance на Chrome DevTools; дългите жълти блокове обикновено показват разходите за парсинг, компилиране и изпълнение на JavaScript.

Можете да подготвите примерна начална таблица: мобилен TBT 780 ms, време за изпълнение на JavaScript 2,8 секунди, работа на основния поток 4,5 секунди. Ако след оптимизация мобилният TBT спадне до 280 ms, вие ще постигнете приблизително 64% подобрение. Тези конкретни записи улесняват екипа да види кои промени са работили.

2. Извършете инвентаризация на скриптовете

Изброявайте всички JavaScript файлове, заредени в кода на страницата или в раздела Network. Определете източника, размера, кога е нужен и зависимостите на всеки файл. Разделянето на файловете в следните групи ще улесни работата ви:

• Критични скриптове: Кодове, необходими незабавно за първоначалното визуализиране или основната навигация.
• Зависими локални скриптове: Теми, слайдери, филтри, галерии и модули на приложения.
• Независими трети страни скриптове: Анализ, реклама, пиксели, чат и компоненти на социални медии.
• Ненужни или стари скриптове: Файлове, останали от неизползвани приставки.
• Скриптове, които трябва да се зареждат условно: Необходими само на определени страници, като проверка на формуляри на страница за контакт.

Най-добрата оптимизация понякога не е добавянето на defer, а премахването на ненужен скрипт. Компресиран файл от 90 KB може да генерира разходи над 300 ms на мобилно устройство, включително парсинг и изпълнение. Поради това, е по-добре да се изчистят ненужните файлове, след което да се отложи зареждането на останалите.

3. Определете файловете, на които ще приложите Defer

Обикновено основните скриптове на темата, поведението на менюто, кодовете на слайдерите, модулите на продуктовите галерии и файловете на приложението са добри кандидати за defer. Въпреки това, важното условие е скриптът да не бъде прекалено зависим от стари и блокиращи методи като document.write, и да е приемливо да се изпълни след готовността на DOM.

В WordPress тема jquery-migrate, основният файл на темата и скриптовете на приставките могат да съдържат сложни зависимости. Правенето на jQuery ядро async е рисковано за повечето сайтове, тъй като много приставки изчакват реда на jQuery. Вместо това, по-безопасно е да приложите контролирано defer за файлове, зависими от jQuery, или да използвате опции за оптимизирано зареждане на ниво приставка. Ръководство за оптимизация на скоростта на WordPress

4. Изберете файловете, на които ще приложите Async

Google Analytics, рекламни тагове, Facebook Pixel, LinkedIn Insight Tag, някои външни джаджи за чат и кодове за споделяне в социалните медии са кандидати за async. Въпреки това, не всеки трети странен скрипт е еднакъв. Някои инструменти за чат на живо може да искат да създадат сесия на потребителя веднага след зареждане на страницата, докато други рекламни системи могат да изчакват определен ред на контейнера. Поради това е необходимо да се провери документацията.

Направата на независим анализ код async обикновено не вреди на потребителското изживяване. Въпреки това, за да се намали рискът от загуба на данни, проверете триггерите в реално време. Ако използвате мениджър на тагове, настройте тригерите вместо да натрупвате всички тагове в един контейнер. Например, скриптът за проследяване на коментари не трябва да се зарежда на страници без форма за коментари, а скриптът за взаимодействие с продуктите не трябва да се зарежда на страници без продуктови описания.

5. Добавете условно и базирано на събития зареждане

Defer и async са добро начало; обаче, зареждането на JavaScript файлове в зависимост от поведението на потребителя може да окаже по-голямо влияние върху TBT. Чат на живо може да се зарежда не веднага след отваряне на страницата, а когато потребителят остане 5 секунди или кликне на бутона за помощ. Кодът за вграждане на карта може да се зарежда, когато потребителят скролира до секцията за контакти. Кодът за видеоплейър може да се извика, когато потребителят натисне бутона за възпроизвеждане.

Този подход е особено ефективен за сайтове с съдържание и корпоративни уебсайтове. Защото посетителят не се нуждае от всякакви джаджи на всяка страница. Премахването на 200 KB JavaScript от първоначалното зареждане може да намали TBT стойността с хиляди милисекунди на слаби мобилни процесори.

6. Тествайте и внедрявайте постепенно

Вместо да прилагате промени директно на живия сайт, опитайте в тестова среда. Извършете ръчни тестове на критични страници като начална страница, страница на категория, страница на продукт или услуга, страница за контакт, форма за вход и процес на плащане. Проверете за грешки в конзолата на браузъра. Особено грешки от типа Cannot read property, is not defined и undefined function показват проблеми с реда или зависимостите.

При преминаване на живо, напредвайте на малки групи. Първо оптимизирайте независимите трети странни скриптове, след което преминете към скриптовете на темата. Повторете отчета на Lighthouse след всяка промяна с еднаква мрежа и симулация на устройства. Не разчитайте само на едно измерване; вземането на средната стойност от 3 теста дава по-надеждни резултати.

Бележки за прилагане на Defer и Async на WordPress сайтове

JavaScript файловете в WordPress екосистемата се зареждат чрез функцията wp_enqueue_script на темата и приставките. От 2026 г. насам, в модерните версии на WordPress, стратегиите за скриптове могат да бъдат определени по-контролируем начин. Въпреки това, стари теми, приставки за изграждане на страници и несъвместими приставки за оптимизация могат да предизвикват конфликти.

Ако използвате приставка за производителност, вместо да отложите всички JavaScript с едно кликване, създайте списък с изключения. Страницата за плащане, входа на членове, администраторския панел, проверката на сигурността и скриптовете за captcha могат да бъдат чувствителни. На сайт, използващ WooCommerce, компонентите на количката, скриптовете на платежния портал и селекторите на вариации трябва задължително да бъдат тествани. Решения за WooCommerce хостинг

Практичното подреждане за WordPress може да бъде следното: Първо, премахнете ненужните приставки. След това, направете условни за зареждане на файловете на приставките, които трябва да се зареждат само на определени страници. След това опитайте defer в скриптовете на темата и приставките. Накрая, използвайте async или отложено зареждане в независимите трети странни кодове. Този метод намалява риска от големи проблеми, свързани с еднократни промени.

Какво да имате предвид при персонализирани софтуерни и фреймуърк проекти

Оптимизацията на JavaScript в съвременни структури като React, Vue, Angular, Next.js, Nuxt и подобни не е само добавяне на defer в HTML етикета. Размерът на пакета, разпределението на кода, tree shaking, динамичен импорт и разходите за хидратация са определящи за TBT. Ако един голям пакет файл е 700 KB, дори с defer, основният поток може да бъде блокиран за дълго време по време на изпълнението.

В персонализираните софтуерни проекти използвайте кодово разпределение на базата на маршрути. Когато потребителят е на началната страница, кодовете на управленския панел, графичните библиотеки или разширените редактори не трябва да се изтеглят. Тежките компоненти трябва да бъдат извиквани чрез динамичен импорт в момента на нуждата. Идентифицирайте ненужните зависимости с помощта на инструменти за анализ на пакети. Вместо големи библиотеки за дата, графики или анимации, оценете по-леки алтернативи.

Проектите, които използват рендериране на сървърна страна или статично генериране, също трябва да бъдат внимателни. Въпреки че HTML пристига бързо, активирането на стотици компоненти едновременно по време на хидратация може да увеличи стойността на TBT. Избягването на ненужен JavaScript на клиентската страна в неинтерактивно съдържание е в централната част на подхода за производителност през 2026 г.

Връзка между хостинг, време за отговор на сървъра и производителност на JavaScript

TBT е директно свързано с времето за изпълнение на JavaScript в браузъра; обаче, инфраструктурата за хостинг косвено влияе на резултатите. Бавното TTFB, липсата на компресия, отсъствието на поддръжка за HTTP/2 или HTTP/3, слабото кеширане и закъсненията от отдалечени локации могат да доведат до по-късно достигане на JavaScript файловете. Когато файловете достигат късно, жизненият цикъл на страницата се удължава и потребителският опит се влошава.

Качествената инфраструктура за хостинг, Brotli или Gzip компресия, активна кеш памет на браузъра, актуална версия на PHP, бързи дискови технологии и интеграция на CDN подкрепят оптимизацията. Правилното инсталиране на SSL сертификата също е важно за съвременните браузърни функции, HTTP/2 и сигурни интеграции на трети страни. Hostragons SSL сертификати Hostragons проверка на домейн

Например, същият JavaScript файл може да бъде 320 KB без компресия, а с Brotli може да спадне до 95 KB. Това не намалява TBT стойността директно в същата пропорция; тъй като TBT измерва разходите за изпълнение. Въпреки това, времето за изтегляне се съкращава, приоритизацията на ресурсите се облекчава и общото изживяване при зареждане се подобрява. Следователно, defer, async, кеширане и правилен хостинг трябва да се разглеждат заедно.

Контролен списък за измерване и проверка

Само да погледнете оценките на PageSpeed не е достатъчно, за да разберете дали оптимизацията е успешна. Следният контролен списък ще ви помогне да оцените реалния ефект по-точно:

• Сравнени ли са стойностите на TBT за мобилни устройства преди и след оптимизацията?
• Намалени ли са най-скъпите файлове в отчета за време на изпълнение на JavaScript?
• Спаднал ли е броят на дългите задачи в записа на Chrome DevTools Performance?
• Има ли грешки в JavaScript в конзолата?
• Менюто, търсенето, филтрите, формите, количката и процесите на плащане работят ли без проблеми?
• Правилно ли се задействат таговете за анализ и реклама на трети страни?
• Подобряват ли се INP и забавянията при взаимодействие в реалните данни на потребителите?
• Промените ли бяха тествани отново след изчистване на кеша?

Важно е да се разграничат лабораторните и полевите данни. TBT е лабораторна метрика на Lighthouse. В реалния потребителски опит Interaction to Next Paint (INP) е станала по-определяща. Въпреки това, намаление на TBT често допринася за подобрение на INP, тъй като по-малко блокировки се случват в основния поток.

Често срещани грешки и как да ги избегнете

Да направите всички скриптове async наведнъж

Това е една от най-честите грешки. Тъй като async не дава гаранция за ред, той може да предизвика случайни грешки в зависими файлове. Структура, която изглежда безпроблемна на една страница, може да се провали при бавна връзка или в различен браузър. За зависимите файлове, defer е по-безопасният старт.

Неправилно отлагане на jQuery и зависими приставки

Особено на WordPress сайтове, много приставки зависят от реда на jQuery. Правенето на jQuery ядро async може да доведе до изпълнение на кода на приставките, преди jQuery да е зареден. Решението е да се види мрежата от зависимости и да се добавят критични файлове в списъка с изключения.

Да оставите трети странни скриптове без контрол

Собствениците на сайтове могат да забравят да оптимизират рекламни, чат и кодове за анализ, докато оптимизират собствените си файлове на темата. Въпреки това, в отчетите на Lighthouse, най-тежките задачи често идват от трети странни източници. Премахването на ненужни тагове, условното задействане и отлагането им при необходимост доставят значителни печалби.

Да инсталирате приставки без измерване

Приставките за производителност могат да бъдат полезни; обаче, всяко допълнително средство, използвано без измерване, може да добави нови JavaScript и CSS натоварвания. Първо диагностицирайте проблема, след това изберете инструмента. Уверете се, че приставката наистина намалява TBT с тестов отчет.

Да пренебрегнете конфликти между кеширане и минификация

Ако минификацията, обединението, defer и async се прилагат едновременно, редът на файловете може да се промени. Това може да доведе до неочаквани грешки в производствената среда. Особено ако CDN, кеширане на сървъра и кеширане на приложението се използват заедно, след всяка промяна изчистете всички слоеве.

Реалистичен сценарий за оптимизация

Представете си, че на средно голям корпоративен уебсайт на началната страница има 18 JavaScript заявки. От тях 5 са за тема и поведение на менюто, 4 за слайдери и анимации, 3 за формуляри и карти, а 6 за кодове за анализ, пиксели и чат на живо. Началната стойност на Lighthouse за мобилния TBT е 920 ms.

На първия етап, две ненужни анимационни приставки се премахват и компресираният JavaScript товар намалява с 140 KB. TBT спада до 760 ms. На втория етап, скриптовете на темата и слайдерите се прилагат с defer; редовете на зависимостите се тестват. TBT става 480 ms. На третия етап, скриптът за картата се зарежда само когато потребителят скролира до секцията за контакт, чат на живо се стартира 7 секунди по-късно, а кодовете за анализ и пиксели стават async. При последното измерване TBT спада до 210 ms.

Този сценарий показва важността на многопластовия подход, вместо да разчитате на една магическа настройка. Defer и async са мощни инструменти; обаче, най-добрите резултати се постигат с премахването на ненужен код, условно зареждане, правилно кеширане и качествена инфраструктура.

Заключение: Балансирана и тествана JavaScript стратегия за по-нисък TBT

Прилагането на отложено зареждане на JavaScript на вашия сайт е един от най-практичните и ефективни начини за намаляване на времето за TBT. Defer предлага безопасно решение за файлове, които трябва да работят последователно и след готовността на DOM; async е идеален за по-гъвкаво зареждане на независими трети страни скриптове. За успешна оптимизация трябва първо да измервате, да класифицирате скриптовете, да премахнете ненужните файлове, да тествате промените постепенно и да наблюдавате реалното потребителско изживяване.

Използването на бърза, сигурна и мащабируема инфраструктура на Hostragons ви помага да постигнете по-стабилна уеб производителност заедно с оптимизация на JavaScript, кеширане и конфигурации на SSL. Ако искате да подобрите TBT стойността на вашия сайт, първо изведете текущия си отчет и след това напредвайте с малки, но измерими стъпки. Можете да разгледате решенията на Hostragons за подходящ хостинг и производствена инфраструктура. Hostragons пакети за уеб хостинг

Често задавани въпроси

Могат ли defer и async да се използват заедно?

Ако в класически скрипт етикетите defer и async се използват заедно, в съвременните браузъри async може да действа приоритетно, което премахва гаранцията за ред. Следователно, в практиката не се препоръчва да се използват и двете в един и същ файл. За зависими файлове, defer, а за независими – async, е по-сигурен подход.

Намалява ли отложеното зареждане на JavaScript SEO класирането директно?

То не осигурява директна гаранция за класиране; обаче, подобрява потребителския опит, скоростта на взаимодействие и производителността на Core Web Vitals, което подкрепя успеха в SEO. По-бързо реагиращите страници могат да увеличат удовлетвореността на потребителите, конверсията и възприемането на качеството на индексацията.

Безопасно ли е да се добавя defer към всеки JavaScript файл?

Не. Някои скриптове може да трябва да работят в първоначалната фаза на страницата или да зависят от зареждането на определени файлове в определен ред. Следователно, за всеки файл трябва да се провери целта, зависимостите и времето на изпълнение; промените трябва да се тестват в тестова среда.

Достатъчни ли са само defer и async за намаляване на TBT?

Могат да осигурят значително подобрение за малки и средни сайтове; обаче, на сайтове, които използват тежки фреймуъркове, съдържат множество трети страни кодове или имат големи пакети, са необходими допълнителни мерки. Разпределение на кода, премахване на ненужен JavaScript, условно зареждане, кеширане и мощна хостинг инфраструктура трябва да бъдат разгледани заедно.

Кои скриптове не трябва да правя async на WordPress сайт?

Файловете на приставките, зависещи от jQuery, скриптовете за плащане и количка, проверките на формуляри, проверките на сигурност и критичните функции на темата не трябва да се правят случайно async. Ако редът се наруши, потребителските операции могат да бъдат нарушени. Първо, опитайте defer, и ако е необходимо, създайте списък с изключения.