Setting up Intersection observer was an overkill though. Iframe supports lazy loading with loading="lazy" attribute. There is always a simple solution if you look for it.
@@eljaz00 I've noticed that many senior developers are increasingly relying on code generators to complete tasks. While I understand the efficiency they provide, I personally struggle with anxiety and guilt when using AI to develop new features. After relying on AI for coding, I often feel like I'm missing out on the learning process, which diminishes the sense of accomplishment I used to get from solving problems manually. While AI is invaluable for handling repetitive tasks, I always encourage junior developers to limit its use when learning new concepts to ensure they develop a deep understanding of the fundamentals. Sorry for the rant and going on a tangent there.
If you want to fix the largest content painful issue try preloading your font in the head tag. That’s what fixed it for me. Same goes for images that give you the same problem. Nice vid!
Also could you please a little bit more about enhancing NextJS apps regarding these points: - Reduce JavaScript execution time - Reduce initial server response time - Largest Contentful Paint element Because these performance metrics are measuring NextJS bundled Javascript, which most likely the developer (like me) didn't write but NextJS produced after bundling the JS chunks (e.g: the path to next static files: /_next/static/chunks/5625-c84ebb1819d4393b.js .... etc )
why not use the next js caching feature, it wil be lighting fast if you load a cached page, and if has changing data, make sure you ravalidate the path so you get up-to-date data
@@bhk6091 No the things I meant after caching, when the page loads first it takes that much time to render... this issue occurs because next decides to load all of the scripts at once! I'm not 100% positive how next works under the hood, but it seems like the chunks that loads in the initial load are more than the user needs?! Maybe I'm wrong..
@@bhk6091 Also another thing that I considered using Sever component and SSR in almost 100% of my app, my stack is NextJS, Framer-motion (for some components in the homepage), Tailwindcss. When I inspected the analysed page from Lighthouse or Pagespeed from Google, it looks like there are more js chunks than the page needs! And it also compiles all of the css from my tailwind classes into one file? even though the main page doesn't need that many classes? Why doesn't next support lazy loading out of the box for everything?
Friendly reminder that Lighthouse/Page Speed Insights/Similar are guides, not scripture. Getting all 100s is somewhat pointless as doing so could encourage bad practices or make things worse. Defintely good to look at to see what could be improved, but of course use your on judgement too if you are optimizing a site.
Setting up Intersection observer was an overkill though. Iframe supports lazy loading with loading="lazy" attribute. There is always a simple solution if you look for it.
that's what cursor coding does to you
@@eljaz00 I've noticed that many senior developers are increasingly relying on code generators to complete tasks. While I understand the efficiency they provide, I personally struggle with anxiety and guilt when using AI to develop new features. After relying on AI for coding, I often feel like I'm missing out on the learning process, which diminishes the sense of accomplishment I used to get from solving problems manually. While AI is invaluable for handling repetitive tasks, I always encourage junior developers to limit its use when learning new concepts to ensure they develop a deep understanding of the fundamentals.
Sorry for the rant and going on a tangent there.
Thanks for pointing that out!
@@justafreak15ableAbsolutely correct
Good job babe!!!! Way to listen to feedback and adjust accordingly! Forever proud of you❤
😘 thanks babe! first like always! love you!
Pretty sure s support loading="lazy" like images no JS required
well dang, that does simplify it!
Was thinking about the same thing🙌
If you want to fix the largest content painful issue try preloading your font in the head tag. That’s what fixed it for me. Same goes for images that give you the same problem. Nice vid!
Hey Cody, there's also this lite-youtube web component which is way smaller than regular s and optimized
Also could you please a little bit more about enhancing NextJS apps regarding these points:
- Reduce JavaScript execution time
- Reduce initial server response time
- Largest Contentful Paint element
Because these performance metrics are measuring NextJS bundled Javascript, which most likely the developer (like me) didn't write but NextJS produced after bundling the JS chunks (e.g: the path to next static files: /_next/static/chunks/5625-c84ebb1819d4393b.js .... etc )
why not use the next js caching feature, it wil be lighting fast if you load a cached page, and if has changing data, make sure you ravalidate the path so you get up-to-date data
@@bhk6091 No the things I meant after caching, when the page loads first it takes that much time to render... this issue occurs because next decides to load all of the scripts at once!
I'm not 100% positive how next works under the hood, but it seems like the chunks that loads in the initial load are more than the user needs?! Maybe I'm wrong..
@@bhk6091 Also another thing that I considered using Sever component and SSR in almost 100% of my app, my stack is NextJS, Framer-motion (for some components in the homepage), Tailwindcss.
When I inspected the analysed page from Lighthouse or Pagespeed from Google, it looks like there are more js chunks than the page needs! And it also compiles all of the css from my tailwind classes into one file? even though the main page doesn't need that many classes?
Why doesn't next support lazy loading out of the box for everything?
@@mohammed.haydar you defo need to use ssr and you will see the difference
Nice job on it Cody! I will enjoy if u can post more about this kind of videos. Sometimes I got stucked on performances that is too hard to solve them
more things, can u provide some libraries from Nextjs that I can do the same improvement?
Thank you so much
Unlighthouse is better then lighthouse because it checks every page
Thanks for the amazing content Cody.
Is there a difference in deploying to Railway or Vercel for smaller apps, I mean performance wise?
lighthouse checking should only be done in production
do you think this could have been solved in nextjs with a suspense boundary and a fallback skeleton?
Is there a difference if you use useRef instead of directly accessing the element using vanilla js?
hey cody where have you deployed your web app ? digital ocean ?
and thanks for making such amazing videos man
railway for now
Friendly reminder that Lighthouse/Page Speed Insights/Similar are guides, not scripture. Getting all 100s is somewhat pointless as doing so could encourage bad practices or make things worse. Defintely good to look at to see what could be improved, but of course use your on judgement too if you are optimizing a site.
Hey Cody, do you have any videos on how to market a SaaS from zero?
I do not
@@WebDevCody really appreciate your videos, mate!
What if i want to check my other routes instead of just landing page ? And what if they are protected for logged in users or over paywall ?
Then you run the performance report from your browser. Chrome has a great one built-in
@@ben53933 Yea i guess, but as cody shown, google app said around 90% and this second website said 30% so big difference there.
Thanks to cursor for making this tutorial possible
Infinite content I could make with the bad code it gives me!
This oh no framework is less oh no than the other ones
You blocked the guy tho, right? /s
Nope I fixed it and sent a video to him with my fixed scores 😆
@@WebDevCody sure, that's one way to do it I guess 🤷 😂
your website design is bad 🙂
I'm expecting you to improve it 🤣 and make a video
If I get time!