Because context matter most, there’s no clear definition or specific set of instructions that just makes it blazing fast. In most cases bigger and smaller changes, such as the ones below, will help you achieve a better performance for your site.
These below are suggestions that will make the biggest impact on your website’s speed.
This is a controversial topic and that’s why i don’t want to share too much of my opinions, and instead i suggest to research on your own if your hosting is the best solution for your website. What i can say for sure is that if it’s really cheap, then cheap you get. There’s a reason why some hostings cost $3 and others $99 and more. I’m not saying get the most expensive, i’m just saying don’t get the cheapest.
Also, LiteSpeed based hosting is also recommended. I can’t share any specific platform because i don’t know, however i’ll be sure to add here as soon as i’m aware of any.
A great video about Hosting by Darrel Wilson can be found here https://www.youtube.com/watch?v=AaohKvUpXxc .
Rey is hosted on the lowest SiteGround Cloud package however that’s because it receives a lot of traffic and we want to have some form of control over some aspects. However there are plenty much cheaper solutions out there.
CDNs can help your users load your website faster by serving your static resources in nodes all around the world. More in this article https://gtmetrix.com/why-use-a-cdn.html .
It’s probably the most common and obvious suggestion there is.
It’s simple, the more plugins you use, the more code runs, the slower the WordPress instance should become. Make sure to enable plugins that are actually in use, are high quality and positively rated.
Please don’t ignore this one. It’s very, very important what you load in your website.
There are lots of caching plugins out there. I won’t write about any of them and encourage instead to research on your own.
As a free solution, my personal favorite is WP Super Cache in combination with Autoptimize but there are plenty others too. Autoptimize plugin is a companion plugin to handle assets minification and concatenation (as well as other features too). This reduces CSS and JS filesizes and also the number of requests made. Another feature of it is lazy loading images and i suggest using it as well. Here’s a video tutorial i suggest if you’re not sure how to handle this plugins.
A premium solution i suggest is WP Rocket. Has pretty much all features included and it’s running on Rey’s demos. Has an easy interface and Rey plays well with it. Here’s a quick recording of a walkthrough WPRocket’s settings https://d.pr/v/tkgVuZ .
These are personal preferences, but there are lots of comparison articles out there and i’m sure there are plenty other great performance improvement plugins, but i just haven’t had the chance to test them.
In 2.0 Rey’s update, all CSS and JS has been split in smaller pieces that are only called on demand. Technically speaking, there’s less code loaded for each page.
Rey will also combine these assets into a single file, however this only works when there’s no caching plugin installed (because weird stuff would happen and it’s a precaution that was needed in order for everything to be working fine).
So if there’s a caching plugin enabled, Rey’s assets will stop being combined and instead will load separately – resulting in multiple file requests. That’s because it passes the minification & concatenation job to the caching plugin. Therefore make sure to keep them enabled.
Please remember, the code must be read by machines, so unless you’re in development mode, there’s no reason not to minify your code.
This one is very, very important. Make sure to optimize your images for web, and ideally served in a modern web format – webp.
An unoptimized image can weight as much as the page’s entire CSS or JS scripts combined. Be sure to optimize them!
This is also an important optimisation. Instead of loading all images at once when the site loads, lazy loading will only load them when scrolling the page. This offloads a lot of bandwidth.
Usually most caching plugins has this functionality, so make sure to enable it.
Also this applies for Iframes too in case you embed videos in the page.
By definition, Redis and Memcached are both in-memory data storage systems. Memcached is a high-performance distributed memory cache service, and Redis is an open-source key-value store.
It’s probably best to ask your hosting support team if any of them is supported on your server.
Even though they’re smaller tweaks, these improvements can make a difference.
Make sure to add a fixed PX (not percent) width and height for the Logo image eg: https://d.pr/i/IahhRQ . This will make sure to avoid layout shifts, especially if the logo is lazy loaded.
Stop using Font Awesome and instead use SVG icons. That’s because even though you might use a single icon from a library, the entire library will load.
FontAwesome’s icons can be found in svg format and also there’s www.iconfinder.com where there are tens of thousands of free icons.
Elementor loads it by default, but you can optimize this. Please access Elementor’s Settings > Experiements and enable Inline Font Icons eg: https://d.pr/i/nixKHD . This will help a lot!
By default Elementor selects Roboto as default global font. If you’re not using it, it’s best to deselect it in Elementor mode > Page Settings (bottom left gear icon) > Site Settings > Global Fonts eg: https://d.pr/i/6N9Hz4 . It’s an important request that can be reduced.
If you don’t want to load Elementor’s Google fonts at all try disabling it in the Advanced settings ex: https://d.pr/i/f2BagD .
Elementor 3.x brought various improvements, amongst them being an “Optimized DOM Output” and “Improved Asset Loading” eg: https://d.pr/i/02phyo .
If you’re going to attach background images to Column elements, it could be a good choice to load them as image tag, instead of just background image eg: https://d.pr/i/fHg5Mu . This will make the images to lazy load and not being downloaded when the site loads. Please note though that it’s not needed when the column is in the “above the fold” area of the site.
In recent versions Elementor team also included this as a feature and you can enable it in Elementor > Settings > Features ex: https://d.pr/i/PB3yGK .
Columns & Inner Sections add a lot of extra markup so where you can, try to avoid using them and instead rely on each element’s Inline positioning. Follow this video https://www.youtube.com/watch?v=vBAKGupM0co to see how you can optimise the layout using best practices.
Also, Rey adds an option on Section elements to transform columns into rows eg: https://d.pr/i/N0D7Gg .
Starting with Elementor 3.12 , the Flex Containers have become more stable and they can be used in new websites. Please know that a Container can have a widget as a sibling, so make sure to avoid overusing Containers or unnecessarily wrapping widgets into Containers.
That’s because Rey’s sliders JS library is much smaller. Elementor uses Swiper which can get quite heavy.
Any Google Font loaded in the website automatically adds up to the site performance. The less fonts you load, the more performant the site will be. Here’s a list of improvement tips:
Don’t use more than 2 fonts (one for body font, the other for Headlines)
You can maintain a consistent layout by doing so, because having too many fonts in a page can be plain ugly and confusing.
Use Primary & Secondary font slots
Work faster by having a centralised choice for fonts.
Access Customizer > General > Typography and select a Primary and a Secondary font. Throughout the entire website, either other Customizer typography controls or in Elementor, make sure to select Rey Primary or Secondary font.
When changing these 2 main font controls, it will automatically be updated in the entire website, instead of having to go through all typography choices and re-select the new fonts.
Self-host Google Fonts
Nowadays this technique appears to be faster. Self hosting the font would avoid relying on bandwidth and network latency.
Trim Weights and Subsets
Each font supports loading various weights (ex: normal, bold, etc.). When loading too many weights, the performance drop is noticeable, especially if those weights are not actually used.
Make sure to access Rey’s Settings > Font settings and carefully pick Weights ex: https://d.pr/i/IUFwyX .
If your website needs a subset of characters (like Cyrillic, Greek, Hebrew etc. ) you can pick it, but make sure to avoid loading all subsets.
If you’re not using blocks at all, try disabling some unnecessary stylesheets that are loaded eg: https://d.pr/i/KloTXH , in Customizer > General > Performance .
Most plugins that have a frontend output will likely load some styling or scripting. If you know for sure that a plugin’s assets shouldn’t load some assets in a specific page, then it’s best to use Rey’s exclude functionality from Customizer > General > Site performance eg: https://d.pr/i/HaXXdq . You can add the asset ID or filename.
When WordPress 4.4 was released, oEmbed was merged into the core. You have probably seen or used this before. This allows users to embed YouTube videos, tweets and many other resources on their sites simply by pasting a URL, which WordPress automatically converts into an embed and provides a live preview in the visual editor.
If you don’t plan on using it, make sure to remove it. Here’s an interesting article showing how to disable them.
If you do have a caching plugin installed though, it’s likely it could have this option built-in.
Emojis are little icons used to express ideas or emotions. If they’re not really necessary for your WordPress site, than it’s recommended to be disabled, because some scripting is loaded. Here’s an interesting article showing how to disable them.
If you do have a caching plugin installed though, it’s likely it could have this option built-in.
Note: Rey 2.4.0+ has this built-in and enabled by default.
When such resources (images, styles, scripts, 3rd party resources etc.) are missing or failed, the browser is trying to solve them, but in many situations it timeouts late. Here’s an example https://d.pr/i/9PYJGX of a missing image that takes 17s to be finally solved as 404 by the browser.
To check the Network activity in Chrome Developer Tools, and verify your site’s slowest points, here’s a step by step guide https://developer.chrome.com/docs/devtools/network/#open .
In some cases, there might actually be some PHP errors that are behind the slowness. Here’s a quick and easy video tutorial to help out in debugging WordPress .
You can also install Query Monitor and get reports for the number of queries, duration and overall DB performance. I highly advice to try it.
You might want to check this article to debug TTFB issues.
If you’re not planning on using Rey’s animations (Reveal etc.) it’s probably best to access Theme settings in the backend and disable the option that loads the module eg: https://d.pr/i/7gFhLE .
This goes the same for Elementor built-in animations.
Unless you’re running an efficient persistent database caching system (Redis/Memcached) having lots of product items in a single page could result in large DB queries.
Make sure to disable “Rey Module – Preloaders Pack” , “Rey Module – Side Header” and “Rey Module – Fullscreen Menu” plugins if you don’t use them. They are optimized already to prevent loading unnecessary code if not in use, however there’s just no point in keeping them active as long as they’re not actually used.
Rey has over 60 internal modules and 50 Elementor widgets. Many of them are likely not in use in the website, so why not disable them completely?
Simply access Rey > Modules Manager & Rey > Elements manager and click on the top right “Scan unused” button eg: https://d.pr/i/nm4cVG . After scanning, click on the Disable button.
Please note that Rey’s modules are efficiently built and they don’t run, however they’re still loaded and some bits of code still run (which determines if the particular feature/module is enabled).
If in the future you’ll seek a specific feature, try checking in Rey’s modules if that functionality is already included. I’ve seen many cases where functionalities that already exist in Rey are added through other plugins.
You can offload product grids by enabling the lazy load option inside eg: https://d.pr/i/bQ8njh . This will make the element to load only when the user has scrolled to its position in the page.
I suggest disabling this option because it runs some tracking JS scripts in the frontend. To locate the option please visit WooCommerce > Settings > Advanced > WooCommerce.com ex: https://d.pr/i/qejgEs .
There’s an option in Customizer > General > Performance, called “Mobile improvements”. This option is exclusive to WPRocket because it has the ability to cache the site separately on mobile.
Wrote an article here what it’s about and how to use it.
Inside Customizer > General > Performance you will find a control to create entries for one or more assets to be preloaded eg: https://d.pr/i/ZrQma2 .
By definition: The preload value of the element’s rel attribute lets you declare fetch requests in the HTML’s , specifying resources that your page will need very soon, which you want to start loading early in the page lifecycle, before browsers’ main rendering machinery kicks in. This ensures they are available earlier and are less likely to block the page’s render, improving performance. More about preloading at Mozilla docs – Preloading content.
Basically each entry added hints the browser to preload it. It’s only useful for assets rendered above the fold (top area) to load them faster in the pages load cycle.
Make sure not to add more than 1-2 items or be careful or otherwise it would make more harm then good.
Yes and no. I’ll explain.
PageSpeed Insights is a great tool for getting all sorts of reports about the speed, site performance and accessibility, the important metrics being Core Web Vitals (LCP, FID, CLS).
A while ago Google announced that Core Web Vitals will count as a measurement when determining the ranking of a site.
What was failed to be properly communicated is that the Core Vitals will only be a single signal from hundreds of signals that determine the ranking factors of your site in Google’s search results.
So basically everything about these Google updates is to highlight the best experiences and ensure that users can find the information they’re looking for. Not the fastest.
Content is and will always be king, but a fast website will tremendously improve the site’s user experience. This is what it’s all about, because after all Google is a search engine and needs to serve the most relevant result, not the prettiest or fastest one.
Here’s a video from Google’s Webmaster SEO channel https://www.youtube.com/watch?v=XUOD6pcvnso , where they explain what this tool actually does. Basically it’s mostly about the user’s experience (as they mentioned in the video, you can just put a single text in your site and you maybe get a 90+ scoring).
So should you stress too much? In my opinion not that much. Even billion dollar companies like Apple, Walmart, Asos or Target, barely get a +30 grade, which is ironic knowing there are teams of hundreds behind them.
So again, trying to get a 100 score is a waste of time, unless you actually have that time and resources, and most importantly complete control over the code or what you load in the website.
But if you don’t, score as much as possible, preferably 90+ and focus on great content, getting your brand known and offering the best overall great site experience.
No. No tricks at all, just Rey and properly optimized content. Here’s what all demos have:
- Rey is hosted on the lowest SiteGround Cloud package.
- WPRocket is used as a caching solution;
- There’s a CDN running from BunnyCDN;
- Images are optimized and lazy loaded;
- No unnecessary plugin used.
Why after importing a pre-made demo content, the scores are not the same as in your demo preview sites?
This is because the demo sites are optimized with all of what’s explained in this guide. Most of these optimisations cannot be imported in another website and require manual input, and of course a caching solution.
That’s because – as seen in this guide – most of the suggestions are not related to Rey, but rather the content (eg: images) and the other installed plugins. The ones that are related to Rey have options and they can easily be enabled.
Rey cannot take responsibility for anything but itself. So every installed plugin, large image, script or stylesheet is a potential problem if unoptimized or even worse, not in use.
It’s important to remember that Rey is very well build, highly optimized and has a tiny output, especially considering the amount of features it has. But it cannot fix other problems of the website. At the end of the day, it’s a theme, not a caching or site optimisation solution.
To add up, Google PageSpeed Insights, like all benchmarking tools, is a very, very pretentious tools and requires the best possible code in order to provide a passing grade.
Somewhere, some time ago someone said “Caching plugins shouldn’t even be needed”. This is nonsense and it’s not true. Caching is very much needed for any dynamic website which interacts with a database.
It’s very simple. Instead of querying the database for the same data for all site visitors, over and over again, on each site visit, why not cache it and serve it statically avoiding redundant database interactions.
So either rely on the hosting’s internal caching mechanism or install a caching plugin as soon as possible.
Yes, in fact it’s probably the most performant out there. That’s because everything from top to bottom is tailored around performance, modularity and running code only when in use.
As an example, regardless of all Rey’s powerful features, it has a similar or even smaller footprint then a barebone theme like Hello Elementor.
PageSpeed is primarily a frontend benchmarking tool, meaning it will penalise many things, but most importantly anything that’s loaded in the page from the first page byte.
More exactly it wants only what it’s showing in the “above the fold” area, while the rest of the CSS/JS/images/fonts etc. to be deferred. That’s why “Eliminate render-blocking resources” is always the most nagging. It just wants to have as little CSS/JS as possible until the first paint, because CSS/JS by default are render blocking, meaning site will be white until all what’s inside the tag is loaded.
So in this particular case, the server configuration doesn’t matter much, meaning the processing power in the background is great, however what’s on the client side is mostly being scored.