I’ve never really gotten in to this too much in the past, but before going live (yes it is taking way longer than expected) I’ve been looking at performance metrics on the different types of pages in M2 with the porto theme. One of the most useful tools I’ve found is: https://yellowlab.tools/
It is pointing out some glaring issues IMO with porto. With Porto, in all, there are 18 fonts being loaded. EIGHTEEN. It results in approximately 300kb on a first load. That is insane when the load size is 900KB-1.2MB.
Also, porto is loading another Jquery. Magento seems to load v1.12.4 and porto is also loading v3.4.1. This also seems like a large waste as well. I doubt there is any way around loading magento’s as I’m sure it needs it. It does complain about these being vulnerable versions as well in another test, which is interesting.
Otherwise there are some duplicate selectors and similar colors used, but I don’t think those have a huge impact other than simply being annoying and affecting the score. There’s also the typical magento huge DOM count, complex css, etc… which I also don’t think there will be a good way around that type of stuff either.
I think reducing the webfonts and possibly reducing the jquery down to what default magento wants would help a bit. I haven’t looked in to what porto’s jquery is being used for.
Before I say anything, I just want to warn against going down the rabbit hole. Chasing metrics can turn into an obsession. There comes to a point where the time/effort outweigh the diminishing returns.
Personally, I use Lighthoust a lot. It’s one of your Inspect Elements tabs in Chrome.
I have my projects limited on font variations. Typically, I’ll stick to 2-3 max. There are a few ways of pulling in fonts. One method is to call an entire font-family. It’s a bigger file, but only requires a single call. Then there are fine-tuned version. For example, you might make a call to a font family for a specific weight. This is great is you only use a single font variation, but if you use lots of weights then you make lots of calls. Therefore, call the entire font family instead.
Usually, when I mess with JQuery, I break something. So, I can’t add much value here.
This is common. The slightest update in JQuery can cause these warnings.
It’s just the way its made… Like many large websites are made. If this stuff really interests you, then you want to research “Headless PWA”. It’s the next evolution in Frontend tech. Still in its infancy for Magento in my opinion. I know very little about it, because it’s built on Javascript. And I know zero about Javascript.
I should note as well, that being penalised in analytics for having “too many assets” is not as valid of an argument as it used to be. With HTTP/1.1 there can only be about 6-8 concurrent connections. So, your browser tends to download in batches, this dragging out load time. With HTTP/2 (which you find many CDNs have adopted), it increases the amount of concurrent connections to “unlimited” (you should fact check this). Therefore, removes bottlenecking.
I’m definitely just trying to knock a few “low hanging fruit” off the performance aspect. If I can do that then I’ll be satisfied. Really, the webfont is what gets me the most. EIGHTEEN! I have no idea on the jquery aspect, but if I find an effective way to attack these two aspects then I’ll definitely post up.
I need to find where these fonts are being called from so I can get rid of them. I don’t need special fonts. They are all approximately 20KB each.
Use grep to search for font imports, then cross-reference them against what you’re seeing in the source code:
grep -Rl '@import url' .
You’ll probably find a bunch in app/code/, app/design/ and pub/ (ignore static folders). Should be a relatively simply task. Plus check Porto Design settings in backend to ensure you’re only using the minimal about of font variations.