Presentation given in WP Meetup in October 2019. Includes fresh new tips from summer/fall 2019! A Must read for all WordPress site owners and developers.

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

2. ● 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

3. The 5 most common reasons for a
slow WordPress site
1. Unnecessarily large image files
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

4. 1. Unnecessarily large
image files

5. Unnecessarily large image files
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.

6. Unnecessarily large image files
Check it yourself: press F12 to
open the developer console in a
browser.
See tab Network and check
image files Size and Time.

7. Unnecessarily large image files
Another tool: webpagetest.org

8. Unnecessarily large image files
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.

9. Unnecessarily large image files
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 ...
File size reduction: 16K --> 16K
Optimized image by: 7.47187 %
---> Optimizing otto-normal-full-size.jpg ...
File size reduction: 868K --> 464K
Optimized image by: 46.6131 %
Optimized 6 images for a total of 463KiB saved!

10. Unnecessarily large image files
Remember to validate after changes!

11. 2. Too many HTTP
requests and assets
loaded in vain

12. 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.

13. 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.
Too many HTTP requests and
assets loaded in vain

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

15. 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!
Too many HTTP requests and
assets loaded in vain

16. Too many HTTP requests and
assets loaded in vain
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!

17. 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/

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

19. 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

20. For developers: learn how to use
the command-line tool curl:
● Tests WordPress specifically
= 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.
Web servers that are slow or
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/

21. Web servers that are slow or
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.

22. 4. Caches not working as
they should

23. 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!

24. Caches not working as they should
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

25. Caches not working as they should
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.

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

27. Caches not working as they should
Remember, caching is also good for the environment!
(Prevents excess CPU cycles from happening.)

28. 5. Code is doing too much

29. 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.

30. Code is doing too much
Finding the code bottlenecks is
hard without proper tools.
Solution:
● Code profiling
● XDebug on test sites
● Tideways on production
sites

31. Code is doing too much
XDebug + Webgrind
More at: https://seravo.com/docs/development/xdebug/

32. Code is doing too much
Tideways.com
More at: https://seravo.com/docs/development/tideways/

33. Code is doing too much
The database is often the
performance bottleneck. See my
other talk on WordPress and
database optimization:
More in-depth code profiling tips
in my WordPress performance
talk:
wordpress.tv/?s=otto+kekäläinen

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

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

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

37. 0. Who is Otto and what is Seravo
a. Follow on Twitter to get slides
1. Too big image file 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 minification 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