Can it possibly be used with quasar 2? about quasar-app-extension-ssg HOT 20 CLOSED

Hey @Nisgrak

I'm actually implementing new features, i'm very close to finish. Then i will make this extension compatible with Quasar v2 :)

Any help is welcome, feel free to make some PR if you want.

The features i'm talking about are:

• Get routes to generate from the App router. (DONE)
• A crawler to find dynamic routes and generate them. (DONE)
• A better concurrency management with queue instead of batches. (DONE)
• Use a published version of my own Critters fork which i'm trying to make it faster to process html and css. (Almost DONE)

from quasar-app-extension-ssg.

Hello @lukadriel7,

I am working hard on it even if i didn't push a commit since a while.

I will come with a solution for FOUC issue in the next days. Then i will start working on Quasar v2. Any PR is welcome by the way :)

from quasar-app-extension-ssg.

This feature is really what quasar lacks at the moment. I hope they will integrate it to the main project.

from quasar-app-extension-ssg.

@lukadriel7,

The features i was talking about since many weeks are now done and new versions published.

Now i can work on Quasar v2 support. I will put some feedback here about the progress of the development.

Meanwhile you can upgrade to [email protected]. I will be glad if you tell me how it works, and hopefully no new issues discovered :)

from quasar-app-extension-ssg.

I just found out that Quasar 2 doesn't have SSR support yet due to some Vue issues. Anyway I'm interested to know if you plan to make this work on Quasar 2 when SSR will be available? Thanks.

from quasar-app-extension-ssg.

Hi @kosirm ,

Yes, for sure i'm planning to do it, as soon as Quasar 2 stable version with SSR support is out.

from quasar-app-extension-ssg.

Thanks!

from quasar-app-extension-ssg.

Hey @freddy38510!

Quasar just make the v2 stable, I would love to have this extension.

Thanks for all your work 😄

from quasar-app-extension-ssg.

Hello, just checking to see if the project is still being developed

from quasar-app-extension-ssg.

Hi @freddy38510 , just an fyi, I updated to the new ssg-extension version, no problems and very smooth! Removing the static list of routes also went fine. The only thing I noticed while looking css inlining is that I had an app.scss I had to move out of the css property in my quasar.conf to somewhere that gets inlined. I think the docs for the new options helped me realize I should look into where I am setting styles though I will be interested to see if quasar2/webpack5 affects the break down of separate style inlining options again.

from quasar-app-extension-ssg.

Hi @lostnet,

Thanks for the quick feedback !

About css inlining if your css is extracted to a file and dynamically inserted into the DOM, then you will see a FOUC at first load. That's where inlineCriticalAsyncCss step in to avoid this.

With inlineCriticalAsyncCss option set to true, the extension will look into every async css files and will inline their critical css (all used css rules by the document) for every page.

inlineCssFromSFC is another option that can be very useful if you don't want to have small portion of css extracted to separated css files. It will be better to have this css directly inlined in the document because of its small size. In this case just put your "small" css in <style> tag in your Vue SFC components and set inlineCssFromSFC to true.

But if you have a large app.scss file, i think that this is better to have this css extracted into its own file. There will be no FOUC, and this file will be cached by browsers.

Should i add more explanations in the README about this ?

from quasar-app-extension-ssg.

Hi @freddy38510,

Thank you for the explanation! If I did understand, I think the descriptions of inlineCssFromSFC accidentally have "critical css" where "all css" is meant and maybe a ~warning about large style sections in the inlineCssFromSFC description could make the differences clearer?

From my testing with inlineCssFromSFC and my small scss file I can see that the default of only inlining FOUC critical makes a lot of sense since the benefit is only in a situation where performance will be close to break even. But it is very helpful to be able to enable and test, I'm always a little uncertain if things that shouldn't be in the critical path aren't still interfering with performance in practice.

from quasar-app-extension-ssg.

In practice you are right, all the css is inlined. But if we refer to the Vue SSR guide, it should only inline the critical CSS.

Automatic critical CSS when using bundleRenderer.

If used during a server render, a component's CSS can be collected and inlined in the HTML (automatically handled when using template option). On the client, when the component is used for the first time, vue-style-loader will check if there is already server-inlined CSS for this component - if not, the CSS will be dynamically injected via a <style> tag.

If we want to drop rules not used by the document, we can process the html with beastcss with proper options enabled (internal: true). This way we only have critical css inlined at first load.

Ps: By critical i mean all rules used by the document, not just above-the-fold.

About the port of this extension to Quasar v2, it should be done in a few days. I did not encounter major difficulties.

About css management with quasar2/webpack5, the things are a lot simplier. Async css files are inserted into the DOM at server-side via a link tag. So there is no need to inline css coming from async css files with inlineCriticalAsyncCss option.

inlineCssFromSFC option will be removed too. Because vue-loader has not yet been updated for SSR usage with vue-style-loader.

from quasar-app-extension-ssg.

Ps: By critical i mean all rules used by the document, not just above-the-fold.

Tuning for above/bellow the fold without adding client side computation struck me as theoretically impossible since a client shouldn't communicate unique screen dimensions like a portrait mode monitor which might make many things above the fold that other clients shouldn't load. But I am interested in testing other aspects to test ways to improve mobile lighthouse performance.

I took a stab at trying to implement this quasar2/webpack5 support but it seemed a bit too difficult as a first project, but I'll take a look at how you implement it and hopefully understand enough to start experimenting with some modifications.

The other aspect of quasar2 that interests me is that the vue2 router's addition of trailing slashes was mandatory and creates a problem similar to FOUC when it routes from a landing page with no slash. I'd be happy to test out these routes with static and crawl routes on any beta versions, etc.

Thanks!

from quasar-app-extension-ssg.

@lostnet,

You are absolutely right about critical css above the fold. One possibility is to generate critical css above the fold for multiple resolutions based on average clients that uses your web app. This is not perfect and i doubt that you can obtain a significant performance improvement.

From the tests i did, purging quasar css from unused rules is a good starting point.
There is also a improvement window about fonts. The default behavior with fonts coming from @quasar/extras has a noticable impact on performance.

Could you elaborate on the trailing slashes with vue2 router's ? Are you talking about a 301 redirection in case of a missing trailing slash ? At first-load in a browser or during server side rendering ?

from quasar-app-extension-ssg.

The default behavior with fonts coming from @quasar/extras has a noticable impact on performance.

For fonts I went with the new fad of trying to get the best builtin font:

body * {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Liberation Sans", sans-serif;
}

But having a decent font uniformly loading would be a great improvement as this ends up looking better in some browsers than others.

Could you elaborate on the trailing slashes with vue2 router's ? Are you talking about a 301 redirection in case of a missing trailing slash ? At first-load in a browser or during server side rendering ?

Sorry this was just the 301 redirection, I was/am confused since some of our analytics makes it look more like we had this router issue which has come up before with our SPA setup app.

from quasar-app-extension-ssg.

There is many ways to handle fonts to improve performance and user experience. This could lead to a very long conversation :) Let's try to focus on the issue.

About 301 redirection this is handled by the app extension since v2.0.0 and specifically this commit.
The app extension is "agnostic" about if there are trailing slashes or not in your Vue router routes option, provided routes from AE ssg.routes option and crawled routes.
If Vue router's make a 301 redirection during pre-rendering of a route, the app extension pre-render the redirected route instead.

About performance i made some tests with a fresh new quasar v2 project and the ported AE SSG in development. Lighthouse reported a score of 100 points in performance with critical css inlined + async loading of stylesheets instead of 90 without it.
The only downside is that it leads to some duplicated css rules in the document. The ones that are inlined and the ones from async loaded stylesheets.

So i think i will re-add this feature in the next version of the AE with Quasar v2 support. I should backport this feature to the previous version too.

from quasar-app-extension-ssg.

Thanks @freddy38510, it works great desktop remains 95-100% with the new version and mobile has gone up to about 76-77% from 40-45% with the previous versions.

from quasar-app-extension-ssg.

Did you use the latest 3.x version with Quasar v2 supports ?

It's a great improvement on mobile, i'm glad this is useful for you. It could have a negative impact on performance if you have a lot of css inlined in the html document making it too big to download and parse for the browser. Maybe i should add a threshold option to not inline critical css above a certain size in bytes.

I'm thinking of an other feature which purge unused css from quasar css vendor file. I could use beastcss but i fear that it will drop used css rules like transitions classes and others. Another possibility is using purgecss but we need a way to know which quasar ui components is used by the app to include them in the content option. But before implementing this feature, i should test if the performance improvement is significant or not.

from quasar-app-extension-ssg.

Did you use the latest 3.x version with Quasar v2 supports ?

Yes, I'd already tested quasar v2 in spa mode so the main things to migrate were for ssr mode and use of Meta. Everything for this extension was seamless.

Maybe i should add a threshold option to not inline critical css above a certain size in bytes.

We migrated an older site so we started with a lot of legacy CSS, but we replaced pretty much all of it with close to default quasar components. For that kind of migration being able to refer to separate stylesheets in a way that wouldn't be in-lined was enough. I think a method to trim some of the unused quasar css would be more likely to have influence on our mobile lighthouse as vendor.css is 16X larger than the app.css in our build. But I will also do some manual modifications to test where we could gain points on mobile.

from quasar-app-extension-ssg.