I was drawn to frontity and was amazed to see in their frontpage this:
But as expected:
https://developers.google.com/speed/pagespeed/insights/?hl=en&url=https%3A%2F%2Ftwentytwenty.frontity.org%2F
Can’t even reach 90 PSI for such a simple site mostly because, this amount of JS cannot keep it up.
Without a consistent 90+ PSI I doubt this is adequate given the future expectations for 2021-2022:
@sir.louen please check using google chrome’s inbuilt Light-House score as google page speed also using lighthouse. please check the screenshot attached below
Thanks
I’m getting 91 for https://twentytwenty.frontity.org in PSI, but I agree with you @sir.louen that a 100 in Performance in PSI/LH is not realistic.
And not even the offical Google AMP page ranks that high:
I think that getting 90+ in a React app is already a success. Please note that on Google AMP pages, JavaScript cannot be used, so it’s much easier to get high scores.
Apart from changing the site to reflect this, I think we cannot do much more performance-wise until the React team finishes the React Concurrent mode.
Me too!! It’s taking so long! 
I’m still getting around 85-90 PSI both in Page Speed Insights and with Lighthouse report.
I saw in the twitter account a template made by a user based on frontity and it oscillates also between 85-91 PSI
From my experience with WPO I’ve seen that 90+ PSI standards are set extremely high. Obviously the experience with Frontity once loaded the page (even under 90+) is 10 times better than loading each static site separately but unfortunately this is not taken into account for this measurements that will be a thing in a couple of months.
With a plain WP site with Twenty Nineteen, 100 PSI is achievable.
Do you think this will move things forward on react implementations regarding WPO?
I just wanted to add my two cents 
.
I really love what you developed with Frontity 
(I really like WP and React, but couldn’t bring them together until now).
But after all I understood the WP-REST API is just as slow as WP itself (maybe slightly faster, but it loads all plugins for responding). So how would you achieve better performance with Frontity on the initial load, since you wait for the data from WP and put a lot of JS on top? 
I know it uses SPR, but I can’t stop thinking that highly dynamic content just weakens its advantages very much.
And if the answers to my questions are just too obvious, feel free to ignore it . I’m just starting to feel comfortable with all the technologies, so I might have my own opinion in a week or two.
And: Keep up the great work! I’m really enthusiastic about using Frontity on my next project. 
PS: My lighthouse report gives around 89 Performance Points
@josaffe welcome to Frontity, thanks a lot for your kind words and for joining the discussion as well
The answer to your questions are not obvious at all, indeed we are right now working on our documentation to make this information easier to find. A couple of days ago @luisherranz replied to a very similar question with a really detailed explanation, you can find it here: Moving an Existing WordPress website with over 5000 Articles, I hope this helps 
Please share with us your progress! We love to see what people build with Frontity
Hey guys, it looks like the main performance problem was simply embedding the fonts in the HTML. Google doesn’t like it. Once I removed it, scores went up to 95.
I have been using the Gatsby version of the TwentyTwenty theme as comparison, to make sure we are in the same performance ranges:
I removed the featured images from the Frontity version to do a fair comparison with the Gatsby version, which doesn’t have featured images.
This is totally my fault as I was the one suggesting to use the embedding technique in the first place. I’ve done a PR to fix it: https://github.com/frontity/frontity/pull/406
@luisherranz Thanks for fix can you please guide me for proper way to use fonts with frontity? can we use base64? next.js by default encode font in base64 format for better performance
React concurrent mode will have a positive impact in Frontity and all the other React frameworks, specially in terms of improving the performance metrics (First Contentful paint, First Meaningful Paint and Time to Interactive). It’s not exactly WPO, but for the Headless/Decoupled WordPress using React in the frontend is going to be a good boost.
That was what we were doing but doesn’t seem like a good idea. We’ll investigate it further but I think it’s safer to leave it deactivated for now, as it clearly impacts the performance score.
Okay.! So what is your recommended method to integrate font?
You don’t need to change anything. You should still use @font-face and add the smallest possible font to your project. I think going only with the woff2 format is the best option because it’s supported in all browsers with the only exception of IE11: https://caniuse.com/#search=woff2. It’s also the smallest format due to its compression. The only difference starting from the next version is that Frontity won’t embed the file in the HTML. But it will still serve it.
