Vuetify: [Feature Request] How to improve lighthouse score with Vuetify

[husayt]

Problem to solve

We have a number of web sites with Vuetify and Nuxt. Vuetify works great for us, only concern is performance. As soon as we add vuetify Lighthouse score tumbles down. Most probably we don't follow best practices.

Here you can see lighthouse scores:
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.sozler.im
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fkoran.center

Proposed solution

Would be great to have a realistic example (not a hello world) with a few components which would score high on LightHouse and which can be a point of reference. Maybe you will discover, indeed there is a performance issue with adding Vuetify to your website and no realistic app would score high with Vuetify on LightHouse. That will allow to identify issues and resolve them.

Meanwhile, some tips and performance guidelines for Vuetify would be appreciated by everyone here.

Thanks

[darylteo]

Just adding to this.

We have just noticed that Vuetify's implementation of buttons don't conform to Material Design/Google Accessibility Guidelines as reported by Lighthouse.

Touch Targets have to be 48dp by 48dp, but the default v-btn are only 36x36 with a margin of 8px instead.

And here I am now trying not to strangle people asking me to overwrite the margins into paddings across the site. Which would be impossible as many of the buttons have customised margins depending on which component they're in.

[johnleider]

We will look into the lighthouse issues. As far as the touch target, I'm not really sure what we can do about the buttons.

[KaelWD]

I'm guessing it would have to be something like this: https://codepen.io/anon/pen/EqZMvZ

The reference implementation doesn't do it either: https://material-components.github.io/material-components-web-catalog/#/component/button

[bengineer19]

Has there been any progress on strategies to improve Lighthouse score?
If there are ways to use Vuetify which don't significantly negatively impact performance scores in Lighthouse then it would be really useful to have some examples or a short mention in the docs.

Otherwise, it seems virtually impossible to use Vuetify in any reasonable application without dragging a lighthouse score down from green into orange or red.

[Sshuichi]

Any progress on this?
I can't make it past 80 (Without tracking nor ads..)

[johnleider]

Are any of your implementations available that I can see?

[Sshuichi]

Absolutely!
I'll try to set it up today. But on the other hand, could you show us a site that is performing +90 on lighthouse using Vuetify?

[bengineer19]

Just running vue create my-app then vue add vuetify as in the quickstart guide results in a demo page which when built has weirdly high FCP and TTI.

[Sshuichi]

@johnleider, I could reproduce the performance issues with the quickstart as @bengineer19 mentioned

[husayt]

That quickstart demo is probably the best place to start from. Then we can try to look into
problems with real websites, like for instance https://www.sozler.im/ or
https://koran.center. Google is heavily penalising these websites due to
performance issues.

[bengineer19]

Yep. I'm currently working on a new site using Vuetify which will replace a legacy site with millions of users anually. Our biggest worry about changeover is that our Google rankings will take a dive because of the lighthouse hit incurred by Vuetify.
So am very happy to help out with this if pointers are available!

[tschut]

I'm the developer for wammes-gifts.nl, and according to https://developers.google.com/speed/pagespeed/insights/ the score for desktop is fine, but on mobile it's not.

@johnleider if it helps I can probably get you access to the repo for that, at least temporary?

[micardona96]

the performance scoring is only affected in the test by running on mobile,

How could I solve this, I emphasize that it is just the simple sample app, with:

>> vue add vuetify

https://api-springboard.web.app/#/

[syskin]

After some test with vuetify on a nuxtjs application, it seems to be that bad performances come from default icons load and fonts load.

If you try to remove default values, and import your own icons and fonts, your app you can easily get 95+ lighthouse score.

[Tajnymag]

@syskin Could you please share with us, what combination of fonts/icons fares well on Lighthouse? I've tried self hosting several roboto and icon fonts and it didn't lead to much better results.

[DRoet]

I think its also good to note that the lighthouse score heavily depends on the specs of the machine its being run on, for example on a slower machine I might get around a ~80, while on a fast machine I consistently get 96-97 using the same website

[Sshuichi]

@DRoet, That's for field Data, not lab data. Lab data should be consistent as it's simulating the same shitty device for all websites.

[syskin]

@syskin Could you please share with us, what combination of fonts/icons fares well on Lighthouse? I've tried self hosting several roboto and icon fonts and it didn't lead to much better results.

I follow the doc recommendation for production deployment, I import mdi/js (https://vuetifyjs.com/fr-FR/customization/icons/#installer-les-icones-material-design-js-svg) and I override @fontface property in CSS file as it is said.

But I used the nuxtjs/vuetify module, so I don't know how you can override that properties in a classic vuetify app.

[yohane55]

I too have 38% performance for my site. But the official vuetify site also have 41%.

[Radiergummi]

To chime in here; I'm working on a new greenfield project and settled on Nuxt.js, Vuetify and TypeScript. We have Lighthouse results around 80 on desktop and 36 on mobile.
What I found to be the hardest thing during development was creating a production setup. Almost all resources online seem to assume some kind of prototype or dev environment, not an actual performance-optimized production application. The Vuetify documentation doesn't help too much here, either: There's no section dedicated to production setup or optimization. Getting icons right, for example, requires digging deep into the docs until you find the relevant snippet:

Use the SVG paths as designated in @mdi/js. This is the recommended installation when optimizing your application for production. You ONLY need to include this if you plan on using more than the default icons.

I understand this makes kind of sense given that not every application requires icons outside of Vuetify components, but it's really not obvious until you actively search for solutions to performance problems.
Is there any guide for production setups somewhere? Could we, as a community, get together and create one, to be featured in the Vuetify documentation?

[husayt]

This is the single biggest problem with Vuetify and I still found no good solution to this. My websites are being heavily penalised by search engines for that, to the point that I have already migrated some of them away and some are in process. Currently my recomendation is unfortunately, if SEF&SEO are of any concern Vuetify will not be the right choice. It's a shame, it has so many good features, but here we are.

[maartenvn]

You can easily remove unused CSS from @mdi/font by using PurgeCSS.
I am using this configuration with Vuetify and it stripped around 200kbs of the CSS bundle. Only the mdi icons used in the application are included in the actual bundle.

npm i @fullhuman/postcss-purgecss @fullhuman/vue-cli-plugin-purgecss

postcss.config.js

const purgeCSS = require("@fullhuman/postcss-purgecss");

const PRODUCTION = process.env.NODE_ENV === "production";

module.exports = {
    plugins: [
        PRODUCTION &&
            purgeCSS({
                content: [
                    `./public/**/*.html`,
                    `./src/**/*.vue`,
                    `./node_modules/vuetify/src/**/*.ts`,
                    `./node_modules/vuetify/dist/vuetify.css`
                ],
                safelist: [
                    /-(leave|enter|appear)(|-(to|from|active))$/,
                    /^(?!(|.*?:)cursor-move).+-move$/,
                    /^router-link(|-exact)-active$/,
                    /data-v-.*/
                ]
            })
    ]
};

You could even remove the ./node_modules/vuetify/dist/vuetify.css line if you whitelist the CSS classes that are injected at runtime and shave it down by almost 400kb in total (in my case).

[Radiergummi]

@maartenvn Nice! I'm absolutely going to steal this snippet 😉

On a serious note, though, that's exactly what I was talking about. Maybe we can collect stuff like this into a comprehensive guide for Vuetify production setups?

[Tajnymag]

@Radiergummi Why stop there? The snippet of @maartenvn could even be included in the official vuetify vue-cli plugin, thus everyone would get this optimization by default.

[Sshuichi]

PurgeCSS never worked out for me. But I will test this snippet hoping that it's working today.

[maartenvn]

I ended up switching to @mdi/js anyways, because the full webfont is still included with @mdi/font.

Unfortunately performance is still terrible.

[husayt]

If you look in detail at LighouseLogs for what is causing performance issues, it's not css.
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.sozler.im

Purgecss is good step, but not the solution to the problem.