You may be surprised to know that many hosting providers meet the minimum requirements to run WordPress, and claim they offer "WordPress Hosting", but in reality, the server environment is far from properly configured!

This is because WordPress itself will technically work with a fairly minimal PHP (the programming language that WordPress is largely written in) configuration, yet there is a lot that can and should be done to optimise it, or in other words, get the very best possible performance, which is crucial for keeping your visitors happy - no one likes a slow website, and this includes search engines like Google and Bing, who will rank your website lower if the page speed isn't up to scratch.

Other Providers

Missing PHP recommended modules, errors, no SSL, etc.
Example from an out-of-the-box cPanel server.

Ethernet Servers

No warnings or errors, perfectly configured.
Example from an Ethernet Servers web hosting account.

  Above & Beyond PHP Tuning. We load all WordPress.org recommended PHP extensions as standard:

json, nd_mysqli, curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, pcre, xml, zip, apcu, memcached, opcache, redis, timezonedb, bcmath, filter, iconv, shmop, simplexml, sodium, xmlreader, zlib

This provides optimal functionality and performance, allowing WordPress to do its best work.

  Compatible with LiteSpeed Cache. The LiteSpeed Cache for WordPress plugin is the leading performance plugin for WordPress, only available to servers running LiteSpeed web server (a commercial product). It automatically caches frequently accessed pages, minifies CSS, JavaScript & HTML, lazy loads images, and much more. In simple terms, it makes your website much faster than it would normally be - with no impact on the functionality of your website. It is not installed by default, but this can be easily done by yourself, or our friendly UK-based technical support.

  The Latest & Greatest Database Performance. Our servers run MariaDB 10.6 & above, but with a twist - all expertly tuned. We don't simply "set and forget" like most providers, using only an out-of-the-box configuration, but rather, we regularly tune innodb_buffer_pool_size, max_allowed_packet, open_files_limit, key_buffer_size, join_buffer_size, innodb_log_file_size, max_heap_table_size, tmp_table_size and other variables based on the actual usage of our servers. This is important because a server's resource usage on day 1 of deployment is going to look considerably different on day 100, day 1,000, and so on.