The 5 most common reasons for a slow WordPress site and how to fix them – extended edition

The 5 most common reasons
for a slow WordPress site
– and how to ﬁx them
Otto Kekäläinen
@ottokekalainen
WP Meetup
October 2019 Edition

● A CEO who codes at Seravo.com
● Written WP themes and plugins,
contributed to WordPress Core,
MySQL, MariaDB, Debian,
Ubuntu, Linux kernel,
AppArmor…
● Linux and open source advocate
Otto Kekäläinen

The 5 most common reasons for a
slow WordPress site
1. Unnecessarily large image ﬁles
2. Too many HTTP requests and assets loaded in vain
3. Web servers that are slow or lack HTTP/2
4. Caches not working as they should
5. Code fetching too much external data before printing
out the WordPress HTML for visitors to see

1. Unnecessarily large
image ﬁles

Unnecessarily large image ﬁles
The pictures from modern mobile
phones are huge. A single image
from a 8 Mpix camera is easily 3
MB in size and 3840x2160 in
dimensions.
My laptop: 1920x1080
Iphone X: 2436x1125
On websites any image over
1000px per side is usually waste
of space.

Check it yourself: press F12 to
open the developer console in a
browser.
See tab Network and check
image ﬁles Size and Time.

Another tool: webpagetest.org

Solution:
● Always use one of the image
sizes generated by
WordPress, never full size.
● Use open source
command-line tools like
optipng and jpegoptim to
optimize your images.
● There are also plugins that
send your images for
processing on a remote
server.

Smart server environments and
development tools take care of image
optimization automatically.
wp-optimize-images
No path given as argument. Using default path.
Scanning for image files in
/data/wordpress/htdocs/wp-content/uploads/
Found 9 images in total and 6 new images.
...
---> Optimizing otto-normal-full-size-1568x2788.jpg ...
File size reduction: 360K --> 324K
Optimized image by: 10.3697 %
---> Optimizing otto-normal-full-size-169x300.jpg ...
---> Optimizing otto-normal-full-size.jpg ...
Optimized 6 images for a total of 463KiB saved!

Remember to validate after changes!

2. Too many HTTP
requests and assets
loaded in vain

Too many HTTP requests and
assets loaded in vain
With the same web developer
console or webpagetest.org tool
you can see how many HTTP
requests were made and the total
size of download:
Solution:
● Uninstall unnecessary
plugins
● If you see a contact form
plugin load on every page,
report that as a bug to the
plugin author. It should load
it’s assets only on the page
where the contact form
actually is on.

If you see this in webpagetest.org
results then you know the
bandwidth of the visitor is
saturated:
Since you can’t increase the
visitors’ bandwidth, you must
slim down your site contents.
Front page should below 100 HTTP requests and 1000
kb, but 30 req and 300 kb is often doable with some
smart design.

Don’t try to solve
performance issues
by installing more
plugins!

Since WordPress 5.2 the core now has the Site Health page that also
recommends uninstalling all unused plugins and themes, which is always a
good practice!

What about minification and
concatenation = combining many
.js and .css files into one?
Ensure your site is server
with HTTP/2 which has
similar features built into
the protocol.
With modern browsers and
HTTP/2 the benefits of
minification and
concatenation is marginal.
Use your developer time on
something else!

Extra tip: native lazy loading images
● Latest Chrome supports new <img> attribute loading=”lazy” that
postpones downloading the image until visitor scrolls down to it.
● For WordPress 5.x sites: wp plugin install --activate native-lazyload
● Read more at wordpress.org/plugins/native-lazyload/

3. Web servers that are
slow or lack HTTP/2

The front page of a fresh
WordPress installation
should load in under 300
ms when tested on
webpagetest.org.
Click on the
request to see
details, and check
for HTTP/2.
Web servers that are slow or
lack HTTP/2

For developers: learn how to use
the command-line tool curl:
● Tests WordPress speciﬁcally
= HTML output of a site
● Shows headers as well.
● Does not cache, all redirects
et al are always really from
the server and not your
browser’s memory.
lack HTTP/2
curl -Ls https://example.com/article/ -o
/dev/null -w '%{http_code}
%{time_total}n'
200 0,341418
curl -ILs -H Pragma:no-cache seravo.com
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Thu, 23 May 2019 14:32:51 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://seravo.com/

lack HTTP/2
You get what you pay for with
hosting that costs only 2,95€ per
month. Don’t try to save 20 euros
in the wrong place, it won’t be
worth it once you get trouble!
A good hosting solution will not
only be much faster than
average, but also usually include
better technology (HTTP/2,
Redis caching, gzip
compression) and some
companies even offer upkeep
that covers monitoring, updates,
security and much more.

4. Caches not working as
they should

Caches not working as they should
Unfortunately the quality of many
WordPress plugins and themes
are low, and they do things that
bust the cache:
● emit cache denying headers
● set cookies for all visitors
HTTP caching is very important,
since when it works, the HTML
from WordPress/PHP does not
need to be fetched at all and
everything is much faster from
the server.
HTTP caching also happens in
the browser and what is fetched
from browser memory is very
quickly shown to the visitor!

While webpagetest.org also
shows cache headers and
statuses, using curl is invaluable
since you can make changes on
the server validate it in an instant:
Look for headers like:
● cache-control
● expires
● age
● set-cookie
Good read:
https://developer.mozilla.org/e
n-US/docs/Web/HTTP/Caching
curl -ILs https://example.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate,
max-age=0

Cookies imply that there is a
session and that the HTML page
contents is individually tailored,
thus no caching.
Cookies should not be used for
language selection or for storing
cookie consent info (sic!).
The old PHPSESSION cookies
should not be in use anywhere
anymore!
On a WooCommerce site cookies
might make sense, since the
page might have a shopping cart
or a “Hello <name>” section that
is supposed to be shown to this
only one user.

Extra tip: test HTTP cache
● For Seravo’s customers: wp-check-http-cache

Remember, caching is also good for the environment!
(Prevents excess CPU cycles from happening.)

Code is doing too much
Typically developers don’t test
their plugins with large amounts
of data and they work well on
small sites.
As sites grow, all problems related
to excess data manipulation
become visible.
External API calls in PHP typically
also block the entire site from
loading if the external API is down.
Solution:
● Inject more data on a test
site and see how it behaves
● In code, don’t always fetch
everything from the
database. Remember
“LIMIT N” in SQL, OK?
● Design code to do only what
is needed for the view,
nothing else.

Finding the code bottlenecks is
hard without proper tools.
Solution:
● Code proﬁling
● XDebug on test sites
● Tideways on production
sites

XDebug + Webgrind
More at: https://seravo.com/docs/development/xdebug/

Tideways.com
More at: https://seravo.com/docs/development/tideways/

The database is often the
performance bottleneck. See my
other talk on WordPress and
database optimization:
More in-depth code proﬁling tips
in my WordPress performance
talk:
wordpress.tv/?s=otto+kekäläinen

Extra tip: test with network block
● For Seravo’s customers: wp-check-remote-failure

Thank you!
For more tips read blogs at
seravo.com (in English) or
wp-palvelu.ﬁ (suomeksi)
or sign up at
seravo.com/newsletter-for-wordpress-developers/

Premium hosting
and upkeep for
WordPress
HTTP/2
TESTED
UPDATES
24/7 UPKEEP

0. Who is Otto and what is Seravo
a. Follow on Twitter to get slides
1. Too big image ﬁle sizes
a. Typical with modern mobile phones and on blogs
b. See it yourself in the developer console, page size should be <1MB
c. How to use webpagetest.org to measure it
d. Optimize images with open source tools yourself or install a plugin - Seravo has wp-optimize-images
2. Too many HTTP requests and assets loaded in vain
a. Look at web developer console how many requests are made on every page
b. Remove excess cruft, remove unnecessary plugins. WP 5.2 health check helps!
c. Don’t try to solve speed issues by installing more plugins!
d. Forget miniﬁcation and concatenation - ensure you have HTTP/2 instead
3. Slow web server, cheap hosting, lack of HTTP/2
a. Fast web server - WP out of the box should load in 200 ms
b. How to use curl to measure it
c. Browser developer console
d. Hosting should cost closer 30-50 euros per month
e. Good hosting takes automatically care of many server side things, like HTTP caching, Redis based object caching, HTTP/2, gzip compression etc
4. Cache busted
a. How to use curl to see cache headers
b. Avoid cookies set in vain
i. WooCommerce OK
ii. Cookie consent or WPML is not OK use case for cookies
5. Code is doing too much
a. XDebug
b. Tideways
c. Database size often the culprit, see my other talk
d. See my WC Europe talk. See you this year as well?
6. Software Architect tips
a. Blocking JavaScript
b. AMP - don’t do it
c. Progressive web applications - the future

The 5 most common reasons for a slow WordPress site and how to fix them – extended edition

Recommended

More Related Content

What's hot (20)

Similar to The 5 most common reasons for a slow WordPress site and how to fix them – extended edition (20)

More from Otto Kekäläinen (20)

Recently uploaded (19)

The 5 most common reasons for a slow WordPress site and how to fix them – extended edition