WordPress Performance Improvements – 2/3 (PageSpeed Audits)

Here we are mainly covering Google PageSpeed and some GTmetrix custom audit suggestions and their solutions. To check the basic WordPress performance points, visit part 1.

16. Avoid an excessive DOM size

Lighthouse flags pages with DOM trees that:

  • Have more than 1,500 nodes total.
  • Have a depth greater than 32 nodes.
  • Have a parent node with more than 60 child nodes.

and shows suggestions like following

How to Reduce DOM Size?

To reduce DOM size, try to minimize the unnecessary HTML elements.

use:

<ul id="nav-main">
    etc..
</ul>

instead of:

<div id="nav-main">
    <ul>
        etc..
    </ul>
</div>

But the process may not be straightforward in WordPress, for WordPress related optimizations:

  • Divide large pages into multiple smaller pages
    • Avoid having all website components like a hero section, forms, events, blogs, services, portfolios, etc., on a single page. It creates a nested and complicated DOM tree.
  • Lazy load videos, images, embeds, comments.
  • Use pagination for blog posts, products, comments.
  • Do not hide unnecessary elements with display: none;

17. Avoid chaining critical requests

Critical request chains are series of dependent network requests important for rendering a page. Lengthier chains and larger download sizes affect the page load performance.

Unless explicitly specified, HTML usually gets the highest priority, then CSS, images, and scripts. For example, if Google Pagespeed detects large chain lengths and sizes with noticeable latency, it shows the following suggestion.

How to manage critical request chaining?

  • Focus on requests that are affecting more (latency (shown in ms) / download size (shown in KB)).
  • Try to eliminate unnecessary requests by disabling plugins, features, etc.
  • Defer the request if those are not required for viewport rendering but needed later on the page.

How to manage critical request chaining in WordPress?

If critical requests chains are not optimized at the development level, they can be managed at the post-development level with plugins.

A plugin like Asset CleanUp helps you to

  • Manage enqueued JavaScript files and on Homepage, Posts, Pages & Custom Post Types
  • Sitewide bulk unloads
  • Remove unused elements from the <HEAD> and <BODY>
  • Minify remaining loaded CSS & JavaScript
  • Ability to add exceptions

18. Avoid document.write()

document.write() can delay page load by tens of seconds, especially on slower connections. Chrome browser blocks the document.write(), so functionality should be independent on this. Lighthouse reports the document.write() calls that Chrome misses.

To solve this issue, avoid documents.write() calls and if third-party scripts are using then load it asynchronously.

How to remove document.write() from a WordPress?

WordPress core do not use document.write() for its functionality. Nowadays modern plugins and theme developers do not rely on it, instead they use document.appendChild() or parentNode.insertBefore(). Some advertisement and third-party scripts are still using it; in that case, add ASYNC to that script element.

<script async src=”script.js”></script>

19. Avoid enormous network payloads

Larger network payloads are directly related to longer load times. They also cost users as they download extra data to consume that page.

The lighthouse shows the size of all resources for the requested page, the largest one on top. It flags pages whose total network requests exceed 5,000 KiB; the median network payload is between 1,700 and 1,900 KiB.

How to avoid enormous network payloads?

  • Minify HTML, CSS, JS
  • Enable data compression
  • Use images wisely (compress, crop, remove metadata, sizing)
  • Use WebP format
  • Enable browser cache so that the same payload is not downloaded again on the next visit or page refresh.

20. Avoid large layout shifts

Large layout shifts affect the visual experience of the user as page elements move around or appear suddenly. Therefore, large layout shift (CLS) is one of the important Web Vital metrics.

Asynchronously loaded resources or dynamically added DOM elements cause sudden movement of layout on the page. Here are some scenarios that cause layout shift,

  • Image or video with unknown dimensions
  • Font or Webfont with a different size than fallback font
  • A third-party ad that resizes itself
WpLift

Solving large layout shifts requires a good coding experience; there’s no common solution for this; it requires a case-by-case analysis. In addition, large layout shifts might affect desktop and mobile experience differently.

Few of the solutions that solve basic CLS problems are as follows

  • Always set image and video dimensions
  • Always set dimensions for iframes and embeds (e.g., Google Maps embeds)
  • Reserve space for ad or dynamically added content

21. Avoid long main-thread tasks

A browser processes content rendering handles user interactions in the main thread. HTML/CSS parsing, Javascript parsing, and execution run on the main thread only.

When any of these tasks take more than 50ms, it is identified as a ‘long task’. These long tasks can delay the first paint and make the page fully interactive for the user.

Example: Long-running JS tasks can block the other tasks like CSS parsing and rendering, increasing the page load time.

How to avoid long main-thread tasks?

Optimizing third-party JavaScript

Remove the third-party codes that aren’t adding any value to your website.

Use web workers

Use web workers to keep JavaScript separate from the main thread.

Reducing JavaScript execution time

By code-splitting, compression, modification, defer JS, etc.

22. Avoid multiple page redirects

Redirects can be necessary sometimes, but usage should be minimal to reduce the impact on page load. Redirects are initiated before any page elements downloads. It increases the initial request’s (HTML) network time; thus, multiple redirects slows down page load.

The first step to solve this issue is to remove the redirect if it is not meant to be there. Second, avoid multiple hops and redirect loops.

23. Avoid non-composited animations

Non Composited animation increases the main thread work; CSS or JS modification triggers the repainting for pixels on a page. As a result, it makes the page stutter or appears visually unstable while loading.

Animations with CSS/JS modifications can trigger style recalculations, repainting pixels, and demand more resources from the main thread. Increased thread is directly correlated with longer load times, and it can also cause multiple cumulative layout shifts (CLS), which is one of the important Web Vital metrics.

There is no one click solution or plugin to solve this issue. You got to stick to compositor-only properties and manage layer count, and use high performance animations.

24. Avoid serving legacy JavaScript to modern browsers

To support old browsers, developers use old legacy javascript code (ES5 Standard). Unfortunately, this results in unnecessary JS files being downloaded by the user.

Developers should use the latest Javascript standards (ES6 or ES2015+); this reduces the data to be downloaded and brings new and modern features to JS programming and functionality.

25. Combine images using CSS sprites

CSS sprites reduce the number of HTTP requests to the server. In addition, CSS sprites are more practical with smaller icons files like social media icons, services icons, logos, etc.

26. Defer offscreen images

The image that is not part of the viewport (offscreen) should be deferred (lazy loading). It is one of the best web development practices that ensure that the browser only downloads the images needed to display in the viewport.

How to defer offscreen images?

Native Lazy Loading

Modern browsers support lazy loading for the inline <img> element by specifying the loading=”lazy” attribute.

Using plugin

Lazy loading plugins like Smush offer you this facility.

27. Efficiently encode images

Basically, it means use compressed images. Images can be compressed manually, or an image CDN should be used to serve images.

28. Eliminate render-blocking resources

Scripts, HTML imports, and Stylesheets may block or delay content rendering on the page. For example, this delays the First Paint (i.e., time at which border renders something on the screen like texts, border, background colors, etc.).

By allowing First Paint to render sooner, visitor perceives that the site is doing something, they get a perception of performance.

How to eliminate render-blocking resources?

Move scripts to the bottom

<script> and <link> elements can be moved to the bottom of the page. These elements will be parsed and executed at the end of the page; it eliminates render-blocking in the viewport.

ASYNC or DEFER

Noncritical <script> and <link> elements can be loaded asynchronously, or loading can be deferred with async or defer attributes.

example:

<script src="/scripts/abc.js" async></script>
<script src="/scripts/123.js" defer></script>
<link rel="import" href="file.html" async>

Please note that it is important to know whether the given script is coded to work with async and defer attributes. If these attributes are used with critical resources, it might break the site.

Split CSS by media type

Divide CSS by media type they are meant for and add media type attribute (i.e., desktop, mobile, etc.)

29. Enable Keep-Alive

This applied to HTTP/1.1 requests only.

Browsers use multiple TCP connections to download the data from the server; on each data retrieval, it closes the connection. Then, it needs to open the connection again; this increases the latency and thus increases the page load time.

The Keep-Alive option keeps the connection open for the next HTTP connections.

How to enable Keep-Alive for Apache?

Apache enabled the Keep-Alive option by default. You can find it on httpd.conf file.

KeepAlive On

30. Enable text compression

As the name suggests, text compression compresses text files like HTML, CSS, JS and saves the download size, which helps in improving page loading performance.

How to enable text compression for Apache?

Add the following code into your .htaccess file:

<IfModule mod_deflate.c>
  # Compress HTML, CSS, JavaScript, Text, XML and fonts
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application/x-font
  AddOutputFilterByType DEFLATE application/x-font-opentype
  AddOutputFilterByType DEFLATE application/x-font-otf
  AddOutputFilterByType DEFLATE application/x-font-truetype
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/opentype
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE image/x-icon
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/xml

  # Remove browser bugs (only needed for really old browsers)
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
  Header append Vary User-Agent
</IfModule>

About Author

Sorry, Comments are closed!