Како да ја забрзате вашата веб-страница: практична листа

За да ја забрзате веб-страницата, прво измерете ја со PageSpeed Insights, па поправете ја најголемата причина што ја покажува — обично преголеми слики, премногу JavaScript, тешки фонтови или скрипти од трети страни. Стремете се кон „добрите“ цели на Core Web Vitals на Google: главната содржина видлива во рок од 2,5 секунди, одговори на допири во рок од 200 милисекунди и речиси никакво поместување на распоредот. Повеќето страници до тоа стигнуваат со неколку промени, а не со пренесување од почеток.

Измерете пред да промените што и да е

Погодувањето троши време. Две бесплатни алатки ги покриваат речиси сите:

• PageSpeed Insights (pagespeed.web.dev) — залепете жива URL адреса. Ги прикажува полеви податоци од вистински корисници на Chrome (ако страницата има доволно сообраќај) и лабораториски податоци од симулирано вчитување, плус список со конкретни проблеми.
• Lighthouse во Chrome DevTools — истиот лабораториски тест, пуштен на било која страница што можете да ја отворите, вклучително и преглед. Тестирајте во мобилен режим; проблемите се гледаат на телефони со побавни мрежи.

Бројките што се важни се Core Web Vitals на Google. Од септември 2026, документацијата на Google на web.dev ги дава овие „добри“ прагови, мерени на 75-от перцентил од вчитувањата на страниците:

INP ја замени постарата метрика First Input Delay во 2024. Ако некоја алатка сè уште го прикажува FID, е застарена.

Запишете ги почетните броеви. По секоја поправка, тестирајте повторно за да знаете што помогнало.

Каде оди времето: опции и компромиси

Секоја вообичаена причина има поправка, а секоја поправка има цена. Почнете со оние на врвот — тие се најевтини и најчести.

Слики

Сликите се најчест проблем и најлесно се поправаат. Фотографија од 4.000 пиксели прикажана со 800 пиксели широчина ја принудува секоја посета да преземе пет пати повеќе отколку што гледа.

• Служете слики во големината во која се прикажуваат, со responsive srcset големини за телефони и десктоп.
• Користете современи формати (WebP или AVIF) и разумна компресија.
• Поставете width и height на секоја слика за прелистувачот да резервира простор. Само со ова се поправа најголемиот дел од поместувањето на распоредот.
• Lazy-load за сликите под видливиот дел со loading="lazy".
• Никогаш не lazy-load главната слика на врвот на страницата. Насоките на Google за LCP се директни за ова: lazy-load на LCP сликата секогаш ја одложува. Наместо тоа, дајте ѝ fetchpriority="high".

JavaScript

Многу веб-страници направени со AI се single-page апликации (SPA): прелистувачот го преземе JavaScript пакетот и потоа ја црта страницата. Колку е пакетот поголем, толку е подолг празниот екран. Поправките, по редослед на напор:

1. Отстранете го она што не го користите. Побарајте листа на зависности и исечете ги библиотеките што се додадени еднаш и заборавени — библиотека за датуми за еден датум, целосен пакет икони за пет икони.
2. Поделете по рута. Вчитајте го кодот за админ таблата само кога некој ја отвора, а не на почетната страница.
3. Prerender на јавните страници. Маркетиншка страница што се испорачува како вистински HTML се појавува пред да се изврши било каков JavaScript. Ова помага и на пребарувачите; видете SEO за веб-сајтови направени со AI.

Бавниот INP обично значи една долга задача што го блокира страницата — филтрирање огромна листа при секој притисок на копче или повторно рендерирање на целата табела кога ќе се промени една ќелија. Панелот Performance во Chrome DevTools покажува која.

Фонтови

Секое семејство и тежина на фонтот е уште една датотека. Два семејства и три до четири тежини обично се доволни. Preload на фонтот што се користи над видливиот дел, font-display: swap за текстот да се прикаже веднаш, и self-host на фонтовите ако надворешната услуга за фонтови е бавна за вашите посетители.

Скрипти од трети страни

Widget-и за разговор, аналитика, heatmap-ови, пиксели за реклами, вградени видеа и социјални канали сите вчитуваат код од други сервери. Секој изгледа мал; заедно често се најбавниот дел од страницата. Задржете ги оние што навистина ги гледате. Останатите вчитајте ги откако страницата ќе стане интерактивна, а тешките вградувања (YouTube плеер, мапа) замете ги со лесен преглед што ја вчитува вистинската содржина при клик.

Одговор на серверот

Time to first byte (TTFB) — колку време му треба на серверот да почне да одговара — лежи под секоја друга метрика. Статичките страници послужени од CDN (мрежа од сервери блиску до вашите посетители; видете што е CDN) се брзи речиси насекаде. Страниците што ги прави сервер при секое барање зависат од тој сервер и неговата база на податоци. Кеширање на повторената работа и индекси во базата за бавните барања се вообичаените поправки.

Прашања што функционираат

Бидете конкретни: наведете ја страницата, метриката и ограничувањето. Залепете ги наодите од PageSpeed Insights ако ги имате.

PageSpeed Insights пријавува LCP од 4,8 s на телефон за почетната страница, а LCP елементот е hero сликата. Преоблечете ја и конвертирајте ја hero сликата во WebP, послужете responsive големини, поставете width и height, дајте ѝ fetchpriority="high" и осигурајте се дека не е lazy-load. Lazy-load за секоја слика под видливиот дел. Не менувај го дизајнот.

Ревидирај ги зависностите на оваа апликација. Наведи секој пакет, што го користи и приближно колку додава на пакетот. Отстрани ги неискористените и подели ги рутите /admin и /settings во посебни делови што се вчитуваат само кога ќе се посети.

Полето за пребарување на /products делува бавно. Дебаунсирај го филтерот, избегнувај повторно рендерирање на целата листа при секој притисок на копче и пагинирај или виртуелизирај ја листата ако има повеќе од 200 ставки.

Чекор по чекор

1. Тестирајте ја живата страница во PageSpeed Insights на телефон. Запишете ги LCP, INP и CLS и трите најголеми проблеми што се наведени.
2. Прво поправете ги сликите: големини, формати, димензии, lazy loading под видливиот дел, приоритет за hero сликата.
3. Исечете ги скриптите од трети страни што не ги користите и одложете ги останатите.
4. Намалете ги фонтовите на она што дизајнот го бара.
5. Намалете го JavaScript: отстранете ги неискористените пакети, делете по рута.
6. Prerender на јавните страници ако сè уште се рендерираат на клиентот и LCP е сè уште бавен.
7. Проверете го серверот: кеширање, индекси во базата, статички хостинг за содржина што ретко се менува.
8. Објавете повторно и тестирајте повторно. Полевите податоци во PageSpeed Insights се ажурираат во наредните недели како што доаѓаат вистински посети, па раните резултати судете според лабораториските податоци.

Чести грешки

• Тестирање само на брз лаптоп. Вашите посетители се на телефони од среден ранг и слаб мобилен интернет. Тестирајте во мобилен режим.
• Гонење на совршените 100. Лабораториската оценка е водич. Откако Core Web Vitals ќе бидат во добриот опсег, содржината и употребливоста се поважни од последните неколку поени.
• Lazy-load на сè, вклучително и hero сликата. Тоа ја влошува LCP.
• Додавање дополнителна алатка или библиотека за брзина. Отстранувањето на тежината речиси секогаш е подобро од додавање код за нејзино управување.
• Оптимизирање на прегледот, а не на живата страница. Развојните прегледи користат неоптимизирани build-ови. Мерете ја објавената URL адреса.
• Забрзување еднаш. Секој нов widget, слика и функција додава тежина. Тестирајте повторно после поголеми промени.

Контролна листа за брзина

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 на телефон
• Слики променети по големина, компресирани, современ формат, со width и height
• Hero сликата не е lazy-load; сликите под видливиот дел се lazy-load
• Нема неискористени JavaScript библиотеки; тешките рути се издвоени
• Најмногу два семејства фонтови, главниот фонт е preload
• Само скрипти од трети страни што навистина ги користите, вчитани подоцна
• Јавните страници се prerender-ирани или статички каде што е можно
• Повторно тестирано на живата URL адреса по објавувањето

Брзината и распоредот за мобилни се поврзани; видете како да направите веб-страница responsive за мобилни. За целосен преглед пред лансирање, како да го однесете AI прототипот во продукција ги покрива останатите работи.

Брзината на Mythex

На Mythex овие промени ги правите со прашање во разговорот, или во уредувачот на код на Pro. Проверете ја објавената URL адреса, а не прегледот, бидејќи прегледот работи на развоен сервер. Статичките frontend-и се распоредуваат како статички сајтови кога објавувате (статички веб-сајтови), што одговара на содржинските страници. Апликациите со сервер се скалираат до нула: спијат кога се неактивни и се будат при следната посета, па првото барање по мирен период е побавно, а поврзаната база спие по 5 минути неактивност (ограничувања на хостингот). Ако јавна страница е бавна само при првата посета, тоа е најверојатната причина. Чувањето маркетиншки страници статички помага. По промените, објавете повторно и направете hard-refresh.

Прашања