The 5 most common reasons for a slow WordPress site and how to fix them
0 likes780 views
Presentation given at the WP Berlin Meetup on May 23rd, 2019. https://www.meetup.com/Berlin-WordPress-Meetup/events/gmzjwqyzhbfc/
Ad
More Related Content
What's hot (20)
Similar to The 5 most common reasons for a slow WordPress site and how to fix them (20)
Ad
More from Otto Kekäläinen (20)
Ad
Recently uploaded (19)
The 5 most common reasons for a slow WordPress site and how to fix them
- 1. The 5 most common reasons for a slow WordPress site and how to fix them Otto Kekäläinen @ottokekalainen WP Berlin Meetup 23. Mai 2019
- 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 installing 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. 3. Web servers that are slow or lack HTTP/2
- 18. 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
- 19. 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/
- 20. 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.
- 21. 4. Caches not working as they should
- 22. 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!
- 23. 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
- 24. 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.
- 25. Caches not working as they should Remember, caching is also good for the environment! (Prevents excess CPU cycles from happening.)
- 26. 5. Code is doing too much
- 27. 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.
- 28. 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
- 29. Code is doing too much XDebug + Webgrind More at: https://seravo.com/docs/development/xdebug/
- 30. Code is doing too much Tideways.com – from Germany More at: https://seravo.com/docs/development/tideways/
- 31. 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
- 32. Thank you! @ottokekalainen See you at WordCamp Europe?
- 33. Premium hosting and upkeep for WordPress HTTP/2 TESTED UPDATES 24/7 UPKEEP
- 34. 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