ჰოსტინგი და წარმადობა
როგორ ვხდით WordPress-ს სწრაფს: LiteSpeed Enterprise, LSCache და საიტზე მორგებული Redis
WordPress-ის ყველაზე სწრაფი მოთხოვნა ისაა, რომელიც არასდროს ეშვება — გაეცანით, როგორ პასუხობს ჩვენი სტეკი ვიზიტების უმეტესობას ქეშიდან PHP-ის ან MySQL-ის გამოძახებამდე, და რას ნიშნავს ეს Core Web Vitals-ისთვის.
ყველაზე სწრაფი მოთხოვნა ის არის, რომელიც არასოდეს სრულდება
სტანდარტული WordPress მოთხოვნა რესურსების თვალსაზრისით ძვირადღირებულია. ვებ-სერვერი ამუშავებას გადასცემს PHP-ს, PHP ტვირთავს WordPress-ს, უშვებს პლაგინებს, რამდენიმე ათეულჯერ აგზავნის მოთხოვნას MySQL-ში, აწყობს HTML-ს და მხოლოდ ამის შემდეგ აბრუნებს ბაიტებს უკან. დატვირთულ საიტზე მთელი ეს პროცესი თითოეული ვიზიტორისთვის ხდება და სწორედ აქ იხარჯება თქვენი პირველ ბაიტამდე დროის (time-to-first-byte) თითქმის მთელი ნაწილი.
ჩვენი პასუხია უზრუნველვყოთ, რომ ვიზიტების უმრავლესობისთვის ეს საერთოდ არ მოხდეს. ჩვენ მიერ ჰოსტირებულ საიტებზე — 100 000-ზე მეტი PBN საიტი პლუს ძირითადი მართვადი WordPress — ფრონტენდ გვერდების ნახვების აბსოლუტური უმრავლესობა მიეწოდება როგორც წინასწარ დაგენერირებული სრული გვერდი პირდაპირ ქეშიდან, PHP-ის გამოძახების ან მონაცემთა ბაზასთან შეხების გარეშე. ამ პოსტის დარჩენილი ნაწილი ეხება იმას, თუ როგორ ერწყმის ერთმანეთს ამის განმახორციელებელი შრეები და სად ამართლებს თითოეული მათგანი თავის ადგილს.
მნიშვნელოვანია იმის გათვალისწინება, რომ ეს არ არის კონკურენტი ქეშები, რომელთა შორისაც არჩევანი უნდა გააკეთოთ. მთლიანი გვერდის ქეში, ობიექტების ქეში და CDN edge-ი თითოეული განსხვავებული კატეგორიის მოთხოვნას ამუშავებს, ხოლო მათი რეალური ღირებულება იმაში მდგომარეობს, თუ როგორ გადასცემენ ისინი მონაცემებს ერთმანეთს.
LiteSpeed Enterprise + LSCache: სრული გვერდის ფენა
თითოეული საიტი მუშაობს LiteSpeed Enterprise-ზე სერვერის დონის LSCache-ით. როდესაც front-end პასუხი ექვემდებარება ქეშირებას, ვებ-სერვერი მას ანიჭებს LiteSpeed-ის ქეშის კონტროლისა და ტეგის თავსართებს, ხოლო LiteSpeed სრულ გვერდს პირდაპირ აწვდის შემდეგი მოთხოვნისას — არ ეშვება PHP პროცესი და არ სრულდება MySQL მოთხოვნა. ეს არის ყველაზე დიდი ბერკეტი WordPress-ის TTFB-ისთვის, რადგან ის აპლიკაციის სრულ ჩატვირთვას ხსნის კრიტიკული გზიდან.
ვინაიდან LSCache ფუნქციონირებს ვებ-სერვერის შიგნით და არა PHP-ის პლაგინში, ის მოთხოვნის სასიცოცხლო ციკლის უფრო ადრეულ ეტაპზე იწყებს მუშაობას და გვერდებს ინახავს ისეთი ფორმით, რომლის მყისიერად გასუფთავებაც სერვერს თავისუფლად შეუძლია. ქეშის კროულერი მუდმივად ინარჩუნებს პოპულარულ გვერდებს გააქტიურებულ მდგომარეობაში, რათა გასუფთავების შემდეგ პირველ ვიზიტორს არ მოუწიოს გვერდის ხელახალი გენერირების დროის ხარჯვა. შედეგი არის შესამჩნევად დაბალი და უფრო სტაბილური TTFB, განსხვავებით სტანდარტულ სერვერზე დამატებული მხოლოდ პლაგინის ქეშისგან, სადაც ქეში კვლავ PHP-ის უკან რჩება.
ჩვენი საკუთარი რეპოზიტორიის დონის ქეშის მოდული წინასწარ დაინსტალირებული და ავტომატურად განახლებადია თითოეულ საიტზე, რაც WordPress-ს LSCache-თან პირდაპირ და სწორად აკავშირებს. არა-LiteSpeed სერვერზე ის უბრალოდ არ აგზავნის სრული გვერდის ჰედერებს და ხელს არ უშლის მუშაობას, მაშინ როდესაც ობიექტების ქეში და გამონაკლისების წესები განაგრძობენ ფუნქციონირებას — ამიტომ მიგრირებული საიტი არასდროს რჩება დაზიანებულ, ნახევრად კონფიგურირებულ მდგომარეობაში.
სისწრაფის შენარჩუნება მოძველებული შიგთავსის მიწოდების გარეშე: ESI და გონივრული ავტომატური გასუფთავება
მთლიანი გვერდის აგრესიულ ქეშირებას აქვს ორი კლასიკური შეცდომის რეჟიმი: ავტორიზებული მომხმარებლისთვის სხვისი გვერდის მიწოდება და ნებისმიერი მომხმარებლისთვის ისეთი გვერდის მიწოდება, რომელიც უნდა შეცვლილიყო. ორივე პრობლემა ქეშირების დონეზე წყდება და არა ქეშირების შემცირებით.
ESI (Edge Side Includes) საშუალებას გვაძლევს დავაქეშოთ გვერდი და ამავდროულად გამოვყოთ ის ნაწილები, რომლებიც დინამიკური უნდა დარჩეს. WooCommerce მაღაზიაში კატალოგის, პროდუქტის და კატეგორიის გვერდები მიეწოდება სრული გვერდის ქეშიდან მაქსიმალურად სწრაფი TTFB-ისთვის, ხოლო ESI ახდენს კალათის ფრაგმენტის, მინი-კალათის ჯამის და ანგარიშის სტატუსის რენდერინგს თითოეული მოთხოვნის მიხედვით. კალათა, შეკვეთის გაფორმება, ჩემი ანგარიში და ნებისმიერი nonce ან სესიის გვერდები ნაგულისხმევად გამორიცხულია. მყიდველები ყოველთვის ხედავენ თავიანთ კალათას და მოქმედ შეკვეთის გვერდს; ყველა დანარჩენი კი ვიტრინას კვლავ ქეშიდან იღებს.
სიახლის შენარჩუნებას უზრუნველყოფს ჭკვიანი ავტომატური გაწმენდა. გაწმენდის ჰუკები ავტომატურად აქტიურდება კონტენტის, პროდუქტების, ფასების ან შეკვეთების ცვლილებისას, ამიტომ ქეშირებული შესაბამისი გვერდები განახლდება დაუყოვნებლივ და არა ტაიმერის მიხედვით, ასევე გაწმენდა მოთხოვნისამებრ შეგიძლიათ მართვის პანელიდან ან WordPress-იდან. ტეგებზე დაფუძნებული გაწმენდა ნიშნავს, რომ ერთი პოსტის რედაქტირება ასუფთავებს მხოლოდ ამ პოსტსა და მის არქივებს — და არა მთელ ქეშს — შესაბამისად, ერთი რედაქტირება არ იწვევს მთელი საიტის ცივ ჩატვირთვას (cold-start).
Redis-ის ობიექტების ქეში თითოეული საიტისთვის: იმისთვის, რაც არ შეიძლება იყოს სრული გვერდი
ყველა მოთხოვნა არ შეიძლება იყოს სტატიკური სრული გვერდი. ავტორიზებულ სესიებს, WordPress-ის ადმინისტრატორს, WooCommerce-ის კალათებს, ძიებას და დინამიკურ ფრაგმენტებს, რომლებსაც ESI აქტიურს ტოვებს, ყველას სჭირდება PHP-ის გაშვება. მათთვის მიზანი გადადის „აპლიკაციის გამოტოვებიდან“ „მონაცემთა ბაზის გამოტოვებაზე“.
თითოეული საიტი იღებს თავის გამოყოფილ Redis-ის ობიექტების ქეშს. WordPress ინახავს მონაცემთა ბაზიდან განმეორებადი წაკითხვის შედეგებს — პარამეტრებს, transient-ებს, პოსტებისა და ტერმინების ძიებებს, WooCommerce-ის პროდუქტებისა და სესიების მონაცემებს — მეხსიერებაში, რათა ყოველი მოთხოვნისას ერთი და იგივე მოთხოვნა არ შესრულდეს MySQL-ში. ეფექტი ყველაზე მეტად შეიმჩნევა სწორედ იქ, სადაც მთლიანი გვერდის ქეშირება ვერ გვეხმარება: უფრო სწრაფი სამართავი პანელები, უფრო სწრაფი კალათები და მონაცემთა ბაზის ბევრად დაბალი დატვირთვა მაღალი ტრაფიკის დროს.
ობიექტების ქეში არის თითოეულ საიტზე ინდივიდუალური და არა გაზიარებული, რაც მნიშვნელოვანია როგორც წარმადობისთვის, ასევე იზოლაციისთვის. საიტზე ინდივიდუალურ მონაცემთა ბაზის რეგულირებასთან (throttling) ერთად, ერთი საიტის მძიმე ან ცუდად დაწერილ მოთხოვნებს არ შეუძლია მონაცემთა ბაზის რესურსების ამოწურვა მეზობელი საიტებისთვის. თქვენ შეგიძლიათ გაიგოთ მეტი იმის შესახებ, თუ როგორ მუშაობს ეს მრავალშრიანი სისტემა ერთად ჩვენს ქეშირების ფუნქციების გვერდზე, ასევე გაეცნოთ მდგმურებს (tenants) შორის არსებულ საზღვრებს იზოლაციის განყოფილებაში.
ნაპირი და მის ქვეშ არსებული ტრანსპორტი
ძირითად სერვერზე (origin) არსებულ ქეშს მაინც უწევს ქსელის გავლა. სერვერის წინ განთავსებულია CDN edge, ამიტომ სტატიკური რესურსების და დაქეშვადი გვერდების მიწოდება ხდება ვიზიტორთან ახლოს მდებარე ყოფნის წერტილიდან (point of presence), ხოლო ძირითადი სერვერი დატვირთვის დროსაც კი უმოქმედო რჩება. ჩვენი footprint-free ჰოსტინგის ხაზისთვის იგივე edge წარმოადგენს multi-CDN პულს, რომელიც განაწილებულია რამდენიმე პროვაიდერზე და ემსახურება როგორც footprint-ის, ასევე წარმადობის მიზნებს; სტანდარტულ WordPress-ზე კი ეს არის უბრალოდ სწრაფი, გამართული შრე, რომელიც ძირითად სერვერებს უქმად ამყოფებს.
საფუძვლებზე კომპრომისი არ გაკეთებულა. საიტები მუშაობს NVMe მეხსიერებაზე HTTP/3 მხარდაჭერით, ამიტომ ქეშის მიერ გაგზავნილი ბაიტები თანამედროვე, მულტიპლექსირებული ტრანსპორტით მიეწოდება, ხოლო ნებისმიერი ქეშის აცდენის (cache miss) უკან სწრაფი საცავია. ამ შრეებიდან არცერთი არ წარმოადგენს ფასიან დანამატს: LiteSpeed, LSCache, ცალკეული საიტის Redis, NVMe და HTTP/3 თითოეული გეგმის ძირითადი სტანდარტია და არა დამატებითი გაყიდვის დონე.
რა ახდენს რეალურ გავლენას Core Web Vitals-ზე
სიზუსტე მნიშვნელოვანია, რადგან ჰოსტინგი ხშირად ზედმეტად გადაჭარბებულად იყიდება Core Web Vitals-თან მიმართებით. TTFB არის ფორმულის ის ნაწილი, რომელზეც სერვერია პასუხისმგებელი, ხოლო ზემოთ აღნიშნული ქეშირების სტეკი არის ის, რაც მას ამცირებს — edge-იდან HTTP/3-ის მეშვეობით მიწოდებული სრული დაქეშირებული გვერდი თითქმის ყველაზე დაბალი მაჩვენებელია, რასაც TTFB-მ შეიძლება მიაღწიოს. რადგან TTFB წარმოადგენს Largest Contentful Paint-ის საწყის ეტაპს, სწრაფი საწყისი წერტილი (origin) ყველა მომდევნო მეტრიკას აძლევს ისეთ სტარტს, რასაც სხვაგვარად ვერ მიიღებდა.
თუმცა LCP, CLS და INP უმეტესწილად ბრაუზერში, თავად გვერდის მიერ წყდება: არაოპტიმიზებული hero სურათი, რენდერის დამბლოკავი CSS და JavaScript, შრიფტებისა და რეკლამების ჩატვირთვისას წანაცვლებული განლაგება და მოდულების მიერ ძირითადი ნაკადის მძიმე დატვირთვა. სერვერის ქეშირების ვერანაირი რაოდენობა ვერ გამოასწორებს 2 მბ-იან hero სურათს ან თემას, რომელსაც მეგაბაიტობით JavaScript გადააქვს. პატიოსანი ჰოსტინგი სერვერის წვლილს ფაქტობრივად უფასოსა და სტაბილურს ხდის, შემდეგ კი უკვე საიტის ამოცანაა, შეინარჩუნოს ფრონტენდი მსუბუქ მდგომარეობაში.
შრომის ეს განაწილება სასარგებლო მენტალური მოდელია. ჩვენ გარანტიას გაძლევთ, რომ მოთხოვნა ბრაუზერამდე სწრაფად მიაღწევს და მაღალი ტრაფიკის დროსაც სწრაფი დარჩება; თქვენ უზრუნველყოფთ მონაცემთა მოცულობის სიმცირესა და სტაბილურობას. ადგილი, სადაც ეს ორი ერთმანეთს ემთხვევა — ქეშის გახურება (cache warm-up), edge მიწოდება და მონაცემთა ბაზის მგრძნობელობის შენარჩუნება, რათა დინამიკური გვერდები არ შეფერხდეს — სწორედ ის არეალია, რომელზეც ჩვენი სტეკია მორგებული, და სწორედ ეს ხდის მართულ WordPress-ს ამ პლატფორმაზე უფრო სწრაფს, ვიდრე იგივე საიტი იქნებოდა სტანდარტულ ჰოსტინგზე.
ხშირად დასმული კითხვები
მჭირდება თუ არა ისევ ქეშირების მოდული, როგორიცაა WP Rocket?
არა. გვერდის სრული ქეშირება ხორციელდება ვებ-სერვერის დონეზე LiteSpeed-ის LSCache-ის მიერ, ხოლო ჩვენი საკუთარი ქეშის მოდული — წინასწარ დაინსტალირებული და ავტომატურად განახლებადი — სწორად აკავშირებს WordPress-ს მასთან, რასაც თან ახლავს თითოეული საიტისთვის განკუთვნილი Redis ობიექტების ქეში. მეორე სრული გვერდის ქეშირების მოდულის დამატება, როგორც წესი, ეწინააღმდეგება სერვერის დონის ქეშს და არ ეხმარება მას, ამიტომ ეს არ არის საჭირო და არ არის რეკომენდებული.
დააზიანებს თუ არა ქეშირება ჩემს WooCommerce კალათას ან შესული მომხმარებლის გვერდებს?
არა. კალათა, ანგარიშსწორება, my-account და ნებისმიერი nonce ან სესიის გვერდები ნაგულისხმევად გამორიცხულია ქეშიდან, ხოლო ESI ინარჩუნებს კალათის ფრაგმენტსა და ჯამებს რეალურ დროში სხვაგვარად ქეშირებულ გვერდებზე. მყიდველები ყოველთვის ხედავენ თავიანთ კალათას და მოქმედ ანგარიშსწორებას, სანამ მაღაზიის ვიტრინა კვლავ ქეშიდან იტვირთება.
როგორ რჩება ქეში განახლებული, როდესაც ვაქვეყნებ ან ვარედაქტირებ?
ჭკვიანი ავტომატური გასუფთავება ამოქმედდება შესაბამის WordPress ჰუკებზე, ამიტომ გამოქვეყნება, შინაარსის რედაქტირება ან პროდუქტის, ფასის ან შეკვეთის შეცვლა ასუფთავებს მხოლოდ დაზარალებულ გვერდებსა და მათ არქივებს — და არა მთელ ქეშს — და რობოტი მათ კვლავ ათბობს. თქვენ ასევე შეგიძლიათ განახორციელოთ გასუფთავება მოთხოვნისამებრ მართვის პანელიდან ან WordPress-ის შიგნიდან.
შეუძლია თუ არა მხოლოდ ჰოსტინგს მომცეს სრულყოფილი Core Web Vitals?
ეს გაძლევთ საუკეთესო შესაძლო TTFB-ს, რაც წარმოადგენს სერვერის წილს და წინსწრებას Largest Contentful Paint-ისთვის. თუმცა LCP, CLS და INP დიდწილად თავად გვერდით განისაზღვრება — სურათების ზომებით, რენდერის დამბლოკავი რესურსებით, განლაგების სტაბილურობითა და მთავარი ნაკადის JavaScript-ით. ჩვენი სტეკი სერვერის წვლილს სწრაფსა და თანმიმდევრულს ხდის; დარჩენილი სხვაობის ამოვსება კი ფრონტენდის მონაცემთა მოცულობის სიმცირის შენარჩუნებაზეა დამოკიდებული.
დაკავშირებული
სცადეთ უფასოდ 14 დღის განმავლობაში
გაუშვით თქვენი პირველი საიტები უფასოდ 14 დღის განმავლობაში — ბარათის გარეშე. გადაგაქვთ არსებული ქსელი? მიგრაცია უფასოა, ყოველგვარი შეზღუდვის გარეშე.
დაიწყეთ უფასოდ