Σήμερα, το WordPress εξουσιάζει πάνω από το 30% του Διαδικτύου . Είναι εύκολο στη χρήση, εξαιρετικά δημοφιλές και δεν πηγαίνει πουθενά σύντομα.

Αλλά το WordPress μπορεί να είναι αργό. Λοιπόν, πώς το βελτιστοποιείτε;

Υπάρχουν πολλά άρθρα σχετικά με τον τρόπο συντονισμού και βελτιστοποίησης του WordPress. Στην πραγματικότητα, το ίδιο το WordPress παρέχει ένα στιβαρός οδηγός στη βελτιστοποίηση του WordPress.

Ως επί το πλείστον, αυτά τα άρθρα και τα σεμινάρια καλύπτουν αρκετά βασικές αλλά χρήσιμες έννοιες, όπως η χρήση προσθηκών cache, η ενσωμάτωση με δίκτυα παράδοσης περιεχομένου (CDN) και η ελαχιστοποίηση αιτημάτων. Ενώ αυτές οι συμβουλές είναι πολύ αποτελεσματικές και ακόμη απαραίτητες, στο τέλος, δεν αντιμετωπίζουν το υποκείμενο πρόβλημα: Οι περισσότεροι αργοί ιστότοποι WordPress είναι αποτέλεσμα κακού ή αναποτελεσματικού κώδικα.

Το WordPress μπορεί να είναι αργό, αλλά δεν πρέπει να είναι. Τιτίβισμα

Επομένως, αυτό το άρθρο στοχεύει κυρίως στην παροχή προγραμματιστών και Εταιρίες ανάπτυξης WordPress με ορισμένες οδηγίες που μπορούν να τους βοηθήσουν να αντιμετωπίσουν τις υποκείμενες αιτίες πολλών ζητημάτων απόδοσης του WordPress.

Το WordPress παρέχει πολλές λειτουργίες προσανατολισμένες στην απόδοση που συχνά παραβλέπονται από προγραμματιστές. Ο κώδικας που δεν αξιοποιεί αυτές τις λειτουργίες μπορεί να επιβραδύνει τις πιο απλές εργασίες, όπως ανάκτηση αναρτήσεων. Αυτό το άρθρο περιγράφει τέσσερις πιθανές λύσεις, οι οποίες αντιμετωπίζουν ορισμένα από τα βασικά προβλήματα πίσω από την αργή απόδοση του WordPress.

Λήψη αναρτήσεων

Το WordPress προσφέρει τη δυνατότητα ανάκτησης κάθε είδους ανάρτησης από τη βάση δεδομένων. Υπάρχουν τρεις βασικοί τρόποι για να το κάνετε αυτό:

• Χρήση του query_posts() λειτουργία: Αυτή είναι μια πολύ άμεση προσέγγιση, αλλά το πρόβλημα είναι ότι υπερισχύει του βασικού ερώτηση , που θα μπορούσε να οδηγήσει σε ταλαιπωρία. Για παράδειγμα, αυτό θα μπορούσε να είναι ένα ζήτημα εάν θέλαμε να προσδιορίσουμε, κάποια στιγμή μετά την ανάκτηση των αναρτήσεων (όπως μέσα footer.php), τι είδους σελίδα αντιμετωπίζουμε. Στην πραγματικότητα, η επίσημη τεκμηρίωση έχει μια σημείωση που συνιστά να μην χρησιμοποιηθεί αυτή η λειτουργία, καθώς θα χρειαστεί να καλέσετε μια πρόσθετη συνάρτηση για να επαναφέρετε το αρχικό ερώτημα. Επιπλέον, η αντικατάσταση του κύριου ερωτήματος θα επηρεάσει αρνητικά τους χρόνους φόρτωσης της σελίδας.

• Χρήση του get_posts() λειτουργία: Αυτό λειτουργεί σχεδόν σαν query_posts(), αλλά δεν τροποποιεί το κύριο ερώτημα. Από την άλλη πλευρά, get_posts() από προεπιλογή εκτελεί το ερώτημα με το suppress_filters η παράμετρος ορίστηκε σε true. Αυτό θα μπορούσε να οδηγήσει σε ασυνέπειες, ειδικά εάν χρησιμοποιούμε φίλτρα που σχετίζονται με ερωτήματα στον κώδικά μας, καθώς οι αναρτήσεις που δεν περιμένετε σε μια σελίδα ενδέχεται να επιστραφούν από αυτήν τη λειτουργία.

  
  
  

• Χρήση του WP_Query τάξη: Κατά τη γνώμη μου, αυτός είναι ο καλύτερος τρόπος για να ανακτήσετε δημοσιεύσεις από τη βάση δεδομένων. Δεν αλλάζει το κύριο ερώτημα και εκτελείται με τον τυπικό τρόπο, όπως και κάθε άλλο ερώτημα WordPress.

Όποια μέθοδο κι αν χρησιμοποιούμε για να αλληλεπιδράσουμε με τη βάση δεδομένων, υπάρχουν και άλλα πράγματα που πρέπει να λάβουμε υπόψη.

Περιορισμός του ερωτήματος

Πρέπει πάντα να καθορίζουμε πόσες αναρτήσεις πρέπει να ανακτήσει το ερώτημά μας.

Για να το πετύχουμε αυτό, χρησιμοποιούμε το posts_per_page παράμετρος.

Το WordPress μας επιτρέπει να δείξουμε -1 ως πιθανή τιμή για αυτήν την παράμετρο, οπότε το σύστημα θα προσπαθήσει να πάρει όλες τις αναρτήσεις που πληρούν τις καθορισμένες συνθήκες.

Αυτή δεν είναι καλή πρακτική, ακόμα κι αν είμαστε σίγουροι ότι θα λάβουμε μόνο μερικά αποτελέσματα ως απάντηση.

πώς να εκτελέσετε τη δοκιμή μονάδας

Πρώτον, σπάνια μπορούμε να είμαστε σίγουροι για τη λήψη μόνο μερικών αποτελεσμάτων. Και ακόμη κι αν μπορούμε, ο καθορισμός ορίου δεν θα απαιτήσει από τη μηχανή βάσης δεδομένων να σαρώσει ολόκληρη τη βάση δεδομένων αναζητώντας αγώνες.

Αντίθετα, ο περιορισμός των αποτελεσμάτων επιτρέπει συχνά στη μηχανή βάσης δεδομένων να σαρώνει εν μέρει μόνο τα δεδομένα, γεγονός που μεταφράζεται σε λιγότερο χρόνο επεξεργασίας και ταχύτερη απόκριση.

Ένα άλλο πράγμα που κάνει το WordPress από προεπιλογή, το οποίο μπορεί να επηρεάσει αρνητικά την απόδοση, είναι ότι προσπαθεί να φέρει κολλώδεις αναρτήσεις και να υπολογίσει πόσες σειρές βρέθηκαν στο ερώτημα.

Συχνά, ωστόσο, δεν χρειαζόμαστε πραγματικά αυτές τις πληροφορίες. Η προσθήκη αυτών των δύο παραμέτρων θα απενεργοποιήσει αυτές τις δυνατότητες και θα επιταχύνει το ερώτημά μας:

$query = new WP_Query( array( 'ignore_sticky_posts' => true, 'no_found_rows' => true ) );

Εξαίρεση αναρτήσεων από το ερώτημα

Μερικές φορές θέλουμε να εξαιρέσουμε ορισμένες αναρτήσεις από το ερώτημα. Το WordPress προσφέρει έναν πολύ άμεσο τρόπο επίτευξής του: χρησιμοποιώντας το post__not_in παράμετρος. Για παράδειγμα:

$posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page, 'post__not_in' => $posts_to_exclude ) ); for ( $i = 0; $i posts ); $i++ ) { //do stuff with $query->posts[ $i ] }

Όμως, ενώ αυτό είναι αρκετά απλό, δεν είναι βέλτιστο γιατί εσωτερικά δημιουργεί ένα ερώτημα. Ειδικά σε μεγάλες εγκαταστάσεις, αυτό μπορεί να οδηγήσει σε αργές αποκρίσεις. Είναι πιο γρήγορο να αφήσετε την επεξεργασία να γίνει από τον διερμηνέα PHP με μερικές απλές τροποποιήσεις:

$posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page + count( $posts_to_exclude ) ) ); for ( $i = 0; $i posts ) && $i posts[ $i ]->ID, $posts_to_exclude ) ) { //do stuff with $query->posts[ $i ] } }

Τι έκανα εκεί;

Βασικά, έβγαλα κάποια δουλειά από τη μηχανή βάσης δεδομένων και το άφησα αντί για τον κινητήρα PHP, ο οποίος κάνει τα ίδια πράγματα αλλά στη μνήμη, που είναι πολύ πιο γρήγορος.

Πως?

Πρώτα, κατάργησα το post__not_in παράμετρος από το ερώτημα.

Επειδή το ερώτημα μπορεί να μας φέρει κάποιες αναρτήσεις που δεν θέλουμε ως αποτέλεσμα, αύξησα το posts_per_page παράμετρος. Με αυτόν τον τρόπο διασφαλίζω ότι, ακόμη και αν είχα κάποιες ανεπιθύμητες θέσεις στην απάντησή μου, θα είχα τουλάχιστον $posts_per_page επιθυμητές θέσεις εκεί.

Στη συνέχεια, όταν κάνω βρόχο στις αναρτήσεις, επεξεργάζομαι μόνο εκείνες που δεν βρίσκονται μέσα στο $posts_to_exclude πίνακας.

Αποφυγή σύνθετων παραμέτρων

Ολα αυτά μεθόδους ερωτήματος Προσφέρετε μια μεγάλη ποικιλία δυνατοτήτων για ανάκτηση αναρτήσεων: ανά κατηγορίες, ανά μετα-κλειδιά ή τιμές, κατά ημερομηνία, ανά συγγραφέα κ.λπ.

Και ενώ αυτή η ευελιξία είναι ένα ισχυρό χαρακτηριστικό, θα πρέπει να χρησιμοποιείται με προσοχή, διότι αυτή η παραμετροποίηση θα μπορούσε να μεταφραστεί σε σύνθετες συνδέσεις πίνακα και δαπανηρές λειτουργίες βάσης δεδομένων.

Στην επόμενη ενότητα, θα παρουσιάσουμε έναν κομψό τρόπο για να επιτύχουμε ακόμα παρόμοια λειτουργικότητα χωρίς να διακυβεύουμε την απόδοση.

Συμπίεση των περισσότερων από τις επιλογές του WordPress

ο API επιλογών WordPress παρέχει μια σειρά εργαλείων για εύκολη φόρτωση ή αποθήκευση δεδομένων. Είναι χρήσιμο για τον χειρισμό μικρών πληροφοριών, για τους οποίους άλλοι μηχανισμοί που προσφέρει το WordPress (όπως δημοσιεύσεις ή ταξινομίες) είναι υπερβολικά περίπλοκοι.

Για παράδειγμα, εάν θέλουμε να αποθηκεύσουμε ένα κλειδί ελέγχου ταυτότητας ή το χρώμα φόντου της κεφαλίδας του ιστότοπού μας, οι επιλογές είναι αυτές που αναζητούμε.

Το WordPress δεν μας δίνει μόνο τις λειτουργίες για τον χειρισμό τους, αλλά μας επιτρέπει επίσης να το κάνουμε με τον πιο αποτελεσματικό τρόπο.

Ορισμένες από τις επιλογές φορτώνονται ακόμη και απευθείας όταν το ξεκινά το σύστημα , παρέχοντας έτσι ταχύτερη πρόσβαση (κατά τη δημιουργία μιας νέας επιλογής, πρέπει να εξετάσουμε εάν θέλουμε να την φορτώσουμε αυτόματα ή όχι).

Εξετάστε, για παράδειγμα, έναν ιστότοπο στον οποίο έχουμε ένα καρουζέλ που εμφανίζει έκτακτα νέα που αναφέρονται στο παρασκήνιο. Το πρώτο μας ένστικτο θα ήταν να χρησιμοποιήσουμε ένα μετα-κλειδί για αυτό ως εξής:

// functions.php add_action( 'save_post', function ( $post_id ) { // For simplicity, we do not include all the required validation before saving // the meta key: checking nonces, checking post type and status, checking // it is not a revision or an autosaving, etc. update_post_meta( $post_id, 'is_breaking_news', ! empty ( $_POST['is_breaking_news'] ) ); } ); // front-page.php $query = new WP_Query( array( 'posts_per_page' => 1, 'meta_key' => 'is_breaking_news' ) ); $breaking_news = $query->posts[0] ?: NULL;

Όπως μπορείτε να δείτε, αυτή η προσέγγιση είναι πολύ απλή, αλλά δεν είναι η βέλτιστη. Θα εκτελέσει ένα ερώτημα βάσης δεδομένων προσπαθώντας να βρει μια ανάρτηση με ένα συγκεκριμένο μετα-κλειδί. Θα μπορούσαμε να χρησιμοποιήσουμε μια επιλογή για να επιτύχουμε ένα παρόμοιο αποτέλεσμα:

// functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation if ( ! empty ( $_POST['is_breaking_news'] ) ) update_option( 'breaking_news_id', $post_id ); } ); // front-page.php if ( $breaking_news_id = get_option( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Η λειτουργικότητα διαφέρει ελαφρώς από το ένα παράδειγμα στο άλλο.

Στο πρώτο κομμάτι του κώδικα, θα λαμβάνουμε πάντα τις τελευταίες ειδήσεις, όσον αφορά την ημερομηνία δημοσίευσης της ανάρτησης.

Στη δεύτερη, κάθε φορά που μια νέα ανάρτηση ορίζεται ως έκτακτη είδηση, αντικαθιστά τις προηγούμενες ειδήσεις.

Αλλά επειδή πιθανότατα θέλουμε ένα σπάσιμο ειδήσεων κάθε φορά, δεν θα πρέπει να είναι πρόβλημα.

Και, στο τέλος, αλλάξαμε ένα βαρύ ερώτημα βάσης δεδομένων (χρησιμοποιώντας WP_Query με μετα-κλειδιά) σε ένα απλό και άμεσο ερώτημα (κλήση get_post()) που είναι μια καλύτερη και πιο αποτελεσματική προσέγγιση.

Θα μπορούσαμε επίσης να κάνουμε μια μικρή αλλαγή και να χρησιμοποιήσουμε μεταβατικά αντί για επιλογές.

Τα μεταβατικά λειτουργούν παρόμοια, αλλά μας επιτρέπουν να καθορίσουμε μια ώρα λήξης.

Για παράδειγμα, για τις ειδήσεις, ταιριάζει σαν ένα γάντι επειδή δεν θέλουμε μια παλιά ανάρτηση ως νέα, και αν αφήσουμε το έργο της αλλαγής ή της εξάλειψης αυτών των ειδήσεων στον διαχειριστή, θα μπορούσε να ξεχάσει να κάνει το. Έτσι, με δύο απλές αλλαγές, προσθέτουμε μια ημερομηνία λήξης:

// functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation // Let's say we want that breaking news for one hour // (3600 = # of seconds in an hour). if ( ! empty ( $_POST['is_breaking_news'] ) ) set_transient( 'breaking_news_id', $post_id, 3600 ); } ); // front-page.php if ( $breaking_news_id = get_transient( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Ενεργοποίηση επίμονης προσωρινής αποθήκευσης

Το WordPress έχει εγγενώς ένα μηχανισμός προσωρινής αποθήκευσης αντικειμένων .

Οι επιλογές, για παράδειγμα, αποθηκεύονται στην κρυφή μνήμη χρησιμοποιώντας αυτόν τον μηχανισμό.

Ωστόσο, από προεπιλογή, αυτή η προσωρινή αποθήκευση δεν είναι επίμονη, που σημαίνει ότι ζει μόνο για τη διάρκεια ενός μεμονωμένου αιτήματος. Όλα τα δεδομένα αποθηκεύονται προσωρινά στη μνήμη, για ταχύτερη πρόσβαση, αλλά είναι διαθέσιμα μόνο κατά τη διάρκεια αυτού του αιτήματος.

Η υποστήριξη της μόνιμης προσωρινής αποθήκευσης απαιτεί την εγκατάσταση μίας μόνιμης προσθήκης προσωρινής μνήμης.

Ορισμένες προσθήκες cache πλήρους σελίδας συνοδεύονται από μια μόνιμη προσθήκη cache (για παράδειγμα W3 Total Cache), αλλά άλλες όχι και πρέπει να την εγκαταστήσουμε ξεχωριστά.

Θα εξαρτηθεί από την αρχιτεκτονική της πλατφόρμας μας, αν θα χρησιμοποιήσουμε αρχεία, Memcached ή κάποιον άλλο μηχανισμό για την αποθήκευση δεδομένων που έχουν αποθηκευτεί στην κρυφή μνήμη, αλλά θα πρέπει να εκμεταλλευτούμε αυτήν την εκπληκτική δυνατότητα.

Κάποιος μπορεί να ρωτήσει: 'Εάν αυτό είναι τόσο εξαιρετικό χαρακτηριστικό, γιατί το WordPress δεν το επιτρέπει από προεπιλογή';

Ο κύριος λόγος είναι ότι, ανάλογα με την αρχιτεκτονική της πλατφόρμας μας, ορισμένες τεχνικές προσωρινής αποθήκευσης θα λειτουργήσουν και άλλες όχι.

Εάν φιλοξενούμε τον ιστότοπό μας στον κατανεμημένο διακομιστή μας, για παράδειγμα, θα πρέπει να χρησιμοποιήσουμε ένα εξωτερικό σύστημα προσωρινής μνήμης (όπως ένα Απομνημόνευση διακομιστή), αλλά εάν ο ιστότοπός μας βρίσκεται σε έναν μόνο διακομιστή, θα μπορούσαμε να εξοικονομήσουμε χρήματα χρησιμοποιώντας απλώς το σύστημα αρχείων για την προσωρινή αποθήκευση.

Ένα πράγμα που πρέπει να λάβουμε υπόψη είναι η λήξη της προσωρινής μνήμης. Αυτή είναι η πιο κοινή παγίδα εργασίας με επίμονη προσωρινή αποθήκευση.

Εάν δεν αντιμετωπίσουμε σωστά αυτό το ζήτημα, οι χρήστες μας θα παραπονεθούν ότι δεν θα δουν τις αλλαγές που έχουν κάνει ή ότι οι αλλαγές τους χρειάστηκαν πολύ χρόνο για να εφαρμοστούν.

Μερικές φορές θα βρεθούμε να κάνουμε ανταλλαγές μεταξύ της απόδοσης και του δυναμισμού, αλλά ακόμη και με αυτά τα εμπόδια, η επίμονη προσωρινή αποθήκευση είναι κάτι που ουσιαστικά πρέπει να εκμεταλλευτεί κάθε εγκατάσταση του WordPress.

AJAXing ο γρηγορότερος τρόπος

Εάν πρέπει να επικοινωνήσουμε μέσω AJAX με τον ιστότοπό μας, το WordPress προσφέρει κάποια αφαίρεση κατά τη στιγμή της επεξεργασίας του αιτήματος από την πλευρά του διακομιστή.

Ακόμα κι αν αυτές οι τεχνικές μπορούν να χρησιμοποιηθούν κατά τον προγραμματισμό εργαλείων back-end ή φόρμα υποβολών από το front-end, θα πρέπει να αποφεύγονται εάν δεν είναι απολύτως απαραίτητο.

Ο λόγος για αυτό είναι ότι για να χρησιμοποιήσουμε αυτούς τους μηχανισμούς, είμαστε υποχρεωμένοι να υποβάλουμε ένα αίτημα ανάρτησης σε κάποιο αρχείο που βρίσκεται μέσα στο wp-admin ντοσιέ. Η πλειονότητα (αν όχι όλων) των προσθηκών προσωρινής αποθήκευσης του WordPress σε ολόκληρη τη σελίδα ούτε προσωρινά αποθηκεύει αιτήματα ούτε κλήσεις σε αρχεία διαχειριστή.

Για παράδειγμα, εάν φορτώνουμε δυναμικά περισσότερες αναρτήσεις όταν ο χρήστης κάνει κύλιση στην αρχική μας σελίδα, θα ήταν καλύτερα να καλέσετε απευθείας σε κάποια άλλη σελίδα πρώτης σελίδας, η οποία θα αποκομίσει τα οφέλη της προσωρινής αποθήκευσης.

Στη συνέχεια θα μπορούσαμε να αναλύσουμε τα αποτελέσματα μέσω JavaScript στο πρόγραμμα περιήγησης.

Ναι, στέλνουμε περισσότερα δεδομένα από ό, τι χρειαζόμαστε, αλλά κερδίζουμε όσον αφορά την ταχύτητα επεξεργασίας και τον χρόνο απόκρισης.

Καταστρέψτε την ιδέα ότι το WordPress είναι απλά αργό

Αυτές είναι μερικές συμβουλές που πρέπει να λάβουν υπόψη οι προγραμματιστές κατά την κωδικοποίηση WordPress .

Μερικές φορές, ξεχνάμε ότι η προσθήκη ή το θέμα μας μπορεί να χρειαστεί να ζουν μαζί με άλλα πρόσθετα ή ότι ο ιστότοπός μας μπορεί να εξυπηρετείται από μια εταιρεία φιλοξενίας που εξυπηρετεί εκατοντάδες ή χιλιάδες άλλους ιστότοπους με μια κοινή βάση δεδομένων.

Εστιάζουμε απλώς στον τρόπο λειτουργίας της προσθήκης και όχι στον τρόπο που ασχολείται με αυτήν τη λειτουργικότητα ή πώς να το κάνετε με αποτελεσματικό τρόπο .

Από τα παραπάνω, είναι σαφές ότι οι βασικές αιτίες της κακής απόδοσης στο WordPress είναι κακός και αναποτελεσματικός κώδικας. Ωστόσο, το WordPress παρέχει όλες τις απαραίτητες λειτουργίες μέσω των διαφόρων API που μπορούν να μας βοηθήσουν δημιουργήστε πολύ περισσότερα λειτουργικά πρόσθετα και θέματα χωρίς να διακυβεύεται η ταχύτητα της συνολικής πλατφόρμας.