WordPress-ის სისწრაფე და ქეშირება: რა ცვლის რეალურად TTFB-ს

ქეშის გარეშე ყოველი WordPress გვერდის ნახვა PHP-ს უშვებს: core იტვირთება, ყოველი აქტიური plugin იტვირთება, სრულდება ოცდაათიდან ასამდე ბაზის მოთხოვნა, და თემა გამოისახება. ეს ჩვეულებრივი საიტისთვის 300-დან 900 მილიწამამდე სერვერის დროა, და ის თავიდან მეორდება შემდეგი ვიზიტორისთვის, რომელიც იმავე გვერდს ითხოვს. სრული გვერდის ქეში მზა HTML-ს ინახავს და PHP-ს შეხების გარეშე გასცემს, რაც პირველ ბაიტამდე დროს 20-დან 80 მილიწამამდე ჩამოიყვანს. სხვა არაფერი, რისი გაკეთებაც შეგიძლია, ამ კლასში არ არის.

ყველაფერი ამის შემდეგ უფრო მცირე და კონკრეტულია: OPcache, რომ PHP საკუთარ თავს აღარ დააკომპილირებს, object cache მოთხოვნებისთვის, რომლებსაც page cache ვერ ფარავს, სურათების დისციპლინა, რომ ბრაუზერმა ნაკლები ჩამოტვირთოს, და front-end სამუშაო, რომელსაც ჰოსტინგი საერთოდ ვერ გააკეთებს. ეს პოსტი მათ იმ თანმიმდევრობით გადის, რომელიც ყველაზე მეტ დროს აბრუნებს, და გეუბნება, რომელი გაზომვა ამტკიცებს, რომ თითოეულმა იმუშავა.

სად მიდის დრო სინამდვილეში#

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

$ curl -o /dev/null -s -w "dns %{time_namelookup}  tcp %{time_connect}  \tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \  https://example.com/

გამოაკელი tls ttfb-ს და რაც დარჩება, სერვერის საკუთარი სამუშაოა: PHP, ბაზა და ფაილური სისტემა. ეს ერთადერთი რიცხვია, რომელსაც ქეშირება ცვლის. თუ შენი ttfb 0.6 s-ია და tls 0.12 s-ზე დასრულდა, დაახლოებით ნახევარი წამი PHP გაქვს დასაჩქარებელი. თუ ttfb 0.18 s-ია და გვერდი მაინც ნელა გრძნობა, პრობლემა ბრაუზერშია და ვერცერთი ჰოსტი ვერ გამოასწორებს - TTFB, Core Web Vitals და ჰოსტინგი ამ ხაზს უფრო დეტალურად ავლებს.

გაუშვი მოთხოვნა ორჯერ. მეორე გეუბნება, მუშაობს თუ არა ქეში; პირველი გეუბნება, რას იღებს უიღბლო ვიზიტორი.

Page caching, რაც მოგების უმეტესობაა#

Page cache ინახავს URL-ის გამოსახულ HTML-ს და შემდეგ მოთხოვნაზე პირდაპირ გასცემს. ბლოგისთვის, ვიზიტკა საიტისთვის ან დოკუმენტაციის საიტისთვის ეს თითქმის ყველა ვიზიტორს ფარავს, რადგან თითქმის ყველა ვიზიტორი შესული არ არის და ითხოვს იმას, რასაც ვიღაცამ უკვე მოითხოვა.

WordPress-ს ამისთვის ჩაშენებული hook აქვს. wp-config.php-ში define( 'WP_CACHE', true ); core-ს აიძულებს wp-content/advanced-cache.php ძალიან ადრე ჩატვირთოს, ჩარჩოს უმეტესობამდე, და ქეშირების plugin ამ ფაილს ჩადებს. პოპულარულებია WP Super Cache, W3 Total Cache, Cache Enabler, LiteSpeed Cache (სასარგებლოა მხოლოდ LiteSpeed სერვერზე) და WP Rocket. აირჩიე ერთი. ორი page cache ერთ საიტზე კლასიკური გზაა, რომ შესული ადმინისტრატორის ზოლი საჯაროდ გაიცეს.

სამი პარამეტრი plugin-ის დანარჩენ ეკრანებზე მნიშვნელოვანია:

• რა გვერდს უვლის ქეშს. ყოველი მოთხოვნა, რომელსაც აქვს wordpress_logged_in_*, comment_author_*, wp-postpass_* ან, მაღაზიაში, კალათის cookie, ახალი უნდა გაიცეს. ყველა სერიოზული plugin ამას ნაგულისხმევად აკეთებს. როცა ეს არასწორია, შედეგი სიმძიმე არ არის, ეს არის ერთი მომხმარებელი, რომელიც მეორის გვერდს ხედავს.
• ქეშის სიცოცხლის ხანგრძლივობა. რამდენიმე საათიდან ერთ დღემდე უმეტეს საიტს ერგება. მოკლე ხანგრძლივობა დაბალტრაფიკიან საიტზე მუდმივად ცივ ქეშად იქცევა, სადაც ყოველი გვერდი იწურება, სანამ ვინმე მას ორჯერ მოითხოვს.
• Preloading. Sitemap-ის გავლა ქეშის გასათბობად purge-ის შემდეგ. ღირს იმ საიტზე, რომელსაც ასობით გვერდი და მოკრძალებული ტრაფიკი აქვს; უაზროა დატვირთულზე, სადაც ვიზიტორები მას ერთ წუთში ათბობენ.

გადაამოწმე გარედან, გამოსული, private ფანჯარაში ან curl -I-ით. plugin-ების უმეტესობა header-ს ამატებს - x-cache: HIT, x-litespeed-cache: hit, კომენტარი HTML-ის ბოლოს. თუ ასეთ მარკერს ვერ პოულობ, შეადარე ttfb ერთი და იმავე URL-ზე ორ ზედიზედ მოთხოვნაზე: მომუშავე page cache აშკარა ჩავარდნას აჩვენებს.

რაშიც page cache ვერ დაგეხმარება: კალათა, checkout, ანგარიშის გვერდები, შესული მომხმარებლების ფორუმი, ყველაფერი, რაც თითო ვიზიტორზე პერსონალიზებულია. მაღაზიაზე ეს ნიშნავს, რომ შემოსავლისთვის ყველაზე მნიშვნელოვანი გვერდები ზუსტად ისინია, რომლებიც ყოველ ჰიტზე მაინც PHP-ს უშვებენ, ამიტომ WooCommerce-ის ჰოსტინგის მოთხოვნები ხარისხით განსხვავდება და არა ხარისხის ზომით.

OPcache#

PHP ყოველ მოთხოვნაზე წყაროს opcode-ებად აკომპილირებს, თუ OPcache არ არის ჩართული, რომ ისინი გაზიარებულ მეხსიერებაში შეინახოს. ოც plugin-იან WordPress-ში ათასობით ფაილია, ამიტომ ეს ქეშის გარეშე მოთხოვნაზე PHP დროის 30-დან 50 პროცენტს ღირს და მეხსიერების გარდა არაფერი უჯდება.

opcache.enable=1opcache.memory_consumption=192opcache.interned_strings_buffer=16opcache.max_accelerated_files=20000opcache.validate_timestamps=1opcache.revalidate_freq=2

ის, რასაც უნდა გაუძლო, არის opcache.validate_timestamps=0. ეს სწორი პარამეტრია აპლიკაციისთვის, რომელიც Git-იდან deploy-დება და შემდეგ restart-დება, და არასწორი WordPress-ისთვის, სადაც plugin-ისა და core-ის განახლებები ფაილებს ადმინისტრაციული პანელის შიგნიდან ცვლის. timestamp შემოწმებების გარეშე ეს განახლებები არაფერს აკეთებს, სანამ PHP არ გადაიტვირთება, ხოლო ნახევრად გამოყენებული განახლება გატეხილი საიტია.

შეამოწმე, სავსეა თუ არა OPcache, და ნუ ივარაუდებ. opcache_get_status() ერთხაზიან სკრიპტში, ან სტატუსის გვერდი, რომელსაც ქეშირების plugin-ების უმეტესობა შეიცავს, აჩვენებს num_cached_keys-ს max_cached_keys-თან შედარებით, used_memory-ს free_memory-სთან შედარებით, და hit rate-ს. სტაბილურ საიტზე დაახლოებით 95 პროცენტზე დაბალი hit rate ნიშნავს, რომ ქეში იდევნება, ანუ პირველი ორი რიცხვიდან ერთი ძალიან მცირეა.

Object caching და ბაზა#

WordPress-ს აქვს შიდა object cache, რომელიც მოთხოვნის შედეგებსა და გამოთვლილ მნიშვნელობებს გასაღებების ქვეშ ინახავს. ნაგულისხმევად ის თითო მოთხოვნაზეა: მოთხოვნის დასაწყისში აიგება და ბოლოს გადაიყრება, ამიტომ ის მხოლოდ ერთი გვერდის ჩატვირთვის შიგნით განმეორებულ სამუშაოს ზოგავს. მისი მუდმივად ქცევა drop-in-ს მოითხოვს wp-content/object-cache.php-ში, Redis-ით ან Memcached-ით მხარდაჭერილს, რომელსაც აყენებს plugin, როგორიცაა Redis Object Cache.

იყავი პატიოსანი, ხელმისაწვდომია თუ არა ეს შენთვის. მას სჭირდება Redis ან Memcached სერვერი, რომელსაც შენი PHP პროცესი აღწევს, და გაფართოება მასთან სასაუბროდ. ბევრ გაზიარებულ და container-ზე დაფუძნებულ ვებ ჰოსტინგს არცერთი არ აქვს - RE:NODE-ის მართული ბაზის ხაზები PostgreSQL და MongoDB-ია, რომლებსაც WordPress არ იყენებს - ამიტომ თუ რეალურ ინსტანციაზე ვერ მიუთითებ, მუდმივი object cache შენს სიაში არ არის და კარგად გაწყობილი page cache პროპორციულად უფრო მნიშვნელოვანია. Redis და როდის გჭირდება ის რეალურად ზოგადი სახით ამ გადაწყვეტილებას განიხილავს.

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

SELECT option_name, LENGTH(option_value) AS bytesFROM wp_optionsWHERE autoload IN ('yes', 'on')ORDER BY bytes DESCLIMIT 20;

IN clause იმიტომაა, რომ WordPress 6.6-მა autoload სვეტი უბრალო yes/no-დან ნაკრებად შეცვალა, რომელიც on, off და auto-ს შეიცავს, ამიტომ ძველი მნიშვნელობებისთვის დაწერილი მოთხოვნა ახალ ინსტალაციაზე ჩუმად არაფერს აბრუნებს. შეკრიბე bytes სვეტი: რამდენიმე ასეულ კილობაიტზე ნაკლები ჯანსაღია, მეგაბაიტზე მეტი გადასახადია ყოველ გვერდის ნახვაზე. ჩვეულებრივი დამნაშავეებია plugin, რომელიც დიდ ქეშირებულ payload-ს autoload-ირებულ option-ად ინახავს, და წლების განმავლობაში დარჩენილი ობოლი transient-ები plugin-ებისგან, რომლებიც გასუფთავების გარეშე წაშალეს.

პოსტის revision-ები მეორე ადვილი მოგებაა. ოთხმოცჯერ რედაქტირებული გვერდი wp_posts-ში ოთხმოც ასლს ატარებს. შეზღუდე ისინი wp-config.php-ში და არ წაშალო ხელით ყოველ წელს:

define( 'WP_POST_REVISIONS', 10 );define( 'EMPTY_TRASH_DAYS', 14 );

სურათები, რაც ბაიტების უმეტესობაა#

ტიპურ WordPress გვერდზე სურათები გადმოცემული წონის 60-დან 80 პროცენტამდეა. ამის გამოსასწორებლად სერვერი ჩართული არ უნდა იყოს.

• ატვირთე გონივრული ორიგინალები. WordPress 2560 პიქსელზე უფრო განიერს ამცირებს და ორიგინალს გვერდით -scaled-ად ინახავს, ამიტომ 6000-პიქსელიანი ტელეფონის ფოტო ორჯერ ხარჯავს საცავს და არაფერს გყიდის. ატვირთვამდე შეამცირე ზომა.
• გამოიყენე თანამედროვე ფორმატი. WordPress WebP ატვირთვებს 5.8-იდან იღებს და AVIF-ს 6.5-იდან. WebP ჩვეულებრივ 25-დან 35 პროცენტამდე უფრო მცირეა, ვიდრე ექვივალენტური JPEG იმავე ვიზუალურ ხარისხზე.
• Lazy loading უკვე ჩართულია. 5.5-იდან WordPress სურათებს loading="lazy"-ს ამატებს, ხოლო 6.3-იდან სავარაუდოდ უდიდეს სურათს ამის ნაცვლად fetchpriority="high"-ით ნიშნავს, რაც Largest Contentful Paint-ისთვის სწორი ქცევაა. plugin, რომელიც ყველაფერს lazy-ჩატვირთავს, მთავარი სურათის ჩათვლით, LCP-ს აუარესებს.
• თემის შეცვლის შემდეგ ხელახლა გენერირე thumbnail-ები. ახალი თემა სხვა ზომებს არეგისტრირებს; გენერაციის გარეშე ბრაუზერს სრული ზომის ფაილი მიეწოდება, რომელიც CSS-ში მცირდება.
• უყურე საცავს. ყოველი რეგისტრირებული ზომა ყოველ ატვირთვას ამრავლებს. ხუთი ზომა პლუს ორიგინალი პლუს scaled ასლი შვიდი ფაილია ფოტოზე, და მედია ბიბლიოთეკა უმეტეს WordPress გეგმაზე დისკის ყველაზე დიდი მომხმარებელია.

Front end ხშირად უფრო ნელი ნახევარია#

როცა პირველ ბაიტამდე დრო 200 მილიწამზე ნაკლებია, დარჩენილი წამები ბრაუზერს ეკუთვნის, და სწორედ იქ ცხოვრობს "ნელი WordPress"-ის უმეტესობა. ჰოსტინგი ქვემოთ ჩამოთვლილს ვერაფერს შეცვლის.

• Render-ის ბლოკავი CSS და JavaScript. page builder, რომელიც რვა stylesheet-ს ტვირთავს და jQuery-ს პლუს ხუთ plugin სკრიპტს, სანამ რამე გამოისახება.
• ფონტები. სამი ოჯახი ოთხ წონაში, თითოეული ცალკე ჩამოტვირთვა; თვითონ განათავსე, subset-ად გაჭერი და დააყენე font-display: swap.
• მესამე მხარის სკრიპტები. ჩატის ვიჯეტი, ორი analytics tag, თანხმობის ბანერი და pixel. თითოეული DNS ძიებაა, კავშირი და ბლოკავი სკრიპტი, და ისინი მუდმივად Interaction to Next Paint-ის ყველაზე ცუდი დამნაშავეებია.
• სლაიდერები და hero ვიდეოები. დიდი, ეკრანის ზედა ნაწილში და ჩვეულებრივ დეკორატიული.

ეს ნახევარი ბრაუზერის ხელსაწყოთი გაზომე და არა curl-ით. Core Web Vitals ანგარიშის საველე მონაცემები შენს ლაბორატორიულ ტესტს არ დაეთანხმება, და საველე მონაცემებს აქვს მნიშვნელობა. HTTP ქეშირების header-ები ახსნილი front-end სისწრაფის მეორე ნახევარს ფარავს: ბრაუზერის იძულება, შეინახოს ის, რაც უკვე ჩამოტვირთა, რომ განმეორებითი ნახვები არაფერი ღირდეს.

PHP worker-ები და მოცულობა, რომელზეც არავინ საუბრობს#

დატვირთვისას სისწრაფე განსხვავებული სიდიდეა, ვიდრე უსაქმოდ ყოფნისას. PHP-FPM pool-ს worker პროცესების ფიქსირებული რაოდენობა აქვს; თითოეული ერთდროულად ერთ მოთხოვნას ემსახურება. ამიტომ არითმეტიკა ულმობელია:

requests per second = workers / average request seconds

ოთხი worker 0.5 s-ზე ქეშის გარეშე მოთხოვნაზე რვა მოთხოვნაა წამში, და მეცხრე ვიზიტორი რიგში დგას. დაამატე page cache და იგივე ოთხი worker მხოლოდ იმ მოთხოვნების მცირე ნაწილს ემსახურება, რომლებიც ქეშს აცდენს, დანარჩენს კი დისკიდან მიკროწამებში პასუხობს. სწორედ ეს არის რეალური მიზეზი, რატომ აქვს ქეშირებას მნიშვნელობა პატარა გეგმაზე: ის მოცულობას სიდიდის რიგით ცვლის და არა მხოლოდ დაყოვნებას.

Worker-ების რაოდენობა მეხსიერებით არის შეზღუდული. ყოველ WordPress worker-ს 40-დან 80 MB-მდე resident ინახავს, მძიმე თემით ზოგჯერ მეტსაც, ამიტომ 1 GB RAM ვებ სერვერისა და ბაზის წილის შემდეგ, შესაძლოა, რვა-თორმეტ worker-ს უჭერს მხარს. pm.max_children-ის მეხსიერების მხარდაჭერაზე მაღლა დაყენება მოცულობას არ ამატებს; ის რიგს out-of-memory მოვლენად აქცევს. რამდენი RAM სჭირდება WordPress-ს ამ არითმეტიკას სათანადოდ აკეთებს, ხოლო php.ini პარამეტრები, რომლებსაც მნიშვნელობა აქვს ფარავს memory_limit-ს, რაც იმავე კითხვის თითო პროცესზე მხარეა.

რას ცვლის ჰოსტინგი და რას არა#

ჰოსტინგს ოთხი რამე ეკუთვნის, და ღირს ზუსტად იყო, რადგან ჰოსტი ვერ გაგიყიდის უფრო სწრაფ თემას.

• CPU წილი განსაზღვრავს, რამდენად სწრაფად სრულდება ერთი PHP მოთხოვნა. მკაცრი CPU შეზღუდვა ნიშნავს, რომ სერვერი თავის ლიმიტზე ნელია და არა გატეხილი.
• მეხსიერება განსაზღვრავს, რამდენი მოთხოვნა სრულდება ერთდროულად, worker-ების რაოდენობით.
• დისკს ნაკლები მნიშვნელობა აქვს, ვიდრე ხალხს ჰგონია, როცა OPcache გახურებულია, მაგრამ NVMe ცივ კითხვებს ამოკლებს და ბაზაში ჩაწერებს იაფს ხდის.
• მანძილი tcp-სა და tls-ის ქვედა ზღვარს ადგენს. გერმანიის სერვერი, რომელიც ბრაზილიაში მყოფ ვიზიტორებს პასუხობს, ორმხრივ გზაზე 200 მილიწამს იხდის, რასაც არ უნდა ქეშავდე. ეს არის CDN-ის წინ დაყენების საქმე და არა სხვა ჰოსტის.

RE:NODE-ზე ვებ გეგმები NVMe საცავზე მუშაობს გერმანიაში მდგარ აპარატურაზე, CPU შეზღუდულია იმ წილზე, რომელიც გეგმამ იყიდა და არა მეზობლებისგან ნასესხებზე, და კონსოლი ვებ სერვერის საკუთარ გამოტანას აჩვენებს, ამიტომ 500 ხილულია support ticket-ის გარეშე. თუ საიტი მეხსიერების ლიმიტს მართლა მიაღწევს, container ჩერდება და სუფთად გადაიტვირთება swap-ში დატოვების ნაცვლად, რაც მოულოდნელია, მაგრამ მანქანას პროგნოზირებადს ინახავს - კიდევ ერთი მიზეზი, worker-ები გეგმას მოარგო და არა ოპტიმიზმს. სერვერის დატვირთვის გრაფიკის კითხვა განმარტავს, რას გეუბნება პანელის მეხსიერებისა და CPU გრაფიკები, სანამ საქმე იქამდე მივა.

FAQ#

რომელი ქეშირების plugin გამოვიყენო?

ნებისმიერი მთავარი, ერთხელ გაწყობილი და მიტოვებული. WP Super Cache და Cache Enabler ყველაზე მარტივია, W3 Total Cache ყველაზე კონფიგურირებადი და ყველაზე ადვილად გასაფუჭებელი, LiteSpeed Cache საუკეთესო არჩევანია მხოლოდ თუ სერვერი ნამდვილად LiteSpeed-ს უშვებს. განსხვავება ორ კარგად გაწყობილ page cache-ს შორის მცირეა; განსხვავება ერთსა და არცერთს შორის უზარმაზარია.

ცვლის CDN page cache-ს?

არა, ისინი განსხვავებულ ნახევრებს წყვეტენ. CDN ბაიტებს ვიზიტორთან აახლოებს და სტატიკურ ფაილებს შესანიშნავად ქეშავს, მაგრამ თუ edge-ზე სრული გვერდის ქეშირებას არ დააყენებ, ის მაინც შენს origin-ს სთხოვს ყოველი HTML გვერდის აგებას. გამოიყენე ორივე: page cache origin-ს იაფს ხდის, CDN მანძილს მოკლეს.

რატომ არის ჩემი საიტი ჩემთვის სწრაფი და ვიზიტორებისთვის ნელი?

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

ღირს object caching Redis-ის გარეშე?

მუდმივი object cache Redis-ის ან Memcached-ის გარეშე არ არსებობს, და ბაზაზე დაფუძნებული შემცვლელები ზოგადად სამუშაოს გადააქვს და არ აქრობს. ძალისხმევა დახარჯე page cache-ზე, autoload-ირებული option-ების შემცირებაზე და plugin-ის მოცილებაზე, რომელიც გვერდზე ორმოც მოთხოვნას უშვებს.

გამოაჩენს თუ არა მეტი RAM ჩემს საიტს უფრო სწრაფს?

მხოლოდ თუ გაკლია. მეტი მეხსიერება მეტ ერთდროულ PHP worker-ს ყიდულობს, ამიტომ ის ზრდის წერტილს, რომლის შემდეგაც საიტი დატვირთვისას ნელდება - ერთი გვერდის გამოსახვას ის უფრო სწრაფს არ ხდის. თუ ერთი ვიზიტორი ნელა იღებს, პასუხებია OPcache, ნაკლები მოთხოვნა და უფრო მსუბუქი თემა.

როგორ ვიპოვო plugin, რომელიც ყველაფერს ანელებს?

დააყენე Query Monitor, ჩატვირთე ნელი გვერდი ადმინისტრატორად შესული და წაიკითხე მოთხოვნების რაოდენობა, ყველაზე ნელი მოთხოვნები და თითო hook-ზე დახარჯული დრო. ის ფაილსა და plugin-ს ასახელებს. ოცი მოთხოვნა გვერდზე ნორმალურია, ორასი plugin-ია, რომელიც ყოველ მოთხოვნაზე რაღაც უგუნურს აკეთებს.