Kā padarīt mājaslapu ātrāku: praktisks kontrolsaraksts

Lai padarītu mājaslapu ātrāku, vispirms izmēriet to ar PageSpeed Insights, pēc tam labojiet lielāko cēloni, ko tas norāda — parasti pārāk lielus attēlus, pārāk daudz JavaScript, smagus fontus vai trešo pušu skriptus. Tiecieties uz Google Core Web Vitals „labiem” mērķiem: galvenais saturs redzams 2,5 sekunžu laikā, atbildes uz pieskārieniem tiek sniegtas 200 milisekunžu laikā un lapa gandrīz nelec. Vairums vietņu sasniedz to ar nelielu izmaiņu kopumu, nevis pārrakstīšanu.

Izmēriet pirms jebko mainīt

Minēšana izšķiež laiku. Divi bezmaksas rīki apkalpo gandrīz visus:

• PageSpeed Insights (pagespeed.web.dev) — ielīmējiet tiešraides URL. Tas rāda lauka datus no reāliem Chrome lietotājiem (ja vietnei ir pietiekami apmeklējumu) un laboratorijas datus no simulētas ielādes, kā arī konkrētu problēmu sarakstu.
• Lighthouse Chrome DevTools — tas pats laboratorijas tests jebkurai lapai, ko varat atvērt, arī priekšskatījumam. Testējiet mobilajā režīmā; problēmas parādās tālruņos lēnākos tīklos.

Svarīgie skaitļi ir Google Core Web Vitals. 2026. gada septembrī Google dokumentācijā web.dev šie ir „labi” sliekšņi, mērot 75. procentili lapu ielādēs:

INP 2024. gadā aizstāja vecāko First Input Delay rādītāju. Ja rīks joprojām rāda FID, tas ir novecojis.

Ierakstiet sākuma rādītājus. Pēc katra labojuma testējiet vēlreiz, lai zinātu, kas palīdzēja.

Kur laiks pazūd: iespējas un kompromisi

Katram biežākajam cēlonim ir labojums, un katram labojumam ir cena. Sāciet ar augšā esošajiem — tie ir lētākie un visbiežākie.

Attēli

Attēli ir visbiežākā problēma un vieglāk labojamā. 4000 pikseļu fotogrāfija, kas rādīta 800 pikseļu platumā, liek katram apmeklētājam lejupielādēt piecas reizes vairāk, nekā redz.

• Piegādājiet attēlus tajā izmērā, kādā tie tiek rādīti, ar responsīviem srcset izmēriem tālruņiem un datoriem.
• Izmantojiet modernus formātus (WebP vai AVIF) un saprātīgu saspiešanu.
• Iestatiet width un height katram attēlam, lai pārlūks rezervētu vietu. Tas vien labo lielāko daļu izkārtojuma nobīdes.
• Lazy-load attēlus zem lapas ekrāna ar loading="lazy".
• Nekad nelieciet lazy-load galveno attēlu lapas augšdaļā. Google LCP norādījumi par to ir skaidri: LCP attēla lazy-load vienmēr to aizkavē. Tā vietā dodiet fetchpriority="high".

JavaScript

Daudzas AI veidotas vietnes ir vienas lapas lietotnes (SPA): pārlūks lejupielādē JavaScript kopumu un tad zīmē lapu. Jo lielāks kopums, jo ilgāks tukšs ekrāns. Labojumi pēc pūles:

1. Noņemiet to, ko neizmantojat. Lūdziet atkarību sarakstu un izmetiet bibliotēkas, kas kādreiz pievienotas un aizmirstas — datumu bibliotēku vienam datumam, pilnu ikonu pakotni piecām ikonām.
2. Sadaliet pēc maršrutiem. Ielādējiet administratora paneļa kodu tikai tad, kad kāds to atver, nevis sākumlapā.
3. Iepriekš renderējiet publiskās lapas. Mārketinga lapa, kas tiek piegādāta kā īsts HTML, parādās, pirms jebkurš JavaScript darbojas. Tas palīdz arī meklētājprogrammām; skatiet SEO AI veidotām mājaslapām.

Lēns INP parasti nozīmē vienu garu uzdevumu, kas bloķē lapu — piemēram, milzīga saraksta filtrēšanu katrā taustiņsitienā vai visas tabulas pārzīmēšanu, kad mainās viena šūna. Chrome DevTools Performance panelis parāda, kas tieši.

Fonti

Katra fontu ģimene un svars ir vēl viens fails. Parasti pietiek divas ģimenes un trīs vai četri svari. Ielādējiet iepriekš fontu, kas izmantots virs lapas ekrāna, lietojiet font-display: swap, lai teksts parādītos uzreiz, un hostējiet fontus pats, ja ārējais fontu pakalpojums ir lēns jūsu apmeklētājiem.

Trešo pušu skripti

Tērzēšanas logrīki, analītika, siltumkartes, reklāmu pikseļi, iegultie video un sociālo tīklu plūsmas ielādē kodu no citiem serveriem. Katrs izskatās mazs; kopā tie bieži ir lēnākā lapas daļa. Paturiet tikai tos, ko patiešām skatāties. Pārējos ielādējiet, kad lapa ir interaktīva, un smagus iegulumus (YouTube atskaņotāju, karti) aizstājiet ar vieglu priekšskatījumu, kas ielādē īsto saturu pēc klikšķa.

Servera atbilde

Laiks līdz pirmajam baitam (TTFB) — cik ilgi serverim vajag, lai sāktu atbildēt — atrodas zem visiem pārējiem rādītājiem. Statiskās lapas, ko piegādā no CDN (serveru tīkla, kas atrodas tuvu jūsu apmeklētājiem; skatiet kas ir CDN), ir ātras gandrīz visur. Lapas, ko serveris veido katrā pieprasījumā, ir atkarīgas no šī servera un tā datubāzes. Kešatmiņa, kas atkārtotu darbu saglabā, un datubāzes indeksi lēniem vaicājumiem ir parastie labojumi.

Uzvednes, kas darbojas

Būt konkrētam: nosauciet lapu, rādītāju un ierobežojumu. Ielīmējiet PageSpeed Insights atradumus, ja tādi ir.

PageSpeed Insights ziņo par LCP 4,8 s mobilajā ierīcē sākumlapai, un LCP elements ir galvenais attēls. Mainiet galvenā attēla izmēru un pārveidojiet to WebP formātā, piegādājiet responsīvos izmērus, iestatiet width un height, dodiet tam fetchpriority="high" un pārliecinieties, ka tas nav lazy-load. Lazy-load katru attēlu zem lapas ekrāna. Nemainiet dizainu.

Pārbaudiet šīs lietotnes atkarības. Uzskaitiet katru pakotni, to, kas to izmanto, un aptuveni, cik tā pievieno kopumam. Noņemiet neizmantotās un sadaliet maršrutus /admin un /settings atsevišķos fragmentos, kas ielādējas tikai tad, kad tos apmeklē.

Meklēšanas lauks lapā /products jūtas lēns. Aizkavējiet filtra palaišanu, izvairieties no visa saraksta pārzīmēšanas katrā taustiņsitienā un, ja sarakstā ir vairāk nekā 200 vienumu, sadaliet to lapās vai virtualizējiet.

Solis pa solim

1. Testējiet tiešraides lapu PageSpeed Insights mobilajā režīmā. Ierakstiet LCP, INP un CLS un trīs galvenās norādītās problēmas.
2. Vispirms labojiet attēlus: izmērus, formātus, dimensijas, lazy-load zem lapas ekrāna, galvenā attēla prioritāti.
3. Samaziniet trešo pušu skriptus, ko neizmantojat, un pārējos atliekiet.
4. Apgrieziet fontus līdz tam, kas nepieciešams dizainam.
5. Samaziniet JavaScript: noņemiet neizmantotās pakotnes, sadaliet pēc maršrutiem.
6. Iepriekš renderējiet publiskās lapas, ja tās joprojām renderē klientā un LCP joprojām ir lēns.
7. Pārbaudiet serveri: kešatmiņu, datubāzes indeksus, statisko hostēšanu saturam, kas reti mainās.
8. Publicējiet vēlreiz un pārtestējiet. PageSpeed Insights lauka dati atjauninās nākamajās nedēļās, kad ieradīsies reāli apmeklējumi, tāpēc agrīnos rezultātus vērtējiet pēc laboratorijas datiem.

Biežākās kļūdas

• Testēšana tikai uz ātra klēpjdatora. Jūsu apmeklētāji ir vidējas klases tālruņos un nestabilā mobilajā datu saitē. Testējiet mobilajā režīmā.
• Vajadzība pēc perfekta 100. Laboratorijas rādītājs ir vadlīnija. Kad Core Web Vitals ir labā diapazonā, saturs un lietojamība ir svarīgāki par pēdējiem punktiem.
• Lazy-load viss, arī galveno attēlu. Tas pasliktina LCP.
• Ātruma spraudņa vai bibliotēkas pievienošana virsū. Svara noņemšana gandrīz vienmēr ir labāka par papildu kodu, lai to pārvaldītu.
• Priekšskatījuma optimizēšana, nevis tiešraides vietnes. Izstrādes priekšskatījumi darbojas ar neoptimizētiem būvējumiem. Mēriet publicēto URL.
• Ātruma labošana vienu reizi. Katrs jauns logrīks, attēls un funkcija pievieno svaru. Pēc lielām izmaiņām testējiet vēlreiz.

Ātruma kontrolsaraksts

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 mobilajā ierīcē
• Attēli izmērīti, saspiesti, modernā formātā, ar width un height
• Galvenais attēls nav lazy-load; attēli zem lapas ekrāna ir lazy-load
• Nav neizmantotu JavaScript bibliotēku; smagie maršruti nodalīti
• Divas fontu ģimenes vai mazāk, galvenais fonts iepriekš ielādēts
• Tikai tie trešo pušu skripti, ko patiešām izmantojat, ielādēti vēlāk
• Publiskās lapas iepriekš renderētas vai statiskas, kad iespējams
• Pārtestēts tiešraides URL pēc publicēšanas

Ātrums un mobilais izkārtojums iet kopā; skatiet kā padarīt mājaslapu responsīvu mobilajām ierīcēm. Pilnai pirmspalaišanas pārbaudei kā AI prototipu pārvērst produkcijā aptver pārējo.

Ātrums Mythex

Mythex šīs izmaiņas veicat, lūdzot tērzēšanā vai koda redaktorā Pro plānā. Pārbaudiet publicēto URL, nevis priekšskatījumu, jo priekšskatījums darbojas ar izstrādes serveri. Statiskās priekšpuses publicēšanas brīdī tiek izvietotas kā statiskas vietnes (statiskās vietnes), kas der satura lapām. Lietotnes ar serveri samazinās līdz nullei: kad tās nav aktīvas, tās guļ un pamostas nākamajā apmeklējumā, tāpēc pirmais pieprasījums pēc klusa perioda ir lēnāks, un pievienotā datubāze iemiegas pēc 5 minūtēm bez aktivitātes (hostinga ierobežojumi). Ja publiska lapa ir lēna tikai pirmajā apmeklējumā, tas ir iespējamais cēlonis. Mārketinga lapu turēšana statiskas palīdz. Pēc izmaiņām publicējiet vēlreiz un veiciet cieto pārlādi.

Jautājumi