- Co Founder/CTO Codeat
- Open Source Addicted
- Italian Linux Society council member
- WordPress Core Contributor/Developer
- WordPress Rome/Terni meetup
- Podcast 🇮🇹 Daniele.tech - Opinioni in open source
- VVV Co-Maintainer, GlotDict creator/co-maintainer
- Mozillian & Mozilla Reps
- AMP is dead
- You need to know how Browsers works
- Images optimization and few sizes
- Speed is not just downloading anymore but the whole experience including rendering
- Plugins for mobile versions are not needed anymore
- The database can't be ignored
- Page builders/Visual composers slow down everything
How Google Pagespeed (Lighthouse)/GTMetrix works
How much time is requested to download everything and parse it
- A browser request is executed for size, 1 mobile and 1 desktop
- Analyze the resources cascade, priorities
- Evaluate in % how much of CSS/JS is used in that page
- How much time:
- is required from a blank page to something else
- How much time is required before the user can interact with the page
- How much time is used to render every HTML tag (including move/shift it)
Now it is enforced natively by WP so the image inside the page content are downloaded only if the user can see them.
reSmush.it plugin, includes WP-CLI support, optimize any image for all the sizes to compress it at best without degrading it.
WebP Express plugin, includes WP-CLI support, generate that image version and can provide it to the browser if supported automatically, without any HTML changes.
Every plugin or theme when saves something does in the database, in the 95% of cases those data are still in the database after the plugin/theme removal and still loaded in memory at every single page opening.
If you don't know what to handle that, as it is critical, and require WordPress knowledge it is better to test plugins and themes not on production!
WPDB-Status to analyze WordPress database critical data.
At every page load WordPress read all the language files and parse them in PHP without any cache, #17268 bug ticket.
DynaMo plugin cache the language files content and improve the parsing flow.
HTML Hell by page builders pt.1
- Usually injects in the HTML page content
- the CSS content, instead to refer to a CSS file
- The difference is that instead of a unique file to download once, parsing and caching for all the requests
- Need to download it everytime and re-parse again
HTML Hell by page builders pt.2
- Usually injects in the HTML page content
- Too many HTML tags, everytime you put a separator, a container etc
- This create too many elements that the browser require to parse it, render etc
- How many of them are really required? Pagespeed now just report that there are too much but who knows when that will became a ranking reason?
Burden by page builders
- Usually the structure you define is saved as shortcode or blocks to be parsed and generate the HTML code
- Blocking you to migrate to a different solution because just works only with that plugin
- Structure and your content are mixed, so to change it you need to do a manual clean up
- All of them change the WordPress page rendering flow creating conflicts with other plugins
Why assets optimization matters
- Very rarely plugin includes their assets only in the page where is needed.
- Contact Form 7, in all the pages injects the CSS/JS
- Gutenberg native styles are injected also if you are using the Classic Editor plugin
- Some plugins uses font icons and inject them also if need just few
- As page builders changes how WordPress works, plugins often are not able to identify what page is the user now
Why assets minification matters
After cleaning the assets in the pages like by home page, post types and specific pages like checkout...
The minification can generate for that single page a more/less unique css/js file compressed at best instead of multiple ones.
WordPress Emoji are required?
Usually is enough just one single font that is downloaded by sizes, parsed etc. Google reports always the Google Font requests as very slows and performance impact anyway.
Replace Google Fonts with Bunny Fonts
Redirection plugin slowdown
AS the redirect are in the database the redirection happens after the request arrive to the webserver to the PHP process, parsed etc. Can generate also conflicts with other plugins.
The solution is to generate .htaccess rules as are more fast!
It means that the website just for frontend have an optimized HTML version (already generated) without asking to the PHP to be execute, read data from database etc.
Kinsta guide (about the various caching types)
OR that the data from the database are saved somewhere else in the middle.
OR that browser saves some assets without downloading again on a new page also the next day.
External softwares to install in the server that require specific plugins to connect it.
They are both used for Object Caching and usually one of them is offered by the hosting provider.
- Redis manage better complex data
- Memcached manage better tiny data
- Apache: the standard, works always but an old technology
- LiteSpeed: fast, free/premium version, support htaccess rules, official WordPress plugin
- NGINX: fast, require administrative access to inject custom rules
Various features like image optimization and DNS very fast.
They aren't free but with previous improvements is much better.
Plugins suggested to improve performance
- W3 Total Cache (advanced)
- WebP Express
- iThemes Security (advanced)