WordPress-ის სურათების ოპტიმიზაცია: ზომები, srcset, WebP

WordPress-ის ნელი გვერდების უმეტესობა სურათების გამო ნელდება და ამ წონის თითქმის მთელი ნაწილის მოშორება შესაძლებელია. თანმიმდევრობა ყოველთვის ერთი და იგივეა. პირველ რიგში შეწყვიტე ისეთი ფაილების ატვირთვა, რომლებიც ნებისმიერ ეკრანზე გამოსაჩენზე გაცილებით დიდია. შემდეგ დარწმუნდი, რომ WordPress ყოველ ვიზიტორს srcset-ის გავლით შესაფერისი ზომის ასლს აძლევს. მერე ჩართე lazy loading ყველაფრისთვის, რაც პირველი ეკრანის ქვემოთაა, მაგრამ არასდროს გვერდის თავში მდებარე მთავარი სურათისთვის. და მხოლოდ ამის შემდეგ ღირს WebP-ში გადაყვანა, რომელიც, როგორც წესი, იგივე თვალით შესამჩნევი ხარისხის დროს მოცულობის მეოთხედიდან ერთ მესამედამდე ზოგავს. გადაყვანა პლაგინით გააკეთო თუ ოფლაინ, საკუთარ კომპიუტერზე, დამოკიდებულია სურათების რაოდენობაზე, ახლების დამატების სიხშირეზე და იმაზე, რამდენ CPU-ს გაძლევს შენი გეგმა. ქვემოთ თითოეული ნაბიჯია განხილული პარამეტრებით, ფილტრებითა და ბრძანებებით, და პირდაპირაა ნათქვამი, სად აკეთებს ნაბიჯი იმაზე ნაკლებს, ვიდრე მისი რეკლამა ჰპირდება.

საიდან მოდის წონა#

გახსენი ბრაუზერის Network პანელი WordPress-ის ნელ გვერდზე და დაალაგე ზომის მიხედვით. სურათი ჩვეულებრივ ერთნაირია: რამდენიმე სურათი მთელი ტრაფიკის უმეტეს ნაწილს შეადგენს - ტელეფონით გადაღებული 4000 პიქსელიანი ფოტო მთავარი ბანერის ადგილას, 2 MB-იანი PNG ეკრანის ანაბეჭდი, 900 KB-იანი ლოგო, ოციოდე სრული ზომის JPEG-ის გალერეა, CSS-ით დაპატარავებული. ბრაუზერი ყველა ბაიტს ჩამოტვირთავს, თუნდაც მხოლოდ 400 პიქსელი დახატოს.

აქ სამი სხვადასხვა პრობლემაა და თითოეული განსხვავებულად იხსნება.

• ძალიან ბევრი პიქსელი. 700 პიქსელის სვეტში მოთავსებული 4000 პიქსელიანი სურათი დაახლოებით ოცდაათჯერ მეტ პიქსელს ატარებს, ვიდრე შეიძლება ჩანდეს. გამოსავალი: ზომის შემცირება.
• ძალიან ბევრი ბაიტი თითო პიქსელზე. 100 ხარისხით შენახული JPEG რამდენჯერმე დიდია 80 ხარისხისაზე, ხოლო განსხვავებას ვერ შენიშნავ. გამოსავალი: შეკუმშვა ან უკეთესი ფორმატი.
• ძალიან ბევრი სურათი ერთდროულად. ორმოც სურათიანი გვერდისთვის ყველა ორმოცი არ არის საჭირო, სანამ ვიზიტორი გვერდს არ გადაახვევს. გამოსავალი: lazy loading.

WebP-ში გადაყვანა მხოლოდ მეორე პრობლემას წყვეტს და ბოლოს უნდა მივმართოთ. თუ 4000 პიქსელიან სურათს WebP-ად მიაწვდი, ფაილი უფრო პატარა იქნება, მაგრამ მაინც მეტისმეტად დიდი. სტატიაში როგორ მოქმედებს ჰოსტინგი TTFB-სა და Core Web Vitals-ზე ახსნილია, რატომ არის ყველაზე დიდი სურათი ჩვეულებრივ ის ელემენტი, რომელსაც Largest Contentful Paint ზომავს, და ამიტომ სურათებთან სწორი მუშაობა ისეთ მაჩვენებელს ამოძრავებს, რომელსაც საძიებო სისტემები ითვალისწინებენ. სერვერის სისწრაფე ამას ვერ გადაარჩენს: 3 MB ნებისმიერ ჰოსტზე 3 MB-ია.

რას აკეთებს WordPress ატვირთვისას თავისით#

როცა ფაილს Media Library-ში ამატებ, WordPress ორიგინალს ინახავს და უფრო პატარა ასლებს ქმნის. ნაგულისხმევი ზომები მოცემულია პარამეტრებში, განყოფილება მედია, ხოლო თემები და პლაგინები კოდში რეგისტრირებენ დამატებითს.

თემები მეტ ზომას add_image_size()-ით ამატებენ და თითოეული მათგანი ერთ ატვირთვაზე ფაილების რაოდენობას ამრავლებს. ერთმა ატვირთვამ დისკზე ადვილად შეიძლება ათიდან ოც ფაილამდე შექმნას. ეს მნიშვნელოვანია როგორც ადგილისთვის, ისე გადაყვანის დროისთვის, და ამიტომაა, რომ ინსტრუმენტები, რომლებიც „სურათს“ ამუშავებენ, სინამდვილეში ათეულ ფაილს ამუშავებენ.

WordPress 5.3-იდან ზედა ზღვარიც არსებობს. თუ ატვირთული სურათი გრძელ გვერდზე 2560 პიქსელზე დიდია, WordPress მას ამ ზომამდე ამცირებს, ორიგინალს დისკზე ტოვებს და დაპატარავებულ ასლს გასცემს, რომლის სახელს -scaled დაბოლოება ემატება. ამას ფილტრი მართავს, ამიტომ ზღვარი შეგიძლია დაიწიო ან სრულად გამორთო:

// Lower the cap from 2560 to 1920 pixelsadd_filter( 'big_image_size_threshold', function () {    return 1920;} );// Or disable the automatic scaling entirely// add_filter( 'big_image_size_threshold', '__return_false' );

თითქმის ყველა საიტისთვის 1920 უკეთესი ზღვარია, ვიდრე 2560, რადგან ძალიან ცოტა მაკეტი აჩვენებს ამაზე ფართო სურათს. ზღვრის დაწევა წარსულში ატვირთულს არ ამცირებს; ის მხოლოდ ახალ ატვირთვებზე მოქმედებს.

ორი დეტალი, რომელიც ხალხს უკვირს. WordPress ზომის ასლების შექმნისას JPEG-ს თავიდან კუმშავს, ნაგულისხმევი ხარისხით 82. ეს გონივრული ნაგულისხმევია. ხოლო ორიგინალი ფაილი დისკზე შეხებული არ რჩება, ამიტომ uploads საქაღალდე უფრო მძიმეა, ვიდრე ის, რასაც ვიზიტორები ოდესმე ჩამოტვირთავენ.

ზომები: ნუ ატვირთავ იმას, რასაც ვერავინ დაინახავს#

ყველაზე იაფი დანაზოგი ჩვევის გარდა არაფერი ღირს. ატვირთვამდე გადაწყვიტე, რა მაქსიმალური სიგანით გამოჩნდება სურათი, და ექსპორტი გააკეთე დაახლოებით ორჯერ უფრო ფართოდ მაღალი სიმკვრივის ეკრანებისთვის, მეტად არა.

ფოტოები JPEG-ად ან WebP-ად შეინახე. ეკრანის ანაბეჭდები და მკვეთრკიდეებიანი ბრტყელი გრაფიკა ხშირად უკეთ იკუმშება PNG-ად ან უდანაკარგო WebP-ად, ხოლო ფოტოს PNG-ად შენახვა თითქმის ყოველთვის შეცდომაა, რომლის გასწორებაც ღირს. ლოგო ან ხატულა SVG უნდა იყოს; WordPress ნაგულისხმევად SVG-ის ატვირთვას არ უშვებს, რადგან SVG სკრიპტებს შეიძლება შეიცავდეს, ამიტომ ჩართე ის მხოლოდ სანდო პლაგინით და მხოლოდ ადმინისტრატორებისთვის.

თუ უკვე არსებულ საიტს ასწორებ და არა ნულიდან იწყებ, საწყისს რიცხვები გიჩვენებს. ჯერ ყველაზე დიდი ფაილები გამოიტანე:

$ cd wp-content/uploads$ find . -type f \( -name '*.jpg' -o -name '*.jpeg' -o -name '*.png' \) \    -size +500k -printf '%s %p\n' | sort -rn | head -20

ტექსტში არსებული სურათისთვის 500 KB-ზე მეტი გასასწორებელი კანდიდატია. ზედა ოცი ხელით გაასწორე და, როგორც წესი, წონის უმეტეს ნაწილს მოაცილებ.

როგორ მუშაობს srcset და რატომ სჭირდება სწორი ზომები#

srcset ატრიბუტი ბრაუზერს საშუალებას აძლევს ერთი სურათის რამდენიმე სიგანიდან აირჩიოს, ხოლო sizes ეუბნება, რა სიგანით გამოჩნდება. WordPress ორივეს ავტომატურად ამატებს რედაქტორით ჩასმულ სურათებზე და შექმნილი ასლებიდან აგებს:

<img src="/wp-content/uploads/2026/10/cafe-1024x683.jpg"     srcset="/wp-content/uploads/2026/10/cafe-300x200.jpg 300w,             /wp-content/uploads/2026/10/cafe-768x512.jpg 768w,             /wp-content/uploads/2026/10/cafe-1024x683.jpg 1024w,             /wp-content/uploads/2026/10/cafe-1536x1024.jpg 1536w"     sizes="(max-width: 1024px) 100vw, 1024px"     width="1024" height="683" alt="A cafe interior" loading="lazy">

ბრაუზერი sizes მინიშნებას კითხულობს, ეკრანის პიქსელების სიმკვრივეზე ამრავლებს და ჩამოტვირთავს ყველაზე პატარა კანდიდატს, რომელიც საკმარისად ფართოა. 390 პიქსელიანი ხედვის არეალისა და 3x სიმკვრივის ტელეფონს დაახლოებით 1170 პიქსელი უნდა; 700 პიქსელის სვეტიან კომპიუტერს 1x-ზე 700. სიგანის აღმწერი (300w) ფაილის რეალური სიგანეა პიქსელებში, რის წყალობითაც ბრაუზერს კანდიდატების შედარება ჩამოტვირთვის გარეშე შეუძლია.

ეს მხოლოდ მაშინ ეხმარება, თუ კანდიდატები არსებობს. სამი ხშირი მარცხი:

• დიდი ასლი მხოლოდ ორიგინალია. თუ თემა 768-სა და 2560-ს შორის არცერთ ზომას არ არეგისტრირებს, ტელეფონი, რომელსაც 1170 პიქსელი უნდა, 1536-იან ასლს ან ორიგინალს მიიღებს. ზომის დამატება 1200-ზე ან 1600-ზე ეხმარება, მაგრამ მხოლოდ ახალ ატვირთვებზე (იხილე ქვემოთ რეგენერაცია).
• არასწორი `sizes`. WordPress ჩვენების სიგანეს იმ ზომით ხვდება, რომელიც ჩასვი. თუ თემა სურათს ვიწრო სვეტში აჩვენებს, ხოლო sizes ამბობს 100vw-ს, ბრაუზერი საჭიროზე დიდ კანდიდატს ჩამოტვირთავს. თემის დეველოპერები ამას wp_calculate_image_sizes ფილტრით ასწორებენ; საიტის მფლობელმა ჩასმისას უფრო პატარა ზომა უნდა აირჩიოს ან თემა გაასწოროს.
• თემის შაბლონებში ან გვერდის კონსტრუქტორებში პირდაპირ ჩაწერილი სურათები. თუ გამოსავალი დანართის ID-ით კი არა, უშუალო URL-ით აიგო, srcset არ იქნება. გამოიყენე კონსტრუქტორის სურათის ველი, რომელიც დანართს ინახავს, და არა ჩასმული მისამართი.

ტეგზე ყოველთვის დატოვე width და height. WordPress მათ დანართის მეტამონაცემებიდან ამატებს და ბრაუზერს სურათის ჩამოსვლამდე ადგილის დაჯავშნის საშუალებას აძლევს, ამიტომ გვერდი არ ხტება. ეს განლაგების წანაცვლების ყველაზე ძლიერი გამოსწორებაა და უკვე გაკეთებულია, თუ კონსტრუქტორი ატრიბუტებს არ აცლის.

რომ ნახო, რა ზომებია შენს საიტზე რეალურად, და კონკრეტული სურათი შეამოწმო, გამოიყენე WP-CLI, თუ გაქვს:

$ wp media image-size$ wp post meta get 123 _wp_attachment_metadata --format=json | head -c 600

პირველი ბრძანება ყველა რეგისტრირებულ ზომას გამოიტანს მათი ზომებითა და იმის ნიშნით, იჭრება თუ არა. მეორე აჩვენებს, რა შეიქმნა 123-ე დანართისთვის.

მინიატურების რეგენერაცია ცვლილების შემდეგ#

დაამატე ზომა, შეცვალე მოჭრა ან დაწიე ხარისხი - უკვე ატვირთულ სურათებზე არაფერი შეიცვლება. დისკზე არსებული ასლები ატვირთვისას შეიქმნა. მათ ხელახლა შესაქმნელად რეგენერაციაა საჭირო:

$ wp media regenerate --only-missing --yes

--only-missing მხოლოდ იმ ზომებს ქმნის, რომლებიც ჯერ არ არსებობს, ეს სწრაფია და უსაფრთხო. მის გარეშე WordPress ყველა დანართის ყველა ზომას თავიდან ააგებს, რაც რამდენიმე ათასი სურათის ბიბლიოთეკაზე დიდხანს გრძელდება და CPU-ს ძალიან ტვირთავს, ამიტომ მშვიდ საათებში გაუშვი. თუ shell-ზე წვდომა არ გაქვს, გამოიყენე რეგენერაციის პლაგინი ადმინისტრირების პანელიდან და ელოდე, რომ ის პატარა პარტიებად დაამუშავებს.

სრულ რეგენერაციამდე გააკეთე backup. ის ფაილებს ცვლის და პატარა სერვერზე შეწყვეტილმა გაშვებამ შეიძლება ზოგი ჩანაწერი წაშლილ ზომებზე მიუთითებელი დატოვოს. სტატია backup, რომელიც ნამდვილად აღდგება აღწერს, როგორ დარწმუნდე, რომ ასლი გამოსადეგია, სანამ მას დაეყრდნობი, ხოლო staging საიტის სამუშაო პროცესი პირველი გავლისთვის კარგი ადგილია.

დაალაგე კიდეც ნამუშევარი. ძველი თემის გამოუყენებელი ზომები დისკზე სამუდამოდ რჩება. თემის შეცვლის შემდეგ ახალი კომპლექტით რეგენერაციამ და ობოლი ფაილების წაშლამ დიდ ბიბლიოთეკაში გიგაბაიტები შეიძლება გაათავისუფლოს.

Lazy loading და ერთი სურათი, რომელსაც ის არ უნდა ჰქონდეს#

Lazy loading სურათის ჩამოტვირთვას აგვიანებს, სანამ ის ხილული არეალის სიახლოვეს არ მოხვდება, ამიტომ გრძელი გვერდი ყველაფერს მისვლისთანავე არ იტვირთავს. WordPress 5.5-იდან ეს ნაგულისხმევია: loading="lazy" ატრიბუტი ემატება შიგთავსში არსებულ სურათებსა და iframe-ებს, პლაგინი საჭირო არ არის. ბრაუზერები მას ნატიურად უჭერენ მხარს და ის უფრო იაფი და საიმედოა, ვიდრე ადრინდელი JavaScript-ის ჩამტვირთველები.

მნიშვნელოვანია საპირისპირო წესი. არასდროს გამოიყენო lazy loading გვერდის თავში მდებარე სურათზე. მთავარი ან რჩეული სურათი ჩვეულებრივ Largest Contentful Paint-ის ელემენტია და ბრაუზერისთვის „დაელოდე“-ს თქმა პირდაპირ აგვიანებს იმას, რაც იზომება. WordPress-ის ახალი ვერსიები შიგთავსის პირველ სურათს loading="lazy"-ს უკვე აღარ ამატებენ და fetchpriority="high"-ს უსვამენ, მაგრამ თემები და კონსტრუქტორები ამას ხშირად გადაწერენ, ამიტომ მზა HTML შეამოწმე და ნუ დაუშვებ.

მთავარი სურათის სწორი ჭდე მარტივია, პრიორიტეტის მინიშნებით:

<img src="/wp-content/uploads/2026/10/hero-1600.webp" width="1600" height="900"     alt="Product on a desk" fetchpriority="high" decoding="async">

ცალკეული სურათებისთვის ნაგულისხმევს ფილტრით გამორთავ, ხოლო იგივე ფილტრების სისტემა მას გლობალურადაც ამორთავს, თუ თემასთან კონფლიქტობს:

add_filter( 'wp_img_tag_add_loading_attr', function ( $value, $image, $context ) {    // Return false to omit loading="lazy" for this tag    if ( strpos( $image, 'hero-' ) !== false ) {        return false;    }    return $value;}, 10, 3 );

ყველაფერი, რაც პირველი ეკრანის ქვემოთაა, lazy უნდა იყოს: გალერეის მინიატურები, ქვედა ნაწილის ლოგოები, კომენტარებში ავატარები. Lazy loading-ს ნუ დააწყობ იმავე ტეგებს გადამწერ lazy loading პლაგინზე: ორი სისტემა, რომელიც ერთმანეთს ეჯიბრება, სურათების საერთოდ არჩენის გარანტირებული გზაა. თუ სურათები ცარიელ ბლოკებად რჩება, სანამ არ გადაახვევ, ან არასდროს იტვირთება, პლაგინში ეს პარამეტრი გამორთე და ნატიურ ატრიბუტს დაეყრდენი.

CSS-ში დაყენებულ ფონურ სურათებს loading="lazy" არ მოიცავს. CSS ფონად აგებულ ბანერს ამ გზით ვერ მიანიჭებ პრიორიტეტს და ვერ ჩატვირთავ ნელა, და ეს კიდევ ერთი მიზეზია, რომ მნიშვნელოვანი სურათებისთვის ნამდვილი img ტეგი ამჯობინო.

WebP: რას იძლევა და რას არა#

WebP Google-ის სურათის ფორმატია, რომელიც დანაკარგიან და უდანაკარგო შეკუმშვას და გამჭვირვალობას უჭერს მხარს. ფოტოები, როგორც წესი, დაახლოებით 25-35 პროცენტით პატარა გამოდის ეკვივალენტურ JPEG-ზე მსგავსი ხილული ხარისხის დროს, ხოლო უდანაკარგო WebP ჩვეულებრივ იმ PNG-ზე პატარაა, რომელსაც ცვლის. მას ყველა დღევანდელი ბრაუზერი აჩვენებს, ამიტომ მისი უსაფრთხო ნაგულისხმევად მიჩნევა შეგიძლია და ვიზიტორებზე ზრუნვა აღარ გჭირდება, რომლებსაც ის ვერ წაუკითხავთ. AVIF კიდევ უფრო ძლიერად კუმშავს, მაგრამ კოდირება გაცილებით დიდხანს გრძელდება; WordPress 6.5 და უფრო ახალი AVIF-ის ატვირთვას იღებს, თუმცა საიტების უმეტესობას ის არ სჭირდება.

WordPress WebP-ის ატვირთვას 5.8 ვერსიიდან იღებს. .webp ფაილი შეგიძლია Media Library-ში გადაათრიო და ის ყველა სხვა სურათივით მუშაობს: ზომის ასლები იქმნება და srcset მუშაობს. შეიქმნება თუ არა ზომის ასლები, სერვერზე არსებულ გამოსახულების ბიბლიოთეკაზეა დამოკიდებული: რედაქტორს სჭირდება GD ან Imagick, WebP-ის მხარდაჭერით აგებული. Site Health ეკრანი განყოფილებაში ხელსაწყოები, საიტის ჯანმრთელობა გიჩვენებს, რა არის დაყენებული. თუ ის აცხადებს, რომ WebP-ის მხარდაჭერა არ არის, .webp ფაილების ატვირთვა იმუშავებს, მაგრამ შემცირებული ვერსიები არ შეიქმნება.

გულწრფელად ვთქვათ შეზღუდვები:

• WebP ზედმეტად დიდ სურათს არ ასწორებს. ჯერ ზომა შეამცირე.
• მოგება განსხვავებულია. ფოტო ბევრს ზოგავს; უკვე ძლიერად შეკუმშული სურათი ცოტას; ზოგი პატარა PNG უფრო დიდი ხდება.
• გადაყვანილი ასლი თითო ზომაზე მეორე ფაილია. თუ ორივეს ინახავ, დისკის მოხმარება ჯერ იზრდება და მხოლოდ შემდეგ მცირდება.
• ძალიან მაღალი ხარისხის პარამეტრებისას უპირატესობა მცირდება. ფოტოებისთვის სასარგებლო დიაპაზონია ხარისხი 75-იდან 85-მდე.

პლაგინი თუ ოფლაინ კონვერტაცია#

ორი მიდგომა არსებობს და სწორი საიტზეა დამოკიდებული.

პლაგინი

სურათების პლაგინები, როგორიცაა ShortPixel, Imagify, EWWW Image Optimizer და Smush, ატვირთვისას გარდაქმნიან და კუმშავენ, არსებულ ბიბლიოთეკას პარტიულად ამუშავებენ და ჭდეს ისე გადაწერენ, რომ WebP-ის მხარდაჭერის მქონე ვიზიტორებმა WebP მიიღონ. ზოგი ამას შენს სერვერზე აკეთებს GD-ის ან Imagick-ის დახმარებით; სხვები ფაილს მწარმოებლის სერვისზე აგზავნიან და შედეგს იბრუნებენ, რაც შენს CPU-ს ზოგავს, მაგრამ ნიშნავს, რომ სურათები შენი სერვერიდან გადიან და ჩვეულებრივ კვოტა ან ფასიანი გეგმა გვხვდება. წაიკითხე, რას აკეთებს პლაგინი ნამდვილად, სანამ ჩართავ, რადგან დეტალები განსხვავდება, ხოლო სარეკლამო გვერდები მათ ბუნდოვანს ხდიან.

პრაქტიკული მომენტები პატარა გეგმაზე არსებული პლაგინისთვის:

• პარტიული გადაყვანა ის ადგილია, სადაც გეგმები იტანჯება. რამდენიმე ათასი სურათის ბიბლიოთეკის გადაყვანა CPU-სა და PHP-ის მეხსიერებაზე დატვირთვის აფეთქებაა. RE:NODE-ზე CPU-ს ლიმიტი ნაყიდ წილზე მკაცრი შეკავებაა, ამიტომ პატარა გეგმაზე პარტიული გაშვება ვარდნის ნაცვლად უფრო დიდხანს გრძელდება, ხოლო ამოცანა, რომელიც მეხსიერების ლიმიტს გადააჭარბებს, იწვევს იმას, რომ ბირთვი კონტეინერს აჩერებს და ის swap-ში გადასვლის ნაცვლად სუფთად გადაიტვირთება. პლაგინი პატარა პარტიებზე დააყენე და ღამით მიეცი მუშაობის საშუალება.
• შეამოწმე, როგორ გაიცემა WebP. პლაგინები ან img ტეგებს WebP-ზე გადაწერენ, ან მათ picture ელემენტში ხვევენ, ან სერვერის წესებს ეყრდნობიან, რომლებიც ფაილს Accept სათაურის მიხედვით ცვლიან. პირველი ორი ვარიანტი ნებისმიერ ქეშთან მუშაობს. ბოლოს სერვერის კონფიგურაცია და Vary: Accept სათაური სჭირდება, რომ ქეშმა WebP ისეთ ბრაუზერს არ მისცეს, რომელსაც მისი წაკითხვა არ შეუძლია.
• შეინახე ორიგინალები. პლაგინების უმეტესობას ორიგინალის ასლის შენახვა შეუძლია; ეს ჩართული დატოვე, სანამ შედეგს ნამდვილ გვერდზე არ ნახავ.
• ერთი ოპტიმიზატორი და არა სამი. ერთსა და იმავე ფაილებზე ორი სურათის პლაგინი ნიშნავს ორჯერ შეკუმშულ ფაილებს და წესებს, რომლებიც ერთმანეთს ეჯახება.

ოფლაინ კონვერტაცია

თუ სურათების ნაკრები ფიქსირებულია, მაგალითად პორტფოლიო, მენიუ ან პროდუქტების კატალოგი, რომელიც თვეში ერთხელ იცვლება, გარდაქმენი ის საკუთარ კომპიუტერზე და ატვირთე შედეგი. ხარისხს ზუსტად აკონტროლებ, სერვერზე არაფერი სრულდება და არაფერი დგება, რაც პლაგინის განახლების შემდეგ შეიძლება გაფუჭდეს.

Google-ის libwebp პაკეტის cwebp ინსტრუმენტით ან ImageMagick-ით საქაღალდე ერთი ბრძანებით გარდაიქმნება:

$ for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done# or with ImageMagick, also resizing to 1600 px wide at most$ mogrify -path out -format webp -quality 80 -resize '1600x>' *.jpg

ზომის შეცვლის არგუმენტში > ნიშნავს „მხოლოდ დიდის დაპატარავება“, ამიტომ უფრო პატარა ფაილები თავისი ზომით რჩება. მთელი ბიბლიოთეკის დამუშავებამდე რამდენიმე შედეგი თვალით შეამოწმე და ფაილების ზომები შეადარე: თუ WebP წყაროზე პატარა არ არის, წყარო დატოვე.

შედეგები ატვირთე ფაილების მენეჯერით ან SFTP-ით. RE:NODE-ის ფაილების მენეჯერი საქაღალდეების გადათრევით ატვირთვას იღებს და სურათებს ბრაუზერში აჩვენებს, რაც პარტიის შერჩევით შესამოწმებლად საკმარისია. პირდაპირ wp-content/uploads-ში ჩაგდებული ფაილები Media Library-ში არ ჩნდება, რადგან ბიბლიოთეკა მონაცემთა ბაზის ცხრილია. ფაილები, რომლებიც რედაქტორში უნდა გამოჩნდეს, თავად Media Library-ით ატვირთე. ფაილები, რომლებზეც მხოლოდ თემა მიუთითებს (ფონები, ლოგოები), თემის საქაღალდეში მოათავსე და პირდაპირ მიუთითე.

ჰიბრიდი, რომელიც უმეტესობას გამოდგება: დიდი სურათები (ბანერები, თავსართები), სადაც ხარისხი ყველაზე მნიშვნელოვანია, ხელით დაამცირე და შეკუმშე, ხოლო რედაქტორების ჩვეულებრივი ატვირთვების ნაკადი პლაგინს მიანდე.

WebP-ის გაცემა სარეზერვო ვარიანტით#

თუ გარდაქმნი, მაგრამ ისეთი ბრაუზერის მხარდაჭერა გინდა, რომელსაც WebP-ის წაკითხვა არ შეუძლია, სტანდარტული ჭდე picture-ია, რომელიც ბრაუზერს ფორმატით არჩევის საშუალებას აძლევს:

<picture>  <source srcset="/wp-content/uploads/2026/10/cafe.webp" type="image/webp">  <img src="/wp-content/uploads/2026/10/cafe.jpg" width="1024" height="683" alt="A cafe"></picture>

2026 წელს სარეზერვო ვარიანტი იშვიათად თუ არის საჭირო და ყველაზე მარტივი მიდგომა მხოლოდ WebP-ია. პლაგინი picture რეჟიმით ან Accept სათაურის რეჟიმით პრობლემას წყვეტს, რომელიც საიტების უმეტესობას უკვე აღარ აქვს, ამიტომ აირჩიე პარამეტრი, რომელიც სერვერის ყველაზე ნაკლებ კონფიგურაციას ტოვებს.

თუ მაინც Accept სათაურით გასცემ Apache-ის სტილის სერვერზე, გადაყვანის წესი ასე გამოიყურება და მუშაობს მხოლოდ იმ შემთხვევაში, თუ თითოეული ორიგინალის გვერდით .webp დევს:

<IfModule mod_rewrite.c>RewriteEngine OnRewriteCond %{HTTP_ACCEPT} image/webpRewriteCond %{REQUEST_FILENAME} \.(jpe?g|png)$RewriteCond %{REQUEST_FILENAME}.webp -fRewriteRule ^(.+)$ $1.webp [T=image/webp,E=WEBP:1,L]</IfModule><IfModule mod_headers.c>Header append Vary Accept env=REDIRECT_accept</IfModule>

nginx-ზე .htaccess არ არსებობს, ამიტომ იგივე იდეა სერვერის კონფიგურაციაში ცხოვრობს, როგორც map $http_accept-ზე. დარწმუნდი, რომ სერვერი .webp ფაილებისთვის კონტენტის ტიპად image/webp-ს აგზავნის. ძველ mime.types ფაილებს ეს ჩანაწერი აკლია და application/octet-stream-ად გაცემული WebP ჩანაცვლად ჩამოიტვირთება და არ გამოჩნდება. შეამოწმე curl-ით:

$ curl -sI https://example.com/wp-content/uploads/2026/10/cafe.webp \    | grep -i -E '^(content-type|content-length|cache-control)'

შემდეგ სურათებს ქეშში შენახვის დიდი ვადა მიანიჭე, რადგან ერთსა და იმავე ფაილის სახელზე ისინი არ იცვლება. Cache-Control სტატიკური ფაილებისთვის განხილულია სტატიაში HTTP ქეშირების სათაურები, ხოლო WordPress-ის ქეშირება განმარტავს, რატომ წყვეტენ გვერდის ქეში და სურათების ოპტიმიზაცია პრობლემის სხვადასხვა ნახევარს.

მაგალითი პრაქტიკიდან#

მაღაზიის პროდუქტის გვერდზე რვა ფოტოა, ტელეფონიდან პირდაპირ ატვირთული 4032 x 3024 პიქსელის ზომით, თითო დაახლოებით 3,4 MB. WordPress-მა თითოეული 2560 პიქსელამდე დაამცირა, ამიტომ ყველაზე დიდი გაცემული ფაილი დაახლოებით 1,4 MB-ია, ხოლო ბადე მათ 380 პიქსელის სიგანით აჩვენებს.

1. დააყენე big_image_size_threshold 1920-ზე და დაარეგისტრირე 760 პიქსელიანი ზომა ბადისთვის (ჩვენების 380 სიგანის ორმაგი).
2. გაუშვი wp media regenerate --only-missing --yes, რომ ახალი ზომა არსებული პროდუქტებისთვის შეიქმნას.
3. რვა მთავარი სურათი ხელახლა ექსპორტირე 1600 პიქსელზე WebP-ად, ხარისხი 80, რაც თითო ფაილზე დაახლოებით 120-დან 200 KB-ს იძლევა.
4. დარწმუნდი, რომ გვერდის წყაროში srcset ჩანს და პირველ სურათს loading="lazy" არ აქვს.
5. ხელახლა გაზომე.

გვერდზე სურათების წონა დაახლოებით რვა-თერთმეტი მეგაბაიტიდან ორზე გაცილებით ნაკლებზე ეცემა. ამისთვის პლაგინი არ დასჭირვებია. ბადეც ბევრად შემსუბუქდა უბრალოდ იმიტომ, რომ ბრაუზერი ახლა 760 პიქსელიან ასლს ირჩევს და არა 2560-იანს.

როგორ გავზომოთ, რომ იმუშავა#

არ ენდო პლაგინის საკუთარ პროცენტებს. გვერდი გაზომე ადრე და მერე ერთი და იგივე ინსტრუმენტით: ბრაუზერის Network პანელი (გამორთე ქეში, შემდეგ წაიკითხე სურათების გადაცემული ზომა), Lighthouse ან PageSpeed Insights. სამ სიდიდეს უყურე: სურათების ჯამური წონა, LCP ელემენტი და მისი ჩატვირთვის დრო, განლაგების წანაცვლება.

ბრძანების სტრიქონიდან შეგიძლია შეამოწმო, რას მიიღებდა კონკრეტული ვიზიტორი:

$ curl -s -o /dev/null -w '%{size_download} bytes\n' \    -H 'Accept: image/webp,*/*' \    https://example.com/wp-content/uploads/2026/10/cafe.jpg

გაუშვი ერთხელ Accept სათაურით და ერთხელ მის გარეშე. თუ ბაიტების რაოდენობა განსხვავდება, სერვერის მხარეს შეთანხმება მუშაობს; თუ ემთხვევა, ყველას ორიგინალს აძლევ. გახსოვდეს, რომ საიტის წინ მდგარ CDN-ს ან გვერდის ქეშს გვერდის ძველი ვერსია შეიძლება ჰქონდეს, ამიტომ ცვლილების შემდეგ გაასუფთავე, თორემ გუშინდელ HTML-ს გაზომავ.

მოკლე სია სურათებთან დაკავშირებული ნებისმიერი პრობლემისთვის:

1. ფაილი ნაჩვენები ზომაზე ორჯერ ან მეტჯერ დიდია?
2. აქვს თუ არა ტეგს srcset, width და height?
3. თავისუფალია თუ არა ზედა სურათი loading="lazy"-სგან?
4. შეესაბამება თუ არა ფორმატი შიგთავსს (ფოტო, გრაფიკა, ლოგო)?
5. დაყენებულია თუ არა ამ ტიპის ფაილებისთვის გრძელი Cache-Control?

შენიშვნები ჰოსტინგზე#

სურათებთან მუშაობა ძირითადად ფრონტენდის საქმეა და არცერთი გეგმა ზედმეტად დიდ ფაილებს არ ანაზღაურებს. ჰოსტი წყვეტს, რამდენად კომფორტულია მექანიკა. RE:NODE-ის WordPress გეგმაზე ფაილების მენეჯერში შეგიძლია .htaccess ან wp-config.php შეცვალო, საქაღალდეები SFTP-ით ატვირთო და პარტიულ გაშვებამდე Backups ჩანართზე backup გააკეთო. backup-ის სლოტების რაოდენობა გეგმის მიხედვით განსხვავდება, ამიტომ დაყრდნობამდე გეგმის გვერდზე შეამოწმე. კიდევ ერთი ლიმიტი, რომელსაც თვალყური უნდა ადევნო, დისკის ადგილია: ყოველი ატვირთვა ათეულ ფაილად მრავლდება, ხოლო პლაგინი, რომელიც ორიგინალებს WebP ასლებთან ერთად ინახავს, მეტ ადგილს იკავებს და არა ნაკლებს, სანამ არ გაწმენდ. თუ პრობლემა დიდი ბიბლიოთეკაა, WordPress-ის მედიის S3-ზე გატანა მას ვებ სერვერის დისკიდან აშორებს კიდევ ერთი მოძრავი ნაწილის ფასად.

FAQ#

WebP უკეთესია JPEG-ზე WordPress-ისთვის?

ფოტოებისთვის ის ჩვეულებრივ 25-35 პროცენტით პატარაა იგივე ხილული ხარისხის დროს და ყველა დღევანდელი ბრაუზერი მას კითხულობს. ეს არ დაგეხმარება, თუ სურათი თავიდანვე არასწორი ზომისაა, ამიტომ ჯერ დაამცირე და მერე გარდაქმენი.

მჭირდება პლაგინი WebP-ის გამოსაყენებლად?

არა. WordPress WebP-ს 5.8-იდან იღებს, ხოლო გარდაქმნა ოფლაინ cwebp-ით ან ImageMagick-ით შეგიძლია და მზა ფაილები ატვირთო. პლაგინს აზრი აქვს, როცა ბევრი ტვირთავს და გარდაქმნა ავტომატურად გინდა.

აზარალებს თუ არა lazy loading SEO-ს?

ნატიურ loading="lazy"-ს საძიებო სისტემები სწორად კითხულობენ, ამიტომ პირველი ეკრანის ქვემოთ სურათები ინდექსირდება. ზიანს გვერდის თავში მთავარი სურათის lazy loading მოაქვს, რომელიც Largest Contentful Paint-ს აგვიანებს. პირველი სურათი ჩვეულებრივად ჩატვირთე.

რატომ რჩება სურათები ოპტიმიზაციის შემდეგაც დიდი?

ჩვეულებრივ გვერდი ორიგინალს ან -scaled ასლს იყენებს, რადგან srcset აკლია, თემამ საშუალო ზომები არ დაარეგისტრირა ან სურათი CSS ფონიდან მოდის. მზა HTML-ში srcset ატრიბუტი შეამოწმე, ხოლო Network პანელში - რომელი ფაილი იტვირთება რეალურად.

უნდა გადავაგენერირო მინიატურები თემის შეცვლის შემდეგ?

დიახ, თუ ახალი თემა სურათების სხვა ზომებს იყენებს. სხვაგვარად ის არარსებულ ზომებს ითხოვს და უფრო დიდზე გადადის. გაუშვი wp media regenerate --only-missing --yes, წინასწარ backup-ის გაკეთებით.

შეუძლია ოპტიმიზაციას სურათების დაზიანება?

დანაკარგიანი შეკუმშვა მონაცემებს აგდებს და დაბრუნება შეუძლებელია, ამიტომ ორიგინალები შეინახე, სანამ შედეგს ნამდვილ გვერდებზე არ შეამოწმებ. არასდროს გადააწერო ერთადერთი ასლი შეკუმშულით.