სწრაფი გვერდები, არასწორი თანხმობა

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

ეს სახელმძღვანელო მოიცავს ქეშირების იმ ფენებს, რომლებიც ჩვეულებრივ გამომცემლის საიტის წინ დგას — CDN edge ქეშები, სრული გვერდის ქეშირების პლაგინები, reverse proxy-ები, service worker-ები და თავად ბრაუზერი — და იმას, როგორ შევაჩეროთ თითოეული თანხმობის არასწორი გამოცდილების გაცემისგან.

ძირითადი წესი: თანხმობა გამოიტანეთ ქეშირებული HTML-იდან

ყველაზე უსაფრთხო არქიტექტურა ქეშირებულ HTML გვერდს თანხმობის მიმართ ნეიტრალურად აბრუნებს. გვერდი შეიცავს CMP loader-სა და თქვენს ტეგებს დაბლოკილ ან მოლოდინის მდგომარეობაში, მაგრამ არავითარ გადაწყვეტილებას ამ კონკრეტულ ვიზიტორზე. შემდეგ CMP მუშაობს ბრაუზერში, კითხულობს შენახულ არჩევანს, წყვეტს, აჩვენოს თუ არა ბანერი და შესაბამისად ათავისუფლებს ტეგებს.

პრობლემები იწყება, როცა სერვერი რენდერისას იღებს თანხმობის გადაწყვეტილებებს, მაგალითად:

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

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

რატომ არის “Vary: Cookie” იშვიათად პასუხი

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

გეოგრაფია edge-ზე

ბევრი გამომცემელი რეგიონების მიხედვით სხვადასხვა ბანერს აჩვენებს: opt-in ბანერს ევროკავშირისა და დიდი ბრიტანეთისთვის, opt-out შეტყობინებას აშშ-ის შტატებისთვის და რაიმე უფრო მსუბუქს სხვაგან. თუ სერვერი ვარიანტს ვიზიტორის IP მისამართით ირჩევს და ეს გვერდი დაქეშდება, ევროპელმა მკითხველმა შეიძლება აშშ-ის ქეშირებული გვერდი მიიღოს, ან პირიქით.

ამას სამი შაბლონი თავიდან გვაცილებს:

1. კლიენტის მხარეს გეოლოკაცია. რეგიონი CMP-მ ბრაუზერში განსაზღვროს, რათა ქეშირებული HTML ყველასთვის ერთნაირი დარჩეს.
2. ქვეყანა ქეშის გასაღებში. თუ edge-ზე გადაწყვეტა გჭირდებათ, ქეშის გასაღებში ჩართეთ ქვეყნის კოდი, რომელსაც თქვენი CDN გთავაზობთ. თითო ქვეყანაზე ერთი ქეშირებული ასლი გექნებათ, რაც პროგნოზირებადია.
3. დაუქეშავი edge ლოგიკა. რეგიონული გადაწყვეტილება შეასრულეთ edge ფუნქციაში, რომელიც სხვაგვარად დაქეშილ გვერდში პატარა, დაუქეშავ მნიშვნელობას ათავსებს.

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

თავად CMP სკრიპტის ქეშირება

CMP loader-ის ხანგრძლივად ქეშირება კარგია წარმადობისთვის, მაგრამ ფასი აქვს, როცა კონფიგურაცია იცვლება. თუ ვენდორებს, მიზნებს ან ბანერის ტექსტს განაახლებთ, სკრიპტი ან კონფიგურაციის ფაილი კი ერთი წლით არის დაქეშილი, ზოგი ვიზიტორი ძველ ვერსიას გააგრძელებს ნახვას. გადაამოწმეთ, როგორ აქვს თქვენს CMP-ს ფაილებისთვის ვერსიების მინიჭება: ცვალებადი ფაილის სახელი ან ვერსიის პარამეტრი საშუალებას გაძლევთ აგრესიულად დააქეშოთ და ცვლილებები მაინც მაშინვე გამოუშვათ. ასევე დარწმუნდით, რომ თქვენი CDN მესამე მხარის სკრიპტების URL-ებიდან query string-ებს არ აშორებს, თუ CMP მათზეა დამოკიდებული.

Service worker-ები და ოფლაინ ქეშები

საიტები progressive web app ფენით ხშირად ინახავენ HTML-ს service worker-ში. იგივე წესი მოქმედებს: არასოდეს შეინახოთ გვერდი, რომელიც კონკრეტულ თანხმობის გადაწყვეტილებას ასახავს. თანხმობასთან დაკავშირებული endpoint-ები და პრეფერენციების ცენტრის გვერდები გამორიცხეთ service worker-ის ქეშირებიდან და დარწმუნდით, რომ CMP-ის ახალი კონფიგურაციის მიღება ყოველთვის შესაძლებელია.

Back/forward ქეში

თანამედროვე ბრაუზერები ახლახან ნანახ გვერდებს მეხსიერებაში ინახავენ, რათა უკან ღილაკმა ისინი მყისიერად აღადგინოს. თუ ვიზიტორი ერთ გვერდზე პრეფერენციების ცენტრს გახსნის, თანხმობას გამოითხოვს და შემდეგ უკან დააჭერს, აღდგენილ გვერდზე შესაძლოა მანამდელი ტეგები კვლავ მუშაობდეს. მოუსმინეთ pageshow event-ს და შეამოწმეთ მისი persisted თვისება: როცა გვერდი ამ ქეშიდან აღდგება, ხელახლა წაიკითხეთ შენახული თანხმობის მდგომარეობა და გააჩერეთ ან გაუშვით ტეგები შესაბამისად.

ტესტირების რუტინა

• ჩატვირთეთ გვერდი სუფთა სესიაში, უარყავით, შემდეგ ჩატვირთეთ მეორე გვერდი და დარწმუნდით, რომ არც ერთი თრექინგ ტეგი არ ეშვება.
• გაიმეორეთ მეორე სუფთა ბრაუზერით და დარწმუნდით, რომ ბანერი ჩნდება, რაც ადასტურებს, რომ ის ქეშის გამო არ გამქრალა.
• შეამოწმეთ პასუხის header-ები, რათა ნახოთ, გვერდები ქეშიდან ბრუნდება თუ არა და შეადარეთ HTML თანხმობის ქუქი-ფაილით და მის გარეშე — ის იდენტური უნდა იყოს.
• გატესტეთ მინიმუმ ორი რეგიონიდან ქეშის გასუფთავების შემდეგ და ისევ მას შემდეგ, რაც ქეში გათბება.
• გამოითხოვეთ თანხმობა, გამოიყენეთ უკან ღილაკი და გადაამოწმეთ, რომ ტეგები ჩერდება.

მთავარი დასკვნები

• ქეშირებული HTML თანხმობის მიმართ ნეიტრალური უნდა იყოს; გადაწყვეტილება CMP-მ ბრაუზერში მიიღოს.
• მთელი cookie header-ის მიხედვით განსხვავება მოერიდეთ; ის hit-ის მაჩვენებლებს ანადგურებს.
• თუ ბანერები რეგიონების მიხედვით განსხვავდება, გადაწყვიტეთ კლიენტის მხარეს ან დაამატეთ ქვეყანა ქეშის გასაღებს.
• CMP ფაილებს ვერსიები მიანიჭეთ, რათა ქეშის ხანგრძლივმა ვადებმა კონფიგურაციის ცვლილებები არ დააგვიანოს.
• გაითვალისწინეთ service worker-ები და back/forward ქეში და გატესტეთ გაცხელებული ქეშით და არა მხოლოდ გასუფთავების შემდეგ.