Φλοξενία & απόδοση
Πώς κάνουμε το WordPress γρήγορο: LiteSpeed Enterprise, LSCache και per-site Redis
Το πιο γρήγορο αίτημα WordPress είναι αυτό που δεν εκτελείται ποτέ — δείτε πώς η στοίβα μας εξυπηρετεί τις περισσότερες επισκέψεις από την cache πριν καν κληθεί η PHP ή η MySQL, και τι σημαίνει αυτό για τα Core Web Vitals.
Το πιο γρήγορο αίτημα είναι αυτό που δεν εκτελείται ποτέ
Ένα τυπικό αίτημα WordPress είναι δαπανηρό. Ο διακομιστής ιστού παραδίδει τη σκυτάλη στην PHP, η PHP εκκινεί το WordPress, εκτελεί τα πρόσθετα, υποβάλλει ερωτήματα στο MySQL μερικές δεκάδες φορές, συνθέτει την HTML και μόνο τότε στέλνει πίσω τα bytes. Σε έναν ιστότοπο με μεγάλη κίνηση, όλο αυτός ο χορός επαναλαμβάνεται για κάθε επισκέπτη και εκεί αφιερώνεται σχεδόν ολόκληρος ο χρόνος έως το πρώτο byte.
Η απάντησή μας είναι να διασφαλίσουμε ότι, για τις περισσότερες επισκέψεις, τίποτα από αυτά δεν συμβαίνει. Σε όλους τους ιστότοπους που φιλοξενούμε — πάνω από 100.000 ιστότοπους PBN συν τα κυρίαρχα managed WordPress — η μεγάλη πλειοψηφία των προβολών σελίδας στο front-end εξυπηρετείται ως προ-rendered πλήρης σελίδα απευθείας από την cache, χωρίς να εκτελείται PHP ή να αγγίζεται η βάση δεδομένων. Το υπόλοιπο αυτής της δημοσίευσης αφορά το πώς τα επίπεδα που το καθιστούν αυτό εφικτό συνδέονται μεταξύ τους, και πού κερδίζει το καθένα τη θέση του.
Το σημαντικότερο πλαίσιο είναι ότι δεν πρόκειται για ανταγωνιστικές κaches μεταξύ των οποίων πρέπει να επιλέξετε. Η cache ολόκληρης σελίδας, η cache αντικειμένων και το CDN edge εξυπηρετούν διαφορετικές κατηγορίες αιτημάτων, και η αξία τους βρίσκεται στον τρόπο με τον οποίο συνεργάζονται και διαδέχονται η μία την άλλη.
LiteSpeed Enterprise + LSCache: το επίπεδο πλήρους σελίδας
Κάθε ιστότοπος λειτουργεί σε LiteSpeed Enterprise με LSCache σε επίπεδο διακομιστή. Όταν μια απόκριση front-end είναι δυνατό να αποθηκευτεί σε cache, ο διακομιστής ιστού την επισημαίνει με κεφαλίδες cache-control και tag του LiteSpeed, και το LiteSpeed εξυπηρετεί ολόκληρη τη σελίδα απευθείας στην επόμενη επίσκεψη — χωρίς να εκτελείται διαδικασία PHP και χωρίς να εκδίδεται ερώτημα MySQL. Αυτός είναι ο σημαντικότερος μοχλός για το TTFB του WordPress, επειδή αφαιρεί ολόκληρη την εκκίνηση της εφαρμογής από την κρίσιμη διαδρομή.
Επειδή το LSCache βρίσκεται εντός του διακομιστή ιστού και όχι σε κάποιο πρόσθετο PHP, αρχίζει να λειτουργεί νωρίτερα στον κύκλο ζωής του αιτήματος και διατηρεί τις σελίδες σε μια μορφή που ο διακομιστής μπορεί να αποστείλει άμεσα. Ένα πρόγραμμα ανίχνευσης προσωρινής μνήμης διατηρεί τις δημοφιλείς σελίδες ζεστές, ώστε ο πρώτος επισκέπτης μετά από έναν καθαρισμό να μην είναι αυτός που θα επωμιστεί την αναγέννηση της σελίδας. Το αποτέλεσμα είναι ένα αισθητά χαμηλότερο και πιο συνεπές TTFB σε σύγκριση με μια προσωρινή μνήμη μόνο για πρόσθετα που είναι προσαρτημένη σε ένα γενικό stack, όπου η προσωρινή μνήμη βρίσκεται ακόμα πίσω από την PHP.
Το δικό μας πρόσθετο cache επιπέδου repository διατίθεται προεγκατεστημένο και με αυτόματες ενημερώσεις σε κάθε ιστότοπο, συνδέοντας το WordPress με το LSCache σωστά από την πρώτη στιγμή. Σε έναν origin server που δεν βασίζεται στο LiteSpeed, απλώς δεν εκπέμπει κεφαλίδες πλήρους σελίδας και παραμένει διακριτικό, ενώ η cache αντικειμένων και οι κανόνες εξαίρεσης συνεχίζουν να λειτουργούν — ώστε ένας ιστότοπος που έχει μεταφερθεί να μην μένει ποτέ σε μια ημιτελή και προβληματική κατάσταση.
Παραμονή ταχύτητας χωρίς σερβίσια ληγμένων: ESI και έξυπνη αυτόματη εκκαθάριση
Η επιθετική προσωρινή αποθήκευση ολόκληρης σελίδας έχει δύο κλασικά σημεία αποτυχίας: την εμφάνιση της σελίδας κάποιου άλλου σε έναν συνδεδεμένο χρήστη και την εμφάνιση σε οποιονδήποτε μιας σελίδας που θα έπρεπε να είχε αλλάξει. Και τα δύο επιλύονται στο επίπεδο της προσωρινής αποθήκευσης και όχι με τη μείωση αυτής.
Το ESI (Edge Side Includes) μάς επιτρέπει να κάνουμε προσωisική αποθήκευση (caching) της σελίδας, αφήνοντας κενά για τα τμήματα που πρέπει να παραμένουν ζωντανά. Σε ένα κατάστημα WooCommerce, οι σελίδες καταλόγου, προϊόντων και κατηγοριών σερβίρονται ως προσωρινή μνήμη ολόκληρης σελίδας για το ταχύτερο δυνατό TTFB, ενώ το ESI αποδίδει το θραύσμα του καλαθιού, τα σύνολα του μίνι καλαθιού και την κατάσταση του λογαριασμού ανά αίτημα. Το καλάθι, το ταμείο, ο λογαριασμός μου και τυχόν σελίδες nonce ή συνεδρίας εξαιρούνται από προεπιλογή. Οι αγοραστές βλέπουν πάντα το δικό τους καλάθι και ένα λειτουργικό ταμείο, ενώ όλοι οι υπόλοιποι συνεχίζουν να λαμβάνουν τη βιτρίνα από την προσωρινή μνήμη.
Η ανανέωση διαχειρίζεται μέσω έξυπνης αυτόματης εκκαθάρισης. Οι ενέργειες εκκαθάρισης ενεργοποιούνται αυτόματα όταν αλλάζουν περιεχόμενο, προϊόντα, τιμές ή παραγγελίες, ώστε οι σχετικές προσωρινά αποθηκευμένες σελίδες να ανανεώνονται αμέσως και όχι βάσει χρονοδιακόπτη, ενώ μπορείτε επίσης να κάνετε εκκαθάριση κατ' απαίτηση από τον πίνακα ελέγχου ή μέσα από το WordPress. Η εκκαθάριση βάσει ετικετών σημαίνει ότι η επεξεργασία μίας δημοσίευσης καθαρίζει αυτή τη δημοσίευση και τα αρχεία της —όχι ολόκληρη την προσωρινή μνήμη—, επομένως μια μεμονωμένη επεξεργασία δεν προκαλεί ψυχρή εκκίνηση σε ολόκληρο τον ιστότοπο.
Αντικειμενοστρεφής κρυφής μνήμης Redis ανά ιστότοπο: για ό,τι δεν μπορεί να αποτελέσει ολόκληρη σελίδα
Δεν μπορεί κάθε αίτημα να είναι μια στατική ολόκληρη σελίδα. Οι συνεδρίες συνδεδεμένων χρηστών, το WordPress admin, τα καλάθια WooCommerce, η αναζήτηση και τα δυναμικά τμήματα που αφήνει το ESI ενεργά, πρέπει όλα να εκτελούν PHP. Για αυτά, ο στόχος αλλάζει από «παράκαμψη της εφαρμογής» σε «παράκαμψη της βάσης δεδομένων».
Κάθε ιστότοπος αποκτά τη δική του αποκλειστική μνήμη cache αντικειμένων Redis. Το WordPress αποθηκεύει στη μνήμη τα αποτελέσματα επαναλαμβανόμενων αναγνώσεων της βάσης δεδομένων — επιλογές, transients, αναζητήσεις άρθρων και όρων, δεδομένα προϊόντων και συνεδρίας του WooCommerce — ώστε να μην εκτελείται το ίδιο ερώτημα στη MySQL σε κάθε επίσκεψη. Το αποτέλεσμα είναι πιο ορατό ακριβώς εκεί που η cache ολόκληρης σελίδας δεν μπορεί να βοηθήσει: ταχύτεροι πίνακες ελέγχου, ταχύτερα καλάθια αγορών και σημαντικά χαμηλότερος φόρτος στη βάση δεδομένων υπό την επίδραση επισκεψιμότητας.
Η προσωρινή μνήμη αντικειμένων (object cache) είναι ανά ιστότοπο και δεν κοινοποιείται, γεγονός που έχει σημασία τόσο για την απόδοση όσο και για την απομόνωση. Σε συνδυασμό με τον περιορισμό της βάσης δεδομένων ανά ιστότοπο, τα βαριά ή κακογραμμένα ερωτήματα ενός ιστότοπου δεν μπορούν να στερήσουν τη βάση δεδομένων από τους γείτονές του. Μπορείτε να διαβάσετε περισσότερα σχετικά με το πώς συνδέεται η ρύθμιση πολλαπλών επιπέδων στη σελίδα λειτουργιών προσωρινής μνήμης μας, καθώς και για τα όρια μεταξύ των μισθωτών υπό καθεστώς απομόνωσης.
Το edge και η υποκείμενη μεταφορά
Η προσωN μνήμη που βρίσκεται στον origin πρέπει ακόμα να διασχίσει το δίκτυο. Μπροστά από τον server βρίσκεται το CDN edge, επομένως τα στατικά στοιχεία και οι σελίδες που μπορούν να αποθηκευτούν σε cache εξυπηρετούνται από ένα σημείο παρουσίας κοντά στον επισκέπτη, και ο origin παραμένει ήσυχος ακόμη και υπό φόρτο. Για τη σειρά φιλοξενίας μας footprint-free, το ίδιο edge είναι μια ομάδα πολλαπλών CDN κατανerνημένη σε πολλούς παρόχους, η οποία εξυπηρετεί έναν στόχο footprint καθώς και έναν στόχο απόδοσης. Στο mainstream WordPress είναι απλώς ένα γρήγορο, καλά συμπεριφερόμενο στρώμα που κρατά τους origins σε αδράνεια.
Από κάτω, τα θεμελιώδη δεν είναι ελλιπή. Οι ιστότοποι λειτουργούν σε αποθήκευση NVMe με HTTP/3, οπότε τα byte που όντως στέλνει η προσω S (cache) φτάνουν μέσω μιας σύγχρονης, πολυπλεγμένης μεταφοράς με γρήγορη αποθήκευση πίσω από κάθε αστοχία προσω (cache miss). Κανένα από αυτά τα επίπεδα δεν αποτελεί πρόσθετο: τα LiteSpeed, LSCache, Redis ανά ιστότοπο, NVMe και HTTP/3 αποτελούν τη βάση σε κάθε πρόγραμμα, όχι μια βαθμίδα επιπλέον χρέωσης.
Τι μετακινεί πραγματικά τα Core Web Vitals
Α αξίζει να είμαστε ακριβείς, επειδή η φιλοξενία συχνά υπερπωλείται στα Core Web Vitals. Το TTFB είναι το τμήμα της εξίσωσης που ανήκει στον διακομιστή, και η στοίβα προσωρινής αποθήκευσης από πάνω είναι αυτό που το μειώνει — μια πλήρης σελίδα με προσωρινή αποθήκευση που εξυπηρετείται μέσω HTTP/3 από το edge είναι περίπου όσο χαμηλό γίνεται το TTFB. Επειδή το TTFB είναι η αιχμή του δόρατος του Largest Contentful Paint, μια γρήγορη προέλευση δίνει σε κάθε μετρική προς τα κάτω ένα προβάδισμα που δεν μπορεί να έχει διαφορετικά.
Αλλά τα LCP, CLS και INP καθορίζονται κυρίως στον browser, από την ίδια τη σελίδα: μια μη βελτιστοποιημένη εικόνα hero, CSS και JavaScript που μπλοκάρουν την απόδοση, διάταξη που μετατοπίζεται καθώς φορτώνονται γραμματοσειρές και διαφημίσεις, και βαριά εργασία κύριου νήματος από πρόσθετα. Καμία ποσότητα server caching δεν διορθώνει ένα hero 2 MB ή ένα θέμα που αποστέλλει megabytes JavaScript. Η έντιμη φιλοξενία καθιστά τη συμβολμή του server ουσιαστικά δωρεάν και σταθερή, και στη συνέχεια εναπόκειται στον ιστότοπο να διατηρήσει το front end ελαφρύ.
Αυτός ο καταμερισμός εργασίας είναι το χρήσιμο νοητικό μοντέλο. Εμείς εγγυόμαστε ότι το αίτημα φτάνει γρήγορα στον browser και παραμένει γρήγορο υπό κυκλοφορία· εσείς κρατάτε το payload μικρό και σταθερό. Το σημείο όπου συναντώνται τα δύο —η προθέρμανση της cache, η παράδοση στο edge και η διατήρηση της βάσης δεδομένων σε απόκριση ώστε οι δυναμικές σελίδες να μην κολλάνε— είναι ακριβώς το σημείο όπου το stack μας είναι ρυθμισμένο, και αυτό είναι που κάνει το managed WordPress σε αυτήν την πλατφόρμα πιο γρήγορο από τον ίδιο ιστότοπο σε έναν γενικό πάροχο φιλοξενίας.
Συχνές ερωτήσεις
Χρειάζομαι ακόμα ένα πρόσθετο προσωρινής αποθήκευσης (caching) όπως το WP Rocket;
Όχι. Η προσωρινή αποθήκευση ολόκληρης σελίδας (full-page caching) διαχειρίζεται στον διακομιστή ιστού από το LSCache του LiteSpeed, και το δικό μας πρόσθετο (plugin) προσωρινής αποθήκευσης —προεγκατεστημένο και αυτόματα ενημερωμένο— συνδέει το WordPress σωστά με αυτό, με μια προσωρινή μνήμη αντικειμένων Redis ανά ιστότοπο πίσω από αυτό. Η προσθήκη ενός δεύτερου πρόσθετου προσωρινής αποθήκευσης ολόκληρης σελίδας συνήθως συγκρούεται με την προσωρινή μνήμη σε επίπεδο διακομιστή αντί να βοηθάει, επομένως δεν είναι απαραίτητη ούτε συνιστάται.
Θα χαλάσει η προσωρινή μνήμη (caching) το καλάθι μου στο WooCommerce ή τις σελίδες σύνδεσης;
Το καλάθι, το ταμείο, ο λογαριασμός μου και τυχόν σελίδες nonce ή συνεδρίας εξαιρούνται από την προσωρινή μνήμη από προεπιλογή, ενώ το ESI διατηρεί το τμήμα του καλαθιού και τα σύνολα ενεργά σε σελίδες που διαφορετικά βρίσκονται στην προσωρινή μνήμη. Οι αγοραστές βλέπουν πάντα το δικό τους καλάθι και ένα λειτουργικό ταμείο, ενώ η βιτρίνα του καταστήματος εξακολουθεί να φορτώνεται από την προσωρινή μνήμη.
Πώς παραμένει η cache φρέσκια όταν δημοσιεύω ή επεξεργάζομαι;
Η έξυπνη αυτόματη εκκαθάριση ενεργοποιείται στα σχετικά άγκιστρα (hooks) του WordPress, επομένως η δημοσίευση, η επεξεργασία περιεχομένου ή η αλλαγή ενός προϊόντος, τιμής ή παραγγελίας καθαρίζει μόνο τις επηρεazόμενες σελίδες και τα αρχεία τους —όχι ολόκληρη την προσω Cαριμένη μνήμη— και ένας ανιχνευτής (crawler) τις προθερμαίνει ξανά. Μπορείτε επίσης να κάνετε εκκαθάριση κατ' απαίτηση από τον πίνακα ελέγχου ή μέσα από το WordPress.
Μπορεί η φιλοξενία από μόνη της να μου δώσει τέλεια Core Web Vitals;
Σας προσφέρει τον καλύτερο δυνατό TTFB, ο οποίος αποτελεί το μερίδιο του διακομιστή και ένα προβάδισμα για το Largest Contentful Paint. Αλλά το LCP, το CLS και το INP καθρίζονται σε μεγάλο βαθμό από την ίδια τη σελίδα — τα μεγέθη των εικόνων, τα στοιχεία που εμποδίζουν τη φόρτωση, τη σταθερότητα της διάταξης και την JavaScript κύριου νήματος. Η αρχιτεκτονική μας κάνει τη συμβολπή του διακομιστή γρήγορη και σταθερή· η διατήρηση του front-end φορτίου ελαφριού είναι αυτό που καλύπτει το υπόλοιπο κενό.
Σχετικά
Δοκιμάστε το δωρεάν για 14 ημέρες
Ξεκινήστε τους πρώτους σας ιστότοπους δωρεάν για 14 ημέρες — χωρίς κάρτα. Μεταφέρετε ένα υπάρχον δίκτυο; Η πρώτη σας μετανάστευση είναι δική μας υπόθεση.
Ξεκινήστε δωρεάν