Гарын авлагууд

Вебсайтаа хурдан болгох нь: практик хяналтын жагсаалт

Вебсайтаа хурдан болгохын тулд эхлээд PageSpeed Insights-аар хэмж, дараа нь заасан хамгийн том шалтгааныг засаарай — ихэвчлэн хэт том зураг, хэт их JavaScript, хүнд фонт эсвэл гуравдагч талын скриптүүд. Google-ийн Core Web Vitals-ийн "сайн" зорилтод хүр: гол контент 2.5 секундэд харагдах, харилцаанд 200 миллисекундэд хариулах, layout бараг үсрэхгүй байх. Ихэнх сайт үүнд хэдхэн өөрчлөлтөөр хүрдэг, дахин бичих шаардлагагүй.

Юу ч өөрчлөхөөс өмнө хэмж

Таахлах нь цаг үрдэг. Хоёр үнэгүй хэрэгсэл бараг бүгдэд нь хангалттай:

  • PageSpeed Insights (pagespeed.web.dev) — амьд URL-аа буулгана. Энэ нь жинхэнэ Chrome хэрэглэгчдийн field data (сайт хангалттай траффиктэй бол) болон дуурайлган ачаалалтын lab data-г, мөн тодорхой асуудлын жагсаалтыг харуулна.
  • Lighthouse Chrome DevTools дотор — ижил лабораторийн туршилт, нээж болох ямар ч хуудсан дээр, урьдчилан харахыг оруулаад. Утасны горимд туршаарай; асуудал гарч ирдэг нь удаан сүлжээтэй утаснууд.

Чухал тоонууд нь Google-ийн Core Web Vitals. 2026 оны 9-р сарын байдлаар web.dev дээрх Google-ийн баримт бичиг эдгээр "сайн" босгыг өгдөг бөгөөд хуудас ачаалагдах 75 дахь перцентилээр хэмжигдэнэ:

ҮзүүлэлтЮуг хэмждэг вэСайн
Largest Contentful Paint (LCP)Гол контент (hero зураг, гарчиг) хэр хурдан харагдах вэ2.5 с буюу бага
Interaction to Next Paint (INP)Хуудас дарлага, хүрэлт, бичилтэд хэр хурдан хариулах вэ200 мс буюу бага
Cumulative Layout Shift (CLS)Ачаалах явцад layout хэр их үсрэх вэ0.1 буюу бага

INP нь 2024 онд хуучин First Input Delay үзүүлэлтийг сольсон. Хэрэв ямар нэг хэрэгсэл FID тайлагнаж байвал энэ нь хуучирсан.

Эхлэлийн тоонуудаа бичээрэй. Засвар бүрийн дараа дахин туршиж, юу тусалсныг мэд.

Цаг хаана алга болж байна: сонголт ба солилцоо

Түгээмэл шалтгаан бүр засвартай, засвар бүр зардалтай. Дээд жагсаалтаас эхэл — тэдгээр нь хамгийн хямд, хамгийн түгээмэл.

ШалтгаанЕрдийн засварСолилцоо
Том зурагХарагдах хэмжээнд багасгах, шахах, WebP эсвэл AVIF ашиглахХэт шахвал чанар бага зэрэг муудна
Зургууд буруу дарааллаар ачаалагдахДэлгэцийн доор байгаа зургийг lazy-load хийх; hero зургийг өндөр эрэмбэтэй болгохHero зураг lazy биш байвал ямар ч асуудалгүй
Хэт их JavaScriptХуудас бүрээр код хуваах, хэрэглэгдээгүй сангуудыг устгахЗарим refactor шаардана
Зөвхөн client дээр render хийхНийтэд нээлттэй хуудсуудыг prerender эсвэл server-render хийхИлүү build эсвэл серверийн тохиргоо
Веб фонтГэр бүл, жингийн тоог цөөлөх, гол фонтыг preload хийх, font-display: swapҮсгийн төрөл бага болно
Гуравдагч талын скриптХэрэглэгдээгүйг нь устгах, үлдсэнийг хуудсын дараа ачаалахВиджет эсвэл трекер алдагдана
Серверийн удаан хариуКэшлэх, CDN, агуулгын хуудсуудад static hostingКэш шинэчлэлтийг анхаарах хэрэгтэй

Зураг

Зураг бол хамгийн түгээмэл асуудал бөгөөд хамгийн амар засагддаг. 800 пиксель өргөнд харуулсан 4,000 пикселийн зураг нь зочин бүрийг харснаасаа таван дахин их файл татахад хүргэдэг.

  • Зургийг харагдах хэмжээгээр нь үйлчил, утас болон десктопд зориулсан хариу үйлдэлт srcset хэмжээтэйгээр.
  • Орчин үеийн формат (WebP эсвэл AVIF) болон боломжийн шахалт ашигла.
  • Зураг бүрт width болон height тавь, ингэснээр хөтөч зайг урьдчилан авна. Ганцаараа энэ нь ихэнх layout shift-ийг засдаг.
  • Дэлгэцийн доорх зургуудыг loading="lazy"-ээр lazy-load хий.
  • Хуудасны дээд хэсгийн гол зургийг хэзээ ч lazy-load бүү хий. Google-ийн LCP заавар энэ талаар шулуун хэлдэг: LCP зургийг lazy-load хийвэл үргэлж саатуулна. Үүний оронд fetchpriority="high" өг.

JavaScript

AI-ээр бүтээсэн олон сайт single-page app (SPA) байдаг: хөтөч JavaScript bundle татаж, дараа нь хуудсыг зурдаг. Bundle том байх тусам хоосон дэлгэц удаан үргэлжилнэ. Хүчин чармайлтын дарааллаар засварууд:

  1. Хэрэглэдэггүйг нь устга. Хамааралуудын жагсаалт гуй, нэг удаа нэмээд мартагдсан сангуудыг тайрч хая — нэг огнооны төлөө огнооны сан, таван дүрсний төлөө бүтэн дүрсний багц.
  2. Маршрут тус бүрээр хуваа. Админ dashboard-ын кодыг хэн нэгэн нээх үед л ачаал, нүүр хуудсан дээр бүү ачаал.
  3. Нийтэд нээлттэй хуудсуудыг prerender хий. Жинхэнэ HTML-ээр илгээгдсэн маркетингийн хуудас JavaScript ажиллахаас өмнө харагддаг. Энэ нь хайлтын системд ч тусалдаг; AI-р бүтээсэн вебсайтын SEO-г үзнэ үү.

Удаан INP ихэвчлэн нэг урт ажил хуудсыг блоклож буйг илэрхийлдэг — дарлагын бүрт асар том жагсаалтыг шүүх, эсвэл нэг нүд өөрчлөгдөхөд бүх хүснэгтийг дахин зурах. Chrome DevTools-ийн Performance панел аль нь болохыг харуулна.

Фонт

Фонт гэр бүл бүр болон жин бүр нь өөр файл. Хоёр гэр бүл, гурав дөрвөн жин ихэвнээ хангалттай. Дэлгэцийн дээд хэсэгт хэрэглэгдэх фонтыг preload хийж, текст даруй харагдахын тулд font-display: swap ашигла, мөн гадаад фонтын үйлчилгээ таны зочдод удаан байвал фонтоо өөрөө хост хий.

Гуравдагч талын скриптүүд

Чатын виджет, аналитик, heatmap, зарын pixel, embed видео, нийгмийн feed бүгд бусад серверээс код татдаг. Бүр нь жижиг харагддаг; нийлбэрээрээ ихэнхдээ хуудасны хамгийн удаан хэсэг болдог. Жинхэнэ ашигладаг нэгийг нь үлдээ. Бусдыг нь хуудас харилцах боломжтой болсны дараа ачаал, хүнд embed-үүдийг (YouTube тоглуулагч, газрын зураг) дарахад жинхэнийг нь ачаалдаг хөнгөн урьдчилан харалтаар солих.

Серверийн хариу

Time to first byte (TTFB) — сервер хариулж эхлэхэд хэр удаж буй нь бусад үзүүлэлт бүрийн доор байдаг. CDN-ээс (зочдод ойр серверүүдийн сүлжээ; CDN гэж юу вэ-г үзнэ үү) үйлчилдэг static хуудсууд бараг бүх газар хурдан. Хүсэлт бүрт сервер бүтээдэг хуудсууд тэр сервер болон өгөгдлийн санаас хамаарна. Давтагддаг ажлыг кэшлэх болон удаан асуулгад өгөгдлийн сангийн индекс нэмэх нь ихэвчлэн засвар.

Ажилладаг prompt-ууд

Тодорхой бай: хуудас, үзүүлэлт, хязгаарлалтыг нэрлэ. Хэрэв байгаа бол PageSpeed Insights-ийн дүгнэлтээ буул.

PageSpeed Insights нүүр хуудсын утас дээрх LCP-г 4.8 с гэж тайлагнаж байна, LCP элемент нь hero зураг. Hero зургийг WebP болгож багасгаж хөрвүүл, хариу үйлдэлт хэмжээ үйлчил, width болон height тавь, fetchpriority="high" өг мөн lazy-load хийгдэхгүйг шалга. Дэлгэцийн доорх бүх зургийг lazy-load хий. Дизайныг бүү өөрчил.

Энэ аппын хамааралуудыг аудит хий. Багц бүрийг, хэн ашигладаг болон bundle-д хэр их нэмдэгийг жагсаа. Хэрэглэгдээгүйг нь устгаж, /admin болон /settings маршрутуудыг зөвхөн зочлоход ачаалагдах тусдаа chunk болгон хуваа.

/products дээрх хайлтын хайрцаг удаан мэдрэгдэж байна. Шүүлтийг debounce хий, дарлага бүрт бүх жагсаалтыг дахин зурахаас зайлсхий, жагсаалт 200-аас олон зүйлтэй бол хуудаслалт эсвэл virtualise хий.

Алхам алхмаар

  1. Амьд хуудсаа туршаарай PageSpeed Insights дээр утасны горимд. LCP, INP, CLS болон жагсаасан гурван гол асуудлыг тэмдэглэ.
  2. Эхлээд зургаа засаарай: хэмжээ, формат, хэмжээсүүд, дэлгэцийн доорх lazy loading, hero-д давуу эрэмбэ.
  3. Ашиглаагүй гуравдагч талын скриптүүдийг тайрч, үлдсэнийг хойшлуул.
  4. Фонтоо багасга дизайнд хэрэгтэйд хүртэл.
  5. JavaScript-ийг багасга: ашиглаагүй багцуудыг устгаж, маршрут тус бүрээр хуваа.
  6. Нийтэд нээлттэй хуудсуудыг prerender хий хэрэв тэд одоо ч client дээр render хийгдэж, LCP удаан хэвээр байвал.
  7. Серверээ шалга: кэшлэлт, өгөгдлийн сангийн индекс, ховор өөрчлөгддөг агуулгад static hosting.
  8. Дахин нийтэлж, дахин туршаарай. PageSpeed Insights-ийн field data жинхэнэ зочид ирэх тусам хэдэн долоо хоногийн турш шинэчлэгдэнэ, тиймээс эхний үр дүнг lab өгөгдлөөр үнэл.

Түгээмэл алдаанууд

  • Зөвхөн хурдан зөөврийн компьютер дээр туршилт хийх. Таны зочид дунд зэргийн утас, тогтворгүй мобайл сүлжээтэй. Утасны горимд туршаарай.
  • Төгс 100-г хөөх. Лабораторийн оноо бол чиглүүлэг. Core Web Vitals сайн хэмжээнд орсны дараа контент, ашиглахад хялбар байдал сүүлийн хэдэн оноогоос илүү чухал.
  • Бүгдийг lazy-load хийх, hero зургийг оруулаад. Энэ нь LCP-г улам муудуулна.
  • Дээрээс нь хурдны плагин эсвэл сан нэмэх. Жинг хасах нь ихэвчлэн түүнийг удирдах код нэмснээс илүү ажилладаг.
  • Амьд сайтын оронд урьдчилан харалтыг оновчилох. Хөгжүүлэлтийн урьдчилан харалт оновчлоогүй build ажиллуулдаг. Нийтлэгдсэн URL-аа хэмжээрэй.
  • Хурдыг нэг удаа засах. Шинэ виджет, зураг, функц бүр жин нэмдэг. Том өөрчлөлтийн дараа дахин туршаарай.

Хурдны хяналтын жагсаалт

  • Утсан дээр LCP ≤ 2.5 с, INP ≤ 200 мс, CLS ≤ 0.1
  • Зургууд багассан, шахагдсан, орчин үеийн форматтай, width болон height-тэй
  • Hero зураг lazy-load биш; дэлгэцийн доорх зургууд lazy-load
  • Хэрэглэгдээгүй JavaScript сангууд байхгүй; хүнд маршрутууд тусгаарлагдсан
  • Хоёр эсвэл түүнээс цөөн фонтын гэр бүл, гол фонт preload
  • Ашигладаг гуравдагч талын скриптүүд л, хожуу ачаалагдсан
  • Нийтэд нээлттэй хуудсууд боломжтой үед prerender эсвэл static
  • Нийтэлсний дараа амьд URL дээр дахин туршсан

Хурд болон утасны layout хамт явдаг; вебсайтыг утсанд тохируулах нь-ийг үзнэ үү. Нийтлэхээсээ өмнөх бүрэн шалгалтад AI прототипийг продакшн руу хэрхэн авах вэ нь үлдсэнийг тайлбарлана.

Mythex дээрх хурд

Mythex дээр эдгээр өөрчлөлтийг чатаар асуух, эсвэл Pro дээрх код editor-оор хийдэг. Урьдчилан харалт нь хөгжүүлэлтийн сервер ажиллуулдаг тул Preview-г биш нийтлэгдсэн URL-аа шалга. Static фронт-энд нийтлэхдээ static сайт болгон байрлуулдаг (static вебсайтууд), энэ нь агуулгын хуудсуудад тохирно. Сервертэй апп нь ашиглагдаагүй үедээ унтдаг (scale to zero): чимээгүй хугацааны дараах эхний хүсэлт удаан байна, мөн холбосон өгөгдлийн сан 5 минут ашиглагдаагүй бол унтдаг (хостингийн хязгаар). Нийтэд нээлттэй хуудас зөвхөн анхны зочлоход удаан бол энэ шалтгаан байж магадгүй. Маркетингийн хуудсуудыг static байлгах нь тусалдаг. Өөрчлөлтийн дараа дахин нийтэлж, хуудсыг хүчээр шинэчил.

Асуултууд

Хуудас ачаалах сайн хугацаа хэд вэ?

Google-ийн Core Web Vitals хамгийн тодорхой зорилтыг өгдөг: гол контент 2.5 секундэд харагдах (LCP), хуудас оролтод 200 миллисекундэд хариулах (INP), мөн layout-ийн шилжилт 0.1 эсвэл түүнээс доош байх (CLS). Эдгээрийг жинхэнэ зочдын 75 дахь перцентилээр хэмжинэ.

Вебсайтын хурд SEO-д нөлөөлдөг үү?

Тийм, бага зэрэг. Google Core Web Vitals-г оруулсан хуудасны туршлагын дохиог ашигладаг ч холбогдох контент илүү чухал. Хурд нь зочдод илүү их нөлөөтэй: тэд уншихаасаа өмнө удаан хуудсыг орхидог.

Яагаад миний PageSpeed Insights оноо нэг бүр өөр гардаг вэ?

Лабораторийн оноо нэг дуурайлган ачаалалтаас гардаг тул сүлжээ, серверийн хугацаа удаа бүр ялгаатай байна. Хэд хэдэн удаа ажиллуулж, чиг хандлагыг хар, мөн жинхэнэ Chrome хэрэглэгчдийн өгөгдлөөс гарсан field data хэсэгт илүү жин өг.

Ихэнх вебсайтыг юу удаашруулдаг вэ?

Ихэвчлэн хэт том зураг, хэт их JavaScript, веб фонт, чатын виджет, зарын pixel, embed зэрэг гуравдагч талын скриптүүд. Серверийн удаан хариу эсвэл хүйтнээр эхэлдэг backend эдгээрт нэмэгддэг.

Mythex · Pricing · AI-аар юуг ч бүтээ · Вэбсайт болон аппын загварууд · Mythex-ийн харьцуулалт · AI-аар апп бүтээх тайлбар толь · AI-аар апп бүтээх үнэгүй хэрэгслүүд · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)