როგორ გავხადოთ ვებსაიტი უფრო სწრაფი: პრაქტიკული შემოწმების სია
ვებსაიტის უფრო სწრაფად გასაკეთებლად ჯერ გაზომეთ PageSpeed Insights-ით, შემდეგ გაასწორეთ მთავარი მიზეზი, რომელსაც ის გიჩვენებთ — ჩვეულებრივ, გადიდებული სურათები, ზედმეტი JavaScript, მძიმე შრიფტები ან მესამე მხარის სკრიპტები. მიზნად დაისახეთ Google-ის Core Web Vitals-ის „კარგი“ სამიზნეები: მთავარი შინაარსი ჩანდეს 2.5 წამში, შეხებებზე პასუხი მოდიოდეს 200 მილიწამში და თითქმის არ იყოს განლაგების ხტომა. უმეტესი საიტი ამას რამდენიმე ცვლილებით აღწევს და არა გადაწერით.
გაზომეთ, სანამ რამეს შეცვლით
გამოცანებით დრო იკარგება. ორი უფასო ინსტრუმენტი თითქმის ყველას ფარავს:
- PageSpeed Insights (pagespeed.web.dev) — ჩასვით ცოცხალი URL. აჩვენებს საველე მონაცემებს რეალური Chrome მომხმარებლებიდან (თუ საიტს საკმარისი ტრაფიკი აქვს) და ლაბორატორიულ მონაცემებს სიმულირებული ჩატვირთვიდან, ასევე კონკრეტული პრობლემების სიას.
- Lighthouse Chrome DevTools-ში — იგივე ლაბორატორიული ტესტი ნებისმიერ გვერდზე, რომელსაც გახსნით, მათ შორის პრევიუზე. ტესტირება მობილურ რეჟიმში გააკეთეთ; პრობლემები მაშინ ჩანს, როცა ტელეფონები ნელ ქსელებზე არიან.
რიცხვები, რომლებიც მნიშვნელოვანია, არის Google-ის Core Web Vitals. 2026 წლის სექტემბრის მდგომარეობით, Google-ის დოკუმენტაცია web.dev-ზე ამ „კარგ“ ზღვრებს იძლევა, გაზომილს გვერდის ჩატვირთვების 75-ე პროცენტილზე:
| მეტრიკა | რას ზომავს | კარგი |
|---|---|---|
| Largest Contentful Paint (LCP) | რამდენად მალე ჩნდება მთავარი შინაარსი (მთავარი სურათი, სათაური) | 2.5 წმ ან ნაკლები |
| Interaction to Next Paint (INP) | რამდენად სწრაფად რეაგირებს გვერდი დაწკაპუნებაზე, შეხებაზე და წერაზე | 200 ms ან ნაკლები |
| Cumulative Layout Shift (CLS) | რამდენად ხტება განლაგება ჩატვირთვისას | 0.1 ან ნაკლები |
INP 2024 წელს ჩაანაცვლა ძველმა First Input Delay მეტრიკამ. თუ ინსტრუმენტი ჯერ კიდევ FID-ს აჩვენებს, ის მოძველებულია.
ჩაიწერეთ საწყისი რიცხვები. ყოველი გასწორების შემდეგ ხელახლა გაზომეთ, რომ იცოდეთ, რა დაეხმარა.
სად იკარგება დრო: ვარიანტები და კომპრომისები
ყოველ გავრცელებულ მიზეზს აქვს გასწორება, და ყოველ გასწორებას აქვს ფასი. დაიწყეთ ზემოდან — ისინი ყველაზე იაფი და ყველაზე გავრცელებულია.
| მიზეზი | ტიპური გასწორება | კომპრომისი |
|---|---|---|
| დიდი სურათები | ზომის შემცირება ნაჩვენებ ზომამდე, შეკუმშვა, WebP ან AVIF | მცირე ხარისხის დაკარგვა, თუ ზედმეტად შეკუმშავთ |
| სურათები არასწორი რიგით იტვირთება | ქვემოთ მდებარე სურათების lazy-load; მთავარ სურათს მაღალი პრიორიტეტი | არცერთი, თუ მთავარი სურათი არ არის lazy-load-ზე |
| ზედმეტი JavaScript | კოდის დაყოფა გვერდების მიხედვით, გამოუყენებელი ბიბლიოთეკების წაშლა | რაღაც რეფაქტორინგი |
| მხოლოდ კლიენტზე რენდერი | საჯარო გვერდების წინასწარი რენდერი ან სერვერზე რენდერი | მეტი build-ის ან სერვერის დაყენება |
| ვებ-შრიფტები | ნაკლები ოჯახი და წონა, მთავარის წინასწარი ჩატვირთვა, font-display: swap | ნაკლები ტიპოგრაფიული მრავალფეროვნება |
| მესამე მხარის სკრიპტები | გამოუყენებელის წაშლა, დანარჩენის გვერდის შემდეგ ჩატვირთვა | ვიჯეტის ან თვალყურის დევნების დაკარგვა |
| ნელი სერვერის პასუხი | ქეშირება, CDN, სტატიკური ჰოსტინგი შინაარსის გვერდებისთვის | ქეშის გაუქმება უნდა იფიქროთ |
სურათები
სურათები ყველაზე გავრცელებული პრობლემაა და ყველაზე იოლად გამოსასწორებელი. 4,000 პიქსელიანი ფოტო, რომელიც 800 პიქსელ სიგანეზე ჩანს, ყოველ ვიზიტორს აიძულებს, ხუთჯერ მეტი ჩამოტვირთოს, ვიდრე ხედავს.
- მიაწოდეთ სურათები იმ ზომით, რომლითაც ნაჩვენებია,
srcset-ით ტელეფონებისა და დესკტოპებისთვის. - გამოიყენეთ თანამედროვე ფორმატები (WebP ან AVIF) და გონივრული შეკუმშვა.
- დააყენეთ
widthდაheightყველა სურათზე, რომ ბრაუზერმა ადგილი დაიჭიროს. მხოლოდ ეს ასწორებს განლაგების ხტომის უმეტესობას. - ჩამოტვირთეთ lazy-load-ით (
loading="lazy") სურათები, რომლებიც ეკრანის ქვემოთაა. - არასდროს გახადოთ lazy-load გვერდის ზედა მთავარი სურათი. Google-ის LCP-ის მითითება ამაზე პირდაპირია: LCP სურათის lazy-load ყოველთვის აყოვნებს მას. მის ნაცვლად მიანიჭეთ
fetchpriority="high".
JavaScript
ბევრი AI-ით აგებული საიტი ერთგვერდიანი აპლიკაციაა (SPA): ბრაუზერი ჩამოტვირთავს JavaScript ბანდლს და შემდეგ ხატავს გვერდს. რაც უფრო დიდია ბანდლი, მით მეტხანს გრძელდება ცარიელი ეკრანი. გასწორებები, მოდებულ ძალისხმევის მიხედვით:
- წაშალეთ ის, რასაც არ იყენებთ. სთხოვეთ დამოკიდებულებების სია და ამოიღეთ ბიბლიოთეკები, რომლებიც ერთხელ დაემატა და დავიწყებულია — თარიღების ბიბლიოთეკა ერთი თარიღისთვის, სრული ხატულების პაკეტი ხუთი ხატულისთვის.
- გაყავით გვერდების მიხედვით. ადმინისტრაციული პანელის კოდი ჩატვირთეთ მხოლოდ მაშინ, როცა ვინმე მას გახსნის, და არა მთავარ გვერდზე.
- წინასწარ დარენდერეთ საჯარო გვერდები. მარკეტინგული გვერდი, რომელიც რეალურ HTML-ად მიდის, JavaScript-ის გაშვებამდე ჩანს. ეს საძიებო სისტემებსაც ეხმარება; იხილეთ SEO AI-ით აგებული ვებსაიტებისთვის.
ნელი INP ჩვეულებრივ ნიშნავს, რომ ერთი გრძელი ამოცანა აბლოკავს გვერდს — მაგალითად, დიდი სიის ფილტრაცია ყოველ დაჭერაზე, ან მთელი ცხრილის ხელახალი რენდერი, როცა ერთი უჯრედი იცვლება. Chrome DevTools-ის Performance პანელი აჩვენებს, რომელი.
შრიფტები
შრიფტის ყოველი ოჯახი და წონა კიდევ ერთი ფაილია. ორი ოჯახი და სამი-ოთხი წონა ჩვეულებრივ საკმარისია. წინასწარ ჩატვირთეთ ზედა ნაწილში გამოყენებული შრიფტი, გამოიყენეთ font-display: swap, რომ ტექსტი მაშინვე გამოჩნდეს, და ჰოსტეთ შრიფტები საკუთარ სერვერზე, თუ გარე შრიფტების სერვისი თქვენი ვიზიტორებისთვის ნელია.
მესამე მხარის სკრიპტები
ჩატის ვიჯეტები, ანალიტიკა, heatmap-ები, რეკლამის პიქსელები, ჩაშენებული ვიდეოები და სოციალური ფიდები სხვა სერვერებიდან ჩატვირთავს კოდს. თითოეული პატარად გამოიყურება; ერთად ისინი ხშირად გვერდის ყველაზე ნელი ნაწილია. დატოვეთ ის, რასაც ნამდვილად იყენებთ. დანარჩენი ჩატვირთეთ გვერდის ინტერაქტიულად გახდომის შემდეგ, ხოლო მძიმე ჩანართები (YouTube-ის დამკვრელი, რუკა) შეცვალეთ მსუბუქი წინასწარი ხედით, რომელიც რეალურ კონტენტს დაწკაპუნებაზე ტვირთავს.
სერვერის პასუხი
Time to first byte (TTFB) — რამდენ ხანს იწყებს სერვერი პასუხს — ყველა სხვა მეტრიკის საფუძველია. CDN-იდან (სერვერების ქსელი თქვენს ვიზიტორებთან ახლოს; იხილეთ რა არის CDN) მიწოდებული სტატიკური გვერდები თითქმის ყველგან სწრაფია. ყოველ მოთხოვნაზე სერვერის მიერ აგებული გვერდები დამოკიდებულია ამ სერვერსა და მის მონაცემთა ბაზაზე. ქეშირება განმეორებადი სამუშაოსთვის და ნელი შეკითხვებისთვის მონაცემთა ბაზის ინდექსები ჩვეულებრივი გასწორებებია.
მუშა მოთხოვნები
იყავით კონკრეტული: დაასახელეთ გვერდი, მეტრიკა და შეზღუდვა. თუ PageSpeed Insights-ის შედეგები გაქვთ, ჩასვით ისინი.
PageSpeed Insights მთავარ გვერდზე მობილურზე LCP-ს 4.8 წმ-ს აჩვენებს, და LCP ელემენტი მთავარი სურათია. შეცვალე და გადააკონვერტირე მთავარი სურათი WebP-ად, მიაწოდე რესპონსიული ზომები, დააყენე width და height, მიანიჭე fetchpriority="high" და დარწმუნდი, რომ lazy-load არ აქვს. ყველა ქვემოთ მდებარე სურათს lazy-load მიანიჭე. დიზაინი არ შეცვალო.
გააუდიტე ამ აპლიკაციის დამოკიდებულებები. ჩამოწერე თითოეული პაკეტი, რა იყენებს მას და დაახლოებით რამდენს უმატებს ბანდლს. წაშალე გამოუყენებლები და გაყავი /admin და /settings მარშრუტები ცალკე ნაწილებად, რომლებიც მხოლოდ მაშინ ჩაიტვირთება, როცა მათ ეწვევიან.
საძიებო ველი /products გვერდზე ნელა რეაგირებს. დაუყენე ფილტრს დებაუნსი, თავიდან აიცილე მთელი სიის ხელახალი რენდერი ყოველ დაჭერაზე და, თუ სიაში 200-ზე მეტი ელემენტია, გააკეთე პაგინაცია ან ვირტუალიზაცია.
ნაბიჯ-ნაბიჯ
- გაზომეთ ცოცხალი გვერდი PageSpeed Insights-ში მობილურზე. ჩაიწერეთ LCP, INP და CLS და მთავარი სამი ჩამოთვლილი პრობლემა.
- ჯერ სურათები გაასწორეთ: ზომები, ფორმატები, განზომილებები, ქვემოთ მდებარეების lazy-load, მთავარზე პრიორიტეტი.
- გააჩერეთ მესამე მხარის სკრიპტები, რომლებსაც არ იყენებთ, და დანარჩენი გადადეთ.
- შეამცირეთ შრიფტები იმით, რაც დიზაინს სჭირდება.
- შეამცირეთ JavaScript: წაშალეთ გამოუყენებელი პაკეტები, გაყავით გვერდების მიხედვით.
- წინასწარ დარენდერეთ საჯარო გვერდები, თუ ისინი ჯერ კიდევ კლიენტზე რენდერდება და LCP ისევ ნელია.
- შეამოწმეთ სერვერი: ქეშირება, მონაცემთა ბაზის ინდექსები, სტატიკური ჰოსტინგი იმ შინაარსისთვის, რომელიც იშვიათად იცვლება.
- თავიდან გამოაქვეყნეთ და თავიდან შეამოწმეთ. PageSpeed Insights-ის საველე მონაცემები შემდეგი კვირების განმავლობაში განახლდება, როცა რეალური ვიზიტები მოვა, ამიტომ ადრეულ შედეგებს ლაბორატორიული მონაცემებით შეაფასეთ.
გავრცელებული შეცდომები
- მხოლოდ სწრაფ ლეპტოპზე ტესტირება. თქვენი ვიზიტორები საშუალო ტელეფონებით და არასტაბილური მობილური ინტერნეტით არიან. ტესტირება მობილურ რეჟიმში გააკეთეთ.
- სრულყოფილი 100-ის დევნა. ლაბორატორიული ქულა მხოლოდ მითითებაა. როცა Core Web Vitals კარგ დიაპაზონშია, შინაარსი და სიადვილე ბოლო რამდენიმე ქულაზე მნიშვნელოვანია.
- ყველაფრის lazy-load, მათ შორის მთავარი სურათისა. ეს LCP-ს აუარესებს.
- სიჩქარის მოდულის ან ბიბლიოთეკის დამატება ზემოდან. წონის მოშორება თითქმის ყოველთვის სჯობს კოდის დამატებას მის სამართავად.
- პრევიუს ოპტიმიზაცია, და არა ცოცხალი საიტის. განვითარების პრევიუები ოპტიმიზაციის გარეშე build-ებს უშვებენ. გაზომეთ გამოქვეყნებული URL.
- სიჩქარის ერთხელ გასწორება. ყოველი ახალი ვიჯეტი, სურათი და ფუნქცია წონას უმატებს. დიდი ცვლილებების შემდეგ თავიდან შეამოწმეთ.
სიჩქარის შემოწმების სია
- LCP ≤ 2.5 წმ, INP ≤ 200 ms, CLS ≤ 0.1 მობილურზე
- სურათები შემცირებული, შეკუმშული, თანამედროვე ფორმატით, width და height-ით
- მთავარი სურათი არ არის lazy-load-ზე; ქვემოთ მდებარე სურათები — lazy-load-ზე
- არ არის გამოუყენებელი JavaScript ბიბლიოთეკები; მძიმე მარშრუტები გამოყოფილია
- ორი შრიფტის ოჯახი ან ნაკლები, მთავარი შრიფტი წინასწარ ჩატვირთული
- მხოლოდ იმ მესამე მხარის სკრიპტები, რომლებსაც ნამდვილად იყენებთ, გვიან ჩატვირთული
- საჯარო გვერდები წინასწარ დარენდერებული ან სტატიკური, სადაც შესაძლებელია
- თავიდან შემოწმებული ცოცხალ URL-ზე გამოქვეყნების შემდეგ
სიჩქარე და მობილური განლაგება ერთად მიდის; იხილეთ როგორ გავხადოთ ვებსაიტი მობილურისთვის ადაპტირებადი. გაშვებამდელი სრული გავლისთვის როგორ მივიყვანოთ AI პროტოტიპი პროდაქშენამდე დანარჩენს ფარავს.
სიჩქარე Mythex-ზე
Mythex-ზე ამ ცვლილებებს ჩატში თხოვნით ან Pro-ზე კოდის რედაქტორში აკეთებთ. შეამოწმეთ გამოქვეყნებული URL და არა პრევიუ, რადგან პრევიუ განვითარების სერვერზე მუშაობს. სტატიკური ფრონტენდები გამოქვეყნებისას სტატიკურ საიტებად ინთავსება (სტატიკური ვებსაიტები), რაც შინაარსის გვერდებს ერგება. სერვერიანი აპლიკაციები ნულამდე მასშტაბირდება: უმოქმედოდ იძინებენ და შემდეგ ვიზიტზე იღვიძებენ, ამიტომ მოუსვენარი პერიოდის შემდეგ პირველი მოთხოვნა უფრო ნელია, ხოლო მიერთებული მონაცემთა ბაზა 5 წუთის უმოქმედობის შემდეგ იძინებს (ჰოსტინგის ლიმიტები). თუ საჯარო გვერდი მხოლოდ პირველ ვიზიტზეა ნელი, სავარაუდო მიზეზი ეს არის. მარკეტინგული გვერდების სტატიკურად შენახვა ეხმარება. ცვლილებების შემდეგ ხელახლა გამოაქვეყნეთ და დააჭირეთ hard-refresh-ს.
კითხვები
რა არის გვერდის კარგი ჩატვირთვის დრო?
Google-ის Core Web Vitals ყველაზე ნათელ სამიზნეებს იძლევა: მთავარი შინაარსი უნდა გამოჩნდეს 2.5 წამში (LCP), გვერდმა უნდა უპასუხოს შეყვანას 200 მილიწამში (INP), ხოლო განლაგების ცვლილება უნდა იყოს 0.1 ან ნაკლები (CLS), რეალური ვიზიტების 75-ე პროცენტილზე გაზომილი.
მოქმედებს თუ არა საიტის სიჩქარე SEO-ზე?
დიახ, ოდნავ. Google იყენებს გვერდის გამოცდილების სიგნალებს, მათ შორის Core Web Vitals-ს, მაგრამ შესაბამის შინაარსს გაცილებით მეტი მნიშვნელობა აქვს. სიჩქარე უფრო დიდ გავლენას ახდენს ვიზიტორებზე, რომლებიც ნელ გვერდებს წაკითხვამდე ტოვებენ.
რატომ განსხვავდება ჩემი PageSpeed Insights ქულა ყოველ ჯერზე?
ლაბორატორიული ქულა ერთი სიმულირებული ჩატვირთვიდან მოდის, ამიტომ ქსელისა და სერვერის დრო გაშვებებს შორის იცვლება. გაუშვით რამდენჯერმე და შეხედეთ ტენდენციას, ხოლო მეტი წონა მიანიჭეთ საველე მონაცემების სექციას, რომელიც რეალური Chrome მომხმარებლებისგან მოდის.
რა ანელებს ყველაზე ხშირად ვებსაიტებს?
ჩვეულებრივ, გადიდებული სურათები, ზედმეტი JavaScript, ვებ-შრიფტები და მესამე მხარის სკრიპტები, როგორიცაა ჩატის ვიჯეტები, რეკლამის პიქსელები და ჩამატებული ჩანართები. ნელი სერვერის პასუხი ან ცივი დაწყების (cold start) მქონე backend ყველა ამათ უმატებს.