How to Optimize the Critical Rendering Path in WordPress

he Critical Rendering Path is the sequence of tasks the browser performs to first render a page on the screen, i.e. to download, process and convert HTML, CSS, and JavaScript code into actual pixels, and paint them on the screen.

The Critical Rendering Path Optimization is the process of minimizing the time spent by the browser to perform each step of the sequence prioritizing the display of content related to the current user action.

Much of this process pertains to the portion of the page that is visible without scrolling down the browser window. That section is also known as Above the Fold. For a better usability, the ATF should be rendered as soon as possible, and this can be done reducing the number of network round trips at a minimum. The resources required to render the ATF are considered critical, and optimizing the Above the Fold means minimizing the impact of critical resources on the time to first render of the page.

In this post, we will walk through the Critical Rendering Path optimization sequence.

  • First, I will provide a general overview of the tasks the browser performs to render a page’s content.
  • Following, I will dissect the most relevant actions we can carry out to optimize the Critical Rendering Path.
  • Finally, I will list some useful (and popular) WordPress optimization plugins.

The Critical Rendering Path Sequence

Here is the sequence of steps performed by the browser to render a page:

  • First, the browser downloads and parses the HTML mark-up and builds the DOM
  • Then it downloads and processes the CSS mark-up and constructs the CSS Object Model
  • It combines DOM and CSSOM nodes required to render the page in the Render Tree, which is a tree structure of all visible nodes
  • It calculates dimensions and position of every object in the page
  • Finally it paints pixels on the screen


As well explained in Google’s Critical Rendering Path Optimization guide, the browser builds the Document Object Model in a four step sequence:

  • First, the browser reads the row bytes and translates them to individual characters
  • Then it converts the strings of characters enclosed within angle brackets into tokens
  • These tokens are converted into node objects
  • Node objects are linked in a tree-like data structure that contains HTML content, properties, and all the relationships between nodes. This structure is the Document Object Model.

What is important to note here is that the browser constructs the DOM incrementally. This gives us the opportunity to speed up the rendering of the page by creating efficient DOM structures.

DOM structure


When the parser encounters a link tag that refers to an external CSS stylesheet, it blocks the parsing and sends out a request for this resource. Once the CSS file has been received, the browser starts building a tree data structure of CSS nodes.

  • The browser reads the row bytes of the .css file and translates them to individual characters
  • It converts the strings of characters enclosed within curly brackets into tokens
  • These tokens are converted into node objects
  • Node objects are linked in a tree-like data structure that contains the CSS properties of each node, and the relationships between nodes. This structure is the CSS Object Model (CSSOM).

Unlike DOM construction, CSSOM construction is not incremental. The browser can’t use a portion of a stylesheet, because styles can be refined and redeclared in the same stylesheet. For this reason, the browser blocks the rendering process until it receives and parses all the CSS. This means that CSS is render blocking.

CSSOM structure

The Render Tree

The browser combines DOM and CSSOM into the Render Tree, which is the final tree structure containing all nodes and properties that are being used to render the page to the screen.

The Render Tree only contains nodes that are required to render a page. As a consequence, invisible nodes are omitted.

The browser uses the Render Tree to calculate node dimensions and position, and ultimately as an input for the paint process.

Render Tree structure

Layout and Paint

In the layout stage, the browser calculates dimensions and position of each node of the Render Tree. In this stage, the browser traverses the Render Tree starting from its root and produces a box model. This information is finally used to convert each node of the Render Tree into actual pixels on the screen.

Critical Rendering Path Optimization

The time required to run the entire process can be variable. It depends on many factors like the document size, the number of requests, the applied styles, the user device, etc.
One of the most relevant Google recommendations is to prioritize visible content so to render the Above the Fold as quick as possible, and provides two main rules to follow:

  • Structure the HTML to load the critical, above-the-fold content first
  • Reduce the amount of data used by HTML, CSS and JS resources

As well explained in Google’s PageSpeed guide, if the amount of data required to render the ATF exceeds the initial congestion window (14.6kb), it will require additional network round trips between the server and browser. On mobile networks, with high latencies, this would significantly delay the page loading (read more on latency).
The browser builds the DOM incrementally, and this gives us the opportunity to reduce the time required to render the ATF by structuring the HTML so to load the above-the-fold first and defer the rest of the page.

The Above the Fold content varies depending on the user device

But optimization does not end with the construction of an effective DOM structure. Rather, it’s a process of improvement and measurement that involves the whole Critical Rendering Path sequence.
Let’s dive deep.

Minimize Resource Dimensions

We can reduce the amount of data the browser is going to download by minifying, compressing and caching HTML, CSS and JavaScript resources:

  • Minification is the process of removing unnecessary characters like comments and white space from the source code. These characters are extremely useful in development, but they’re useless for the browser in order to render the page.
  • Compression is the capability of web servers and clients to reduce the size of transmitted files in order to improve speed and bandwidth utilization
  • Caching: every browser comes with an implementation of an HTTP cache. What we need to do is ensuring that each server response provides the correct HTTP headers to instruct the browser on when and how long it should cache the requested resources

Optimize CSS

Now we know that the browser has to wait until it fetches and processes the CSS code before it can render the page (CSS is render blocking). But not all CSS resources are render-blocking.
CSS can be scoped to particular conditions, and we can optimize it using media types and media queries. If you’re viewing a webpage on the screen, the browser will send a request for print media type but it won’t block the rendering of the page for this resource.
Take the following link tag:

<link rel="stylesheet" href="style.css" />

The referenced stylesheet of this tag applies under any condition, independently from the current media type, screen resolution, device orientation, etc. This means that the CSS resource is always render-blocking.
Luckily, we can send a request for a CSS resource under specific conditions. We could move print styles into a separate file and use the media attribute to tell the browser that the specified style sheet should only be loaded when printing the page, and it doesn’t need to block the rendering on the screen:

<link rel="stylesheet" href="print.css" media="print" />

The browser still downloads the print.css stylesheet, but it won’t block the rendering. Moreover, the browser has to download less data for the main CSS file and this would help us speed up the download. We can specify any media query on the link attribute, so we can split the CSS into multiple files and load them conditionally:

<link rel="stylesheet" href="style.css" media="screen" />
<link rel="stylesheet" href="portrait.css" media="orientation:portrait" />
<link rel="stylesheet" href="widescreen.css" media="(min-width: 42rem)" />

Be sure your styles are actually required to render the page. If they’re not, you can add an appropriate value to media tag attribute and unblock rendering.

Media types and queries can help us to speed up the page rendering, but we can do a lot more.

  • Minify CSS: white space and comments only help us read CSS declarations. By removing comments and whitespace from the stylesheet we can significantly reduce the number of bytes of a CSS file
  • Combine multiple CSS files: this would reduce the number of HTTP requests. This action is particularly important in mobile connections, where performance is affected by high latency (read more on latency).
  • Inline critical CSS: some styles are critical in the sense that they are required to render the above-the-fold of the page. You should always consider inline critical styles directly into the HTML markup to avoid additional HTTP requests. But avoid inlining large CSS files, because this may require additional round trips to render the above-the-fold, and this would result in a PageSpeed warning.

Speed-up Layout and Paint Processes

The time spent by the browser to layout the document depends on the number of DOM elements to layout and on the complexity of those layouts.

  • If you have a lot of DOM elements, the browser could take a long time to calculate position and dimensions of them all: avoid layout whenever it’s possible.
  • Prefer the new Flexbox model, as it’s faster than old Flexbox and floating layouts.
  • Avoid forced synchronous layout with JavaScript

Computing element size and position takes time and reduces performance. Making the DOM as simple as possible, and avoiding the use of JavaScript to anticipate the layout process would help the browser to speed up the page rendering (read more on layout optimization).

Strictly connected to the Layout is the Paint process, which is probably the most time-consuming stage in the Critical Rendering Path sequence, because anytime you change the layout of an element or any non-geometric property the browser triggers a paint event. Making things as simple as possible at this stage could help the browser speed-up the paint process. For instance, a box-shadow property, which requires some sort of calculations, would take longer to paint than a solid border color.

Chrome DevTools allow to identify the portions of the page that are being painted

Optimizing the paint process may not be that easy, and you should make use of your browser’s developer tools to measure how long the browser takes to trigger each paint event. You can read more on this topic in Google’s Rendering Performance guide.

Make JavaScript unblocking

When the browser encounters a script tag it has to stop parsing the HTML code. Inline scripts are executed at the exact point where they are in the document and block the DOM construction until the JS engine finishes running. In other words, inline JavaScript can significantly delay the initial render of the page. But JavaScript also allows to manipulate CSS properties, so the browser has to pause the script execution until it has finished downloading and building the CSSOM, as well. This means that JavaScript is parser blocking.
In case of external JS files, the parser must also wait until the resource has been fetched from cache or remote server, and this could heavily slow down the time to first render of the page.
That being said, what can we do to minimize the time spent by the browser to load and execute JavaScript?

  • Load JavaScript asynchronously: the boolean async attribute of the script tag instructs the browser to execute the script asyncronously, if possible, without blocking the DOM construction. The browser sends the HTTP request for the script, and continues parsing the DOM. Also, the script does not block the CSSOM construction, meaning that it won’t block the Critical Rendering Path (see MDN docs for further information about script tag attributes)
  • Defer JavaScript: the boolean defer attribute of the script tag tells the browser to execute the script after the document has been parsed, but before firing the DOMContentLoaded event. This attribute must not be used if the src attribute is absent, i.e. inline scripts (read more on Mozilla Hacks)
  • Postpone inline JavaScript: many scripts do not manipulate the DOM or the CSSOM, so there is no good reason for them to block the parsing. Unfortunately, we can’t use async and defer attributes for inline scripts, so the only way to load them after the document has been loaded is moving them to the bottom. The advantage is that inline scripts do not require additional HTTP requests. However, inlining scripts used in several pages would result in redundant code.

Wrapping Up Optimization Rules

That’s a lot of stuff, isn’t it? Let’s take a breath, and write down a list of the optimization actions described so far.

  • Minify, compress and cache HTML, CSS and JavaScript resources.
  • Minimize use of render blocking resources (specifically CSS)
    • Use media queries on link tags
    • Split stylesheets and inline critical CSS
    • Combine multiple CSS files
  • Minimize use of parser blocking resources (JavaScript)
    • Use defer attribute on the script tags
    • Use async attribute on the script tags
    • Inline JavaScript and move script tags to the bottom of the document

Now that we know the basic concepts of Critical Rendering Path Optimization, we can have a look at some WordPress popular optimization plugins.

Optimizing the Critical Rendering Path in WordPress

WordPress users can take advantage of a number of plugins that cover almost every aspect of the optimization process. You can install a fully featured plugin, or you can install several plugins at once, each providing specific optimization features.


Should You Disable XML-RPC on WordPress?

A few questions came up in our recent blog post, where we discuss XML-RPC brute force attacks, about disabling XML-RPC on WordPress. To allay any confusion, we thought we would describe exactly what XML-RPC does and whether you should consider disabling it.

XML-RPC on WordPress is actually an API or “application program interface“. It gives developers who make mobile apps, desktop apps and other services the ability to talk to your WordPress site. The XML-RPC API that WordPress provides gives developers a way to write applications (for you) that can do many of the things that you can do when logged into WordPress via the web interface. These include:

  • Publish a post
  • Edit a post
  • Delete a post.
  • Upload a new file (e.g. an image for a post)
  • Get a list of comments
  • Edit comments

For a full list of the WordPress API functions available to developers via XML-RPC, take a look at this page on the WordPress codex.

If you disable the XML-RPC service on WordPress, you lose the ability for any application to use this API to talk to WordPress.

Lets use an example to illustrate: You have an app on your iPhone that lets you moderate WordPress comments. Someone advises you to disable XML-RPC. Your iPhone app suddenly stops working because it can no longer communicate with your website using the API you just disabled.

To us, disabling XML-RPC comes with a cost. You are disabling a major API in WordPress. We briefly provided this capability, but removed the feature because WordPress’s own API abuse prevention has improved. Furthermore, providing the ability to disable XML-RPC caused confusion among users when their applications broke because they could not access the API.

Jetpack is one of the most popular plugins for WordPress and relies heavily on XML-RPC to provide its features. It is developed by Automattic, makers of WordPress. If you visit the “Known Issues” page for Jetpack, you’ll notice they discuss how certain security plugins can impact Jetpack features if you use them to disable XML-RPC.

The following two kinds of attacks on XML-RPC have received press coverage during the past 2 years.

  • DDoS via XML-RPC pingbacks. This is actually not a very effective form of DDoS and anti-spam plugins like Akismet have gotten good at spotting this kind of abuse.
  • Brute force attacks via XML-RPC. These are completely ineffective if you’re using Wordfence because we simply block the attacker after they reach the login attempt limit.

If you still want to disable XML-RPC, there are several plugins to choose from in the official WordPress repository. You will lose any XML-RPC API functionality that your applications rely on. We don’t disable XML-RPC on our own sites.



Κοινωνικά Δίκτυα –Ποιο το αντίκτυπο στη κοινωνία και τι πρέπει να προσέχουμε

Κοινωνικά Δίκτυα –Ποιο το αντίκτυπο στη κοινωνία και τι πρέπει να προσέχουμε


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

Πλεονεκτήματα και οφέλη από τα κοινωνικά μέσα

  1. Παγκόσμια διασύνδεση

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

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

Θα μπορούσε κάποιος να πεί πως έτσι ενισχύεις κάποιες καταστάσεις όπως το να

  • αναζήτήσεις εργασία
  • αναζητήσεις βοήθεια
  • μοιραστείς τις πεποιθήσεις σου
  • να έχεις πρόσβαση σε νέα και γεγονόντα σε πραγματικό χρόνο


  1. Προσβαση σε κοινότητες κοινών ενδιαφερόντων

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

  1. Διαμοίραση πληροφοριών σε πραγματικό χρόνο

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

  1. Στοχευμένες διαφημίσεις

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


Είναι όμως τόσο αθώα τα κοινωνικά μέσα δικτύωσης;Ποια μπορεί να είναι τα μειονεκτήματα;


  1. Αντίκτυπο σχολίων και δημοσιεύσεων

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

  1. Δικτυακός εκφοβισμός και εγλήματα κατά των παιδιών

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

  1. Κίνδυνος απάτης ή πλαστογραφία.

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

  1. Χάσιμο χρόνου

Παρότι μπορούμε να εκπαιδευτούμε, να ενημερωθούμε, να αλληλεπιδράσουμε κλπ, είναι γεγονός πλέον πως τα κοινωνικά μέσα μπορεί να είναι το περισσότερο διαστημα απλά χαμένος χρόνος. Η μεγαλύτερη κίνηση στο διαδίκτυο γίνεται από τα κοινωνικά μέσα και στατιστικά το 60% αυτών από κινητές συσκευές. Επίσης το 28 % του χρόνου μας ξοδεύεται στα κοινωνικά μέσα και ατό το ποσοστό αυξάνεται συνεχώς. Επίσης ένα κομμάτι του χρόνου στα κοινωνικά μέσα ξοδεύεται σε ώρες εργασίας. Αυτό σημαίνει απώλειες για την επιχείρηση και ξανά χαμένος χρόνος.


  1. Επιχειρηματική εισβολή στην ιδιωτικότητα.

Οι κοινωνικές πλατφόρμες προσκαλούν μεγάλες επιχειρήσεις να ειβάλουν στα προσωπικά  δεδομένα των χρηστών και να προωθήσουν τα προϊόντα τους. Σε όλους θα έχει τύχει να κάνουν ένα σχόλιο ή μια ανάρτηση και στη συνέχεια να δουν σχετική διαφήμιση. Για παράδειγμα το facebook υπολογίζεται πως κέρδιζει 16 τρισεκατομμύρια ανά έτος. Αυτό είναι ένα πολύ καλό κέρδος για μια δωρεάν πλατφόρμα. Αρά λοιπόν πως αυτά βγάζουν χρήματα; Ακριβώς χρησιμοποιώντας αλγορίθμους για τις στοχευμένες διαφημίσεις. Επομένως αντιλαμβανόμαστε πως το προϊόν στη προκειμένη περίπτωση δεν είναι η πλατφόρμα αλλά ο ίδιος ο χρήστης.