Example: Your 19 page has blocking script features and 4 locking CSS features. This causes a delay in rendering your page.
"No part of the content above the fold on your page would be rendered without waiting for the following features to load. Try to postpone or load asynchronously the blocking features, or embed the fundamental parts of those features inline directly into HTML. "
This is the justification for the image above.
As a queue, these components must be loaded so that the page is displayed in full.
Due to the size of such files and the lack of organization and definition of a structure that will set the loading priority, they may delay the display of some elements of the pages that can be viewed without being fully loaded.
1 - Install the "Speed Booster Pack" plugin in WordPress.
2 - Now navigate to Settings> open the speed booster pack
3 - Now below click on the option: Still need more speed and check the Load CSS asynchronously option to "load CSS asynchronously", it will remove the error from the CSS part.
You have other options in this plugin if you need to use performance enhancements to run tests and verify.
Magento 1 and 2
For both versions of Magento there are several extensions available that will address this issue.
As I avoid the use of extensions for such purposes, unfortunately I can not do any indicate.
Techniques to improve CSS performance
CSS is usually not the problem because it is already loaded asynchronously.
However, sometimes it can become a problem when assets become very large.
The best way I know of optimizing this is to separate what is essential and put it at the top of the page and leave what is not essential for after or yet to be loaded asynchronously.
In addition, specific styles that serve only one page can be placed inline or in separate styles.
A good organization would look like this:
- Common style for the whole system
- Page-specific style
- User-specific style, if any
Anyway, here organization is everything.
This is because you do not want to postpone CSS loading too much, since it is usually something that is missing from the interface.
It is important to remember that a good organization improves the use of the cache both by the browser and by the CDN, after all, you separate what changes more than changes less. This helps your site have a shorter loading and rendering time, taking only a little longer on first access.
Scripting optimization, in addition to the organization, requires a deeper understanding of the many options available and how browsers work.
Ideally, you want scripts to start loading as soon as possible, but only execute, pausing the page after critical content has already been displayed.
A simple way to do this is to use the attributes
- They execute the loaded scripts as soon as they are downloaded in any order (
- Run the loaded scripts after you finish displaying the page, in the order in which they appear on the page (
Which one is the best? It depends.
async it's best when you want the functionality added by the script to be present as soon as possible, probably something critical.
defer it is best for something that is not worth pausing to render the page.
But say you only use such attributes in your tags
<Script> is to be very simplistic.
Difficulties in asynchronous scripts
Problems begin because inline scripts can not be asynchronous or deferred.
So if they depend on some script included from external source you need some mechanism so that they execute only when such dependencies are met.
The same goes for asynchronous scripts, which can run in any order.
A simplistic way to solve the problem is to use the event
window.onload. But it has a serious problem with this approach: it puts everything off until the end, which means that even the critical features will have to wait for everything on the page to load.
sets) and what they depend on (
So you add a little script loader at the beginning of the page (synchronous) that is able to identify when the dependencies of a certain script are satisfied and execute it as soon as possible.
Um script loader does not necessarily mean that it will download the scripts on demand but that it keeps a record of the modules present on the page and can know when they can run.
Within the modules, you can still add events
onload to postpone the execution of what is not so important.
Or you can use the lazy more aggressive, which is to load the code of a functionality only when it is activated by the user.
For example, imagine that on your system there is a complex Popup window open when the user clicks a button that is present on every page.
You do not want the code to load on all pages, because the window is not always used. Then you can load the code and styles used in the popup within the event
click button. The first time the user clicks, it will take a little longer to open, until the assets cache, but will allow the site to be faster overall.
In your case, that there do not seem to be many scripts, I'd turn them all into AMD modules and
defer in all scripts.
If you have inline scripts that it can not transform into a module, a technique to postpone their execution is to change the
And then you create a module that evaluates the content of those using
eval It 's not a sin when you know what you're doing.
18 tips for you to optimize your website or virtual store.
- Image Optimization
- Reduce number of HTTP equalizations
- Critical locking and rendering block resources (CSS + JS)
- Reduce latency with a CDN (for images, css and JS)
- Time to First Byte (TTFB)
- Avoid 301 redirects
- Prefetch and Preconnect
- HTTP / 2
- PHP7 and HHVM
- Web Source Performance
- Hotlink Protection
- Enable Gzip Compression
- The infrastructure
- Fix 404 Errors
- Serving Staggered Images
- Database optimization
Completing the render lock