ჰოსტინგი და წარმადობა
როგორ ვაჩქარებთ 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 cache-control და tag ჰედერებს, ხოლო LiteSpeed მომდევნო მოთხოვნისას სრულ გვერდს პირდაპირ აწვდის — PHP პროცესი არ ირთვება, MySQL მოთხოვნა არ იგზავნება. ეს არის ყველაზე ძლიერი ბერკეტი WordPress TTFB-ისთვის, რადგან ის აპლიკაციის მთელ ჩატვირთვას ამოსავალი წერტილიდან გამორიცხავს.
რადგან LSCache ვებ სერვერშია და არა PHP მოდულში, ის მოთხოვნის სასიცოცხლო ციკლში უფრო ადრე იწყებს მუშაობას და გვერდებს ისეთ ფორმატში ინახავს, რომელსაც სერვერი მყისიერად ტვირთავს. ქეშის კრაულერი პოპულარულ გვერდებს აქტიურ მდგომარეობაში ინარჩუნებს, ამიტომ გასუფთავების შემდეგ პირველი სტუმარი არ არის ის, ვინც გვერდის თავიდან გენერაციის საფასურს იხდის. შედეგად, მიიღება შესამჩნევად დაბალი და უფრო სტაბილური TTFB, ვიდრე ზოგად სტეკზე მორგებული მხოლოდ მოდულიანი ქეშის შემთხვევაში, სადაც ქეში კვლავ PHP-ს უკან მდებარეობს.
ჩვენი საკუთრო რეპოს დონის ქეშ პლაგინი წინასწარ დაყენებული და ავტომატურად განახლებადი სახით მოყვება თითოეულ საიტს და WordPress-ს LSCache-თან სწორად აერთებს ყუთიდანვე. არამაიქსის LiteSpeed წარმომავლობის სერვერზე ის უბრალოდ არ გამოასხივებს სრული გვერდის თავსრთვებს და გზიდან იცლება, სანამ ობიექტური ქეში და გამორიცხვის წესები თავის საქმეს აგრძელებენ — ამიტომ მიგრირებული საიტი არასდროს რჩება გაფუჭებულ, ნახევრად კონფიგურირებულ მდგომარეობაში.
სიჩქარის შენარჩუნება ძველი მონაცემების გარეშე: ESI და ჭკვიანი ავტომატური წაშლა
მთლიანი გვერდის აგრესიულ ქეშირებას ორი კლასიკური წარუმატებლობის რეჟიმი აქვს: სისტემაში შესული მომხმარებლისთვის სხვისი გვერდის ჩვენება და ნებისმიერი პირისთვის ისეთი გვერდის ჩვენება, რომელიც შეცვლილი უნდა იყოს. ორივე პრობლემა წყდება ქეშირების ფენაში და არა ნაკლები ქეშირებით.
ESI (Edge Side Includes) საშუალებას გვაძლევს დავაკეშიროთ გვერდი და ამავდროულად დავტოვოთ სივრცეები იმ ნაწილებისთვის, რომლებიც აქტიური უნდა დარჩეს. WooCommerce მაღაზიაში კატალოგის, პროდუქტისა და კატეგორიის გვერდები იტვირთება სრული გვერდის კეშიდან მაქსიმალური TTFB-ს უზრუნველსაყოფად, ხოლო ESI თითოეული მოთხოვნის შესაბამისად ასახავს კალათის ფრაგმენტს, მინი-კალათის ჯამებსა და ანგარიშის მდგომარეობას. კალათა, შეკთხვის გაფორმება, „ჩემი ანგარიში“ და ნებისმიერი nonce ან სესიის გვერდი ნაგულისხმევად გამორიცხულია. მყიდველები მუდმივად ხედავენ საკუთარ კალათასა და მუშა შეკვეთის გაფორმების გვერდს, ხოლო ყველა დანარჩენი მომხმარებელი ვიტრინას კეშიდან იღებს.
სიახლის შენარჩუნებას უზრუნველყოფს ჭკვიანი ავტო-გაწმენდა. გაწმენდის hook-ები ავტომატურად გააქტიურდება შინაარსის, პროდუქტების, ფასების ან შეკვეთების ცვლილებისას, ასე რომ შესაბამისი ქეშირებული გვერდები ტაიმერის მოლოდინის გარეშე, მყისიერად განახლდება; გარდა ამისა, გაწმენდა მოთხოვნისამებრ შეგიძლიათ მართვის პანელიდან ან უშუალოდ WordPress-იდანაც. ჭდეებზე (tag) დაფუძნებული გაწმენდა ნიშნავს იმას, რომ ერთი პოსტის რედაქტირება ასუფთავებს მხოლოდ ამ პოსტსა და მის არქივებს — და არა მთლიან ქეშს — შესაბამისად, ცალკეული ცვლილება მთელ საიტს ხელახლა არ ანელებს.
თითოეული საიტის Redis ობიექტების კეში: იმისთვის, რაც არ შეიძლება იყოს სრული გვერდი
ყველა მოთხოვნა არ შეიძლება იყოს სტატიკური სრული გვერდი. მომხმარებლის აქტიური სესიები, WordPress ადმინისტრაციული პანელი, WooCommerce კალათები, ძიება და დინამიური ფრაგმენტები, რომლებიც ESI-სგან რჩება, ყველაფერი PHP-ზე უნდა გაეშვას. ამ შემთხვევაში, მიზანი იცვლება „აპლიკაციის გამოტოვებიდან“ „მონაცემთა ბაზის გამოტოვებაზე“.
თითოეული საიტი იღებს თავის გამოყოფილ Redis ობიექტების ქეშს. WordPress ინახავს მონაცემთა ბაზის განმეორებითი წაკითხვის შედეგებს — პარამეტრებს, დროებით მონაცემებს (transients), ჩანაწერებისა და ტერმინების ძიებებს, WooCommerce-ის პროდუქტისა და სესიის მონაცემებს — მეხსიერებაში, რათა იგივე მოთხოვნა არ შესრულდეს MySQL-ის მიმართ ყოველ ვიზიტზე. ეფექტი ყველაზე კარგად ჩანს სწორედ იქ, სადაც სრული გვერდის ქეშირება ვერ ეხმარება: უფრო სწრაფი მართვის პანელი, უფრო სწრაფი კალათები და მონაცემთა ბაზის ბევრად დაბალი დატვირთვა ტრაფიკის დროს.
ობიექტების ქეში არის საიტზე ინდივიდუალური და არა საერთო, რაც მნიშვნელოვანია როგორც წარმადობისთვის, ისე იზოლაციისთვის. საიტების მიხედვით მონაცემთა ბაზის შეზღუდვასთან ერთად, ეს უზრუნველყოფს, რომ ერთი საიტის მძიმე ან ცუდად დაწერილი მოთხოვნები სხვებს ბაზის რესურსებს არ უზღუდავდეს. მეტის წაკითხვა იმის შესახებ, თუ როგორ მუშაობს ეს მრავალფენიანი სისტემა, შეგიძლიათ ჩვენი ქეშირების ფუნქციების გვერდზე, ხოლო მოიარეებს შორის საზღვრების შესახებ — იზოლაციის განყოფილებაში.
კიდე და მის ქვეშ მდებარე ტრანსპორტი
წარმოშობის სერვერზე არსებულ ქეშს მაინც უწევს ქსელის გადაკვეთა. სერვერის წინ CDN-ის კიდე (edge) დგას, ამიტომ სტატიკური რესურსები და ქეშირებადი გვერდები ვიზიტორთან ახლოს მდებარე ყოფნის წერტილიდან (POP) მოწოდდება, ხოლო წარმოშობის სერვერი დატვირთვის დროსაც კი უმოქმედოდ რჩება. ჩვენი Footprint-Free ჰოსტინგის ხაზისთვის იგივე კიდე წარმოადგენს მრავალპროვაიდერიან მრავალ-CDN აუზს, რომელიც ემსახურება როგორც საძიებო სისტემის კვალის (footprint) შემცირების, ისე წარმადობის მიზანს; ჩვეულებრივ WordPress-ზე ეს უბრალოდ სწრაფი, კარგი ქცევის მქონე ფენაა, რომელიც ორიგინალ სერვერებს უმოქმედოდ ინარჩუნებს.
სიღრმისეულად, ფუნდამენტური ასპექტები უგულებელყოფილი არ არის. საიტები მუშაობს NVMe მეხსიერებაზე HTTP/3 მხარდაჭერით, ასე რომ ქეშის მიერ გაგზავნილი ბაიტები მიეწოდება თანამედროვე, მულტიპლექსური ტრანსპორტით, ხოლო ქეშის აცდენისას მონაცემები სწრაფი მეხსიერებიდან იტვირთება. არცერთი ეს შრე არ არის დამატებითი ფასიანი ფუნქცია: LiteSpeed, LSCache, თითოეული საიტისთვის განკუთვნილი Redis, NVMe და HTTP/3 არის საბაზისო სტანდარტი თითოეულ ტარიფზე და არა უფრო ძვირი პაკეტის ნაწილი.
რა რეალურად ცვლის Core Web Vitals
ზუსტად ყოფნა ღირს, რადგან ჰოსტინგი ხშირად გადამეტებულად არის შეფასებული Core Web Vitals-ზე. TTFB არის განტოლების ის ნაწილი, რომელსაც სერვერი ფლობს, და მის შემცირებას ზემოთ მდებარე ქეშირების სტეკი განაპირობებს — HTTP/3-ის მეშვეობით edge სერვერიდან მოწოდებული ქეშირებული სრული გვერდი დაახლოებით ისეთივე დაბალია, როგორიც TTFB შეიძლება იყოს. რადგან TTFB არის Largest Contentful Paint-ის საწყისი წერტილი, სწორი წარმოშობა ყველა ქვედა დინების მეტრიკას ისეთ უპირატესობას ანიჭებს, რომელსაც სხვაგვარად ვეღარ მიიღებს.
მაგრამ LCP, CLS და INP ძირითადად ბრაუზერში, თავად გვერდის მიერ წყდება: არაოპტიმიზებული მთავარი სურათი, რენდერის შემზღუდველი CSS და JavaScript, განლაგება, რომელიც შრიფტების და რეკლამების ჩატვირთვისას იცვლება, და პლაგინების მიერ მთავარი ნაკადის (main-thread) მძიმე დატვირთვა. სერვერის არცერთი ქეშირება არ გამოასწორებს 2 მბ-იან სურათს ან თემას, რომელიც მეგაბაიტობით JavaScript-ს აგზავნის. გულწრფელი ჰოსტინგი სერვერის წვლილს ფაქტობრივად უფასოს და სტაბილურს ხდის, შემდეგ კი საიტის პასუხისმგებლობაა, რომ ფრონტ-ენდი მსუბუქი შეინარჩუნოს.
შრომის ეს დანაწილება სასარგებლო გონებრივი მოდელია. ჩვენ გარანტიას ვიძლევით, რომ მოთხოვნა ბრაუზერამდე სწრაფად მივა და ტრაფიკის პირობებშიც სწრაფი დარჩება; თქვენ კი უზრუნველყოფთ, რომ პეილოადი იყოს პატარა და სტაბილური. სწორედ იქ, სადაც ეს ორი ერთმანეთს ხვდება — ქეშის წინასწარი გაცხელება, კიდეების მიწოდება და მონაცემთა ბაზის მგრძნობიარედ შენარჩუნება, რათა დინამიური გვერდები არ შეფერხდეს — ზუსტად იქ არის ჩვენი სტეკი მორგებული და სწორედ ეს აქცევს მართვად WordPress-ს ამ პლატფორმაზე უფრო სწრაფს, ვიდრე იგივე საიტი ზოგად ჰოსტზე.
ხშირად დასმული კითხვები
მე კვლავ მჭირდება ქეშირების პლაგინი, როგორიცაა WP Rocket?
არა. სრული გვერდის ქეშირებას ვებ სერვერის დონეზე უზრუნველყოფს LiteSpeed-ის LSCache, ხოლო ჩვენი საკუთარი ქეშის პლაგინი — წინასწარ დაინსტალირებული და ავტომატურად განახლებადი — სწორად აერთიანებს WordPress-ს მასთან, რომელსაც უკან თითოეული საიტისთვის Redis ობიექტების ქეში უმაგრებს ზურგს. მეორე სრული გვერდის ქეშირების პლაგინის დამატება, როგორც წესი, სერვერის დონის ქეშს უპირისპირდება და არა ეხმარება, ამიტომ ის არც საჭიროა და არც რეკომენდებული.
ქეშირებამ შეიძლება დაარღვიოს WooCommerce კალათა ან ავტორიზებული გვერდები?
არა. კალათა, შეკვეთის გაფორმება, „ჩემი ანგარიში“ და ნებისმიერი nonce ან სესიის გვერდი ნაგულისხმევად გამორიცხულია ქეშირებიდან, ხოლო ESI ინარჩუნებს კალათის ფრაგმენტსა და ჯამებს აქტიურ მდგომარეობაში სხვა მხრივ დაკეშირებულ გვერდებზე. მყიდველები მუდამ ხედავენ საკუთარ კალათას და მოქმედ შეკვეთის გაფორმების გვერდს, მაშინ როცა მაღაზიის ვიტრინა მაინც ქეშიდან იტვირთება.
როგორ ნარჩუნდება ქეში განახლებული პუბლიკაციის ან რედაქტირების დროს?
ჭკვიანი ავტომატური გაწმენდა ირთვება შესაბამის WordPress ჰუკებზე, ამიტომ კონტენტის გამოქვეყნება, რედაქტირება ან პროდუქტის, ფასის ან შეკვეთის შეცვლა ასუფთავებს მხოლოდ შესაბამის გვერდებს და მათ არქივებს — და არა მთელ ქეშს — და მცოცავი რობოტი მათ ხელახლა ათბობს. თქვენ ასევე შეგიძლიათ გაწმენდოთ მოთხოვნის შესაბამისად სამართავი პანელიდან ან WordPress-ის შიგნიდან.
მხოლოდ ჰოსტინგს შეუძლია მომცეს იდეალური Core Web Vitals?
ის უზრუნველყოფს თქვენთვის საუკეთესო შესაძლო TTFB-ს, რომელიც სერვერის წილი და უპირატესობაა Largest Contentful Paint-ისთვის. თუმცა LCP, CLS და INP დიდწილად თავად გვერდის მიერ წყდება — სურათების ზომებით, რენდერის შემაფერხებელი რესურსებით, განლაგების სტაბილურობითა და მთავარი ნაკადის JavaScript-ით. ჩვენი სტეკი სერვერის წვლილს სწრაფსა და სტაბილურს ხდის; დანარჩენი ნაპრალის შესავსებად კი ფრონტენდ-პეილოდის სიმსუბუქის შენარჩუნებაა საჭირო.
დაკავშირებული
სცადეთ უფასოდ 14 დღის განმავლობაში
შექმენით თქვენი პირველი საიტები უფასოდ 14 დღის განმავლობაში — ბარათის გარეშე. გადაიტანთ არსებულ ქსელს? პირველ მიგრაციას ჩვენ ვიღებთ საკუთარ თავზე.
უფასოდ დაწყება