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

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

μελέτη περίπτωσης για τον προϋπολογισμό κεφαλαίων με λύση

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

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

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

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

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

Απόκτηση θέσεων εργασίας

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

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

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

  
  
  

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

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

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

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

Για να γίνει αυτό, χρησιμοποιούμε την παράμετρο «δημοσιεύσεις ανά σελίδα».

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

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

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

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

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

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

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

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

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

$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__no_en» από το ερώτημα.

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

Έτσι, όταν ψάχνω για τις αναρτήσεις και επεξεργάζομαι μόνο εκείνες που δεν βρίσκονται στον πίνακα '$ posts_para_exclude'. '

Αποφύγετε τη σύνθετη παραμετροποίηση

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

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

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

Αξιοποιήστε στο έπακρο τις επιλογές του Wordpress.

Επιλογές API WordPress 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), αλλά άλλοι δεν το κάνουν και πρέπει να το εγκαταστήσουμε ξεχωριστά.

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

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

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

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

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

μεταβείτε στο πλαίσιο στρατηγικής αγοράς

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

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

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

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

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

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

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

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

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

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

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

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

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

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