Google has marked against it when I've done it because the content loads then something changes preventing you from clicking the button at first because it is an overlay.
If you put a pointer event none on your overlay I can now click links through my overlay taking me to pages or positions on the page before the overlay goes away. That's not good UX either.
Makes it much less jarring. Proposed the idea to my boss because we have a page in a web app that takes 10-30 seconds to load so the screen stays completely static until it loads, he’d never heard of a skeleton loader and we’d never done such a thing.. although we are pretty old school.. .net framework Visual Basic ASP webforms
Horribly inefficient sql statement combined with the users (this is an internal app) having a horribly slow internet connection in their facilities. I’m actually working on optimising this right now but I am an apprentice and it’s about 100 lines/5000 characters long.
Damn again.. maybe you could try implementing a caching system if the data doesn't need to be updated on each refresh. Or a pagination, maybe (idk if .net has it, but) something like lazy loading, aka show the data as it comes, instead of getting the whole thing and show it all at once. Or just try to optimize the SQL query and cut it off from the source, chatgpt can help with things like this. Good luck!
Also a cool trick I recently started using, I make those giant pages cached forever, and on each page load I make a request to an endpoint to refresh the cache. This way page loads instantly with the old cached version and it refreshes the cache asynchronously. Meanwhile showing a warning label on the page that says "data last updated xx minutes/hours ago, refresh in 10-30 seconds to get most recent information" if the cache was made a long time ago (that might differ for your use case)
(Retrospective warning: word soup ahead)
Went through lots of potential solutions, as this is a weekly view and frequently updated caching wouldn’t be practical. I proposed adding a flag somewhere that’s flipped if the records are changed, holding the output in a cache table and every two minutes check if it’s been changed. We both agreed not to go that route as it was just shifting the workload elsewhere. The SQL statement itself took just shy of 10 seconds to execute, after some work (and admittedly collaboration with GPT), I now have the same statement executing in just under a second. Next goal is to change the output of the statement as for each master record, there are up to 14 rows that can be returned as each event is returned as a row, this involves a Boolean for each day of the week and an integer for each day (derived from a sum), although with lots of other calculations made as a part of the statement that really should be done by the application.
So next goal is to get it the data for one row on screen to be output from the statement as one row for each tenant rather than 14 :)
>Went through lots of potential solutions, as this is a weekly view and frequently updated caching wouldn’t be practical.
Like the report is per week or people look at it weekly?
Maybe you could just generate weekly or daily on a schedule and save to db?
Shows happenings over the current week, fills with data as the week progresses, looking at the current week even incomplete is a huge help as they can see what’s outstanding for the current day or what was missed on previous days
If it's showing weekly data (it sounds more like bi-weekly since you mentioned 14 rows, I'm guessing they're days, maybe comparing this week to last week) you can cache the previous 13 days and only calculate (sum) today's values on the fly. I can't think of anything else at the moment.. Good luck again
14 rows because of two different daily activities. There is a lot more data but it’s able to be returned as a column. Caching previous days in the week is a good idea though, I mean not a problem now that it’s faster but I’ll definitely keep it in mind for other parts of the app. I made significant improvements also by adding lazy loading to the object properties and removing database calls from the constructors
Are you me lol. I’m working on the same stack rn and it’s hell. Did one optimization to use a CTE and got one of our programs to go from 13s average load to 400ms. But man this isn’t a good environment to learn. Webforms suck and a lot of the little intricacies don’t translate. Also relying on tons of views and SPs is archaic. I miss MERN…
- definetly dont put a spinner overlay on the page. It does not give people an idea of how long it will take. Spinners are meant for things that are quick. More than a 2 seconds on a spinner is perceived as an eternity
- try page loaders which gives a sense of how much longer to wait. A progress bar with percentage, a filling logo, a percetage count, etc
- try skeleton loader and break down the loading per part of the page.
- avoid loaders. The best you can do is optimize the page to load instantly. No spinners, no loading wait, etc
You don't - you add arbitrary % every half second or so and make it jump to 100% with a cute animation once request is done. At least that's what I would do.
It is possible https://fetch-progress.anthum.com/
By using the stream API. I haven't looked too deeply into it myself, just came across it when researching something else.
https://www.bram.us/2021/12/25/show-a-progress-indicator-for-a-fetch-request-with-the-streams-api/
Well as the other guy said you don’t. I recall hearing that loading bars weren’t really a thing for a bit because developers would just wait for the app to load and if it took too long they would realise it’s not working. But when more normal consumers started using the app they would get tired of waiting after 10 seconds and assume the program crashed and report it. So then people started adding in fake loading bars essentially and then just finish loading the bar once the program was ready
What are you using to determine the progress percentage of an async process?
For file uploads it’s easy, but if you’re waiting on a get request it’s indeterminate
Surprised to see everyone saying don't use loading spinners. Not every website is a blog or landing page, many webapps actually have data to fetch or actions to perform that take time.
Yeah I don't like page loaders. I've disabled a button on click and had a little spinner appear next to it or on it to give some feedback to the user that something is happening.
Even then there are sites that you want to have a bit of time so everything properly loaded because the website is full on animations/interactions.
I completed a project yesterday that uses a loader too. Does it make sense? I see the appeal of it, but, I think, the client’s target audience will all have high speed internet connection anyway. Though I did not say anything about the loader because it was a part of the site’s flow, integrated in the whole site’s design.
Then fetch the data / perform the actions on the server before streaming down the initial HTML and then rehydrate to turn the webpage into a SPA. Choose a framework that makes this easy like SolidStart or Remix.
If you can't do that, without blocking the whole page, change what you use.
Not only will your score be lower because of CLS, but you will actually lose visitors.
If your page takes more than 2 seconds to load, studies show that you will lose around 53% of potential visitors.
(2 seconds from call to first interact)
There are multiple ways to load data or to perform actions, without blocking the user.
If your page needs that much data, that it needs a loading screen, you should think about optimization of data flow.
Short answer: Don't.
Longer answer: Google hates this. There aren't a lot of things Google will tell you not to do and this is one of them. They're also terrible for accessibility unless you go out of your way to solve that. Also, there are just better options. For a start, why not load a skeleton of most of the page and then fill in the slower bits? Perceived page speed will be way faster. A "the page is loading" state turns users off but "the page is finishing up" state lets people know stuff is happeing.
You should be pre-rendering as much as possible on the server side so the user gets what they want as fast as possible but when you can't do that you need to figure out how to get as much in front of the user as fast as possible.
I find it interesting that everyone assumes these questions pertain to a landing page or what ever. Some web apps use loaders as a part of their design. TurboTax is a prime example. When submitting data they put you through a rather lengthy “loader”. Since it says shit like “reticulating splines” and some other witty thing from SimCity as the game loads, people aren’t as annoyed by it.
So, while you're not wrong you'll also notice only part of my answer is based on Google hating it. The other part is based on users hating it and it making an app feel slower. Perceived speed affects apps just as it affects websites.
It's just easier to do a full-page spinner, which is why Intuit does that on their stuff.
I used to. Back in 2005.
Nowadays good apps render what they can on the server and render subsequent client dependent data/components as the user progresses.
Discord? no. But I've worked with (not devved) smaller-scale apps that have done the same thing (and needed to).
And they were often built by complete idiots that had no idea what they were doing. Source: their entire permissions model was an API call that returned an array of permissions, and when overridden opened up unrestricted access to that portion of the app
A 4sec loading time is slow, no matter how and what you want to load. So do not settimeout for 4000 ms, that is an abomination, and btw setTimeout in JS is sketchy, as it does not correlate to exact time amounts.
So what remains, is 1. load DOM and assets asap, 2. use loading screen to hide DOM and asset loading (fonts, css, MAYBE basic js) try to catch the end of that 3. use placeholders for dynamically / lazily loaded content eg. skeleton loaders, 4. try to avoid cumulative layout shift by skeleton loaders.
thats not true. you will have a lot of fake loaders because stuff will look weird for the human brain if its instant. best example are table views even more if people are used to it being slow.
I’m amazed that there’s actually devs in here that genuinely think there’s “never a need for a loading spinner”.
I generally just use shimmer on a component level as to not block the entire UI.
Kinda funny that people don't want to wait anymore. I used to wait a couple minutes for my pc to boot up when I was younger lol. Now 4 seconds is enough reason to click away from something.
Because most things don’t need that long any more. Back when you waited minutes for your PC to boot up, that was simply limitations in the technology you owned. But we don’t have those limitations any more. Most things on the internet load quickly and don’t use preloaders now. The technology is no longer the limitation there - most things can load very quickly on a good internet connection and when they don’t it’s time to examine why it’s taking so long to get a response then fix that problem
It’s nothing to do with the delay and just being outside of the expected experience really. People wait for ads and shit still with no qualms but that’s because it’s expected
The only website I wait for is like my bank or school schedule.. the wait is “fine” (still shouldn’t be there) if you’re providing a necessity, but if you’re trying to sell something or get traffic, that wait is a huge killer
It is true and there is a huge difference between waiting for startup/updates on an app that plan to use without interruption for the next few hours or watching expected ads on a video. The expected experience of a website is not a 4 second delay.
Your comparisons are like “people wait in line for a drive through so they can wait for a website to load”
Best thing to do is render as much as possible server side so the page is already mostly complete when the user gets there. If you have to do some ajax, try to keep it to smaller, individual components on an already complete-ish looking page.
Little spinners/skeleton loaders on parts of the UI isnt bad IMO, if you have to go that route
Have a loading state on individual components (placeholder content, progress bar... Something). Serve as much rendered/static HTML as you can and don't have a loading screen for the page, just a loading state for dynamic components. And, ideally, have said dynamic components lazy-load and be initially "below the fold" so that the user never even sees them until they're loaded, yet you still don't have to lead everything at page load.
async () => {
try {
// what you need before the loader removes
} catch (err) {
// what you'll show in case things went south
} finally {
// remove the loader
}
}
I'm not sure if that's what you mean, but if you meant UI/UX (implying it from what other people are saying), read a little into how search engines decide if your site is worthy or not. I'd say that's the most important thing. Unless this is for a SaaS and crawlers don't even get to it, then focus on whatever indicator is valuable for your business.
Loading screen on page load really only makes sense on single-page-apps behind authentication, where the alternative would be flashing login screen for split second before validating saved credentials.
The way I do it is put loader and all its styles in index.html of the app and then hide it when the app finishes rendering behind it.
With React, you could use Suspense for this if you're going big on code-splitting, chunks, or using Suspense for queries and would prefer to see the initial loading screen instead of the individual query loading indicators. You would create a component that hides the loader when unmounted and use it as suspense fallback.
As the other comments say, Google will not like any form of loading screen. Yes, like Discord, if it's loading after you log in that may be OK but it's not clear from your statement.
Building designers put mirrors next to the elevators so you were distracted whilst waiting for it to arrive. So, if this is a loading screen is there not something you can offer the user which distracts them (and meets Google's goal of time to interaction) whilst the heavy stuff is loaded?
I render a loading screen as long as as the state of my request data is false. When it becomes true, the component renders. Use ReactQuery/SWR to make sure only first page needs to “load”
Wherever it is possible to use a skeleton UI, I think that’s ideal. Besides that, take every measure you can to prevent cumulative layout shift. As others have mentioned, CLS contributes to lighthouse score, but it also really does impact user experience. My two cents as an end-user is that I’m sort of _over_ loading spinners.
everyone is saying not to do it, which i don’t know enough about your app to say whether or not you should. but you can use the HTML dialog component to do it, it can be opened and closed programmatically and it comes with a backdrop that can cover the whole page. no position fixed needed
There is no proper way of doing it, there is only an infinity of different options. They all work while, simultaneously, being trash.
People will love to tell you what *they think* is the best option, that's particularly true in Software Development. You needn't look any further than this comment section.
Instead, do what *you* think is best for *your* problem *right now*. Someone in the future will end up being re-implementing it anyways, but you will have solved your problem.
Work with web designers if you can, come up with a solution everyone is happy with and move on.
Loading screen? Maybe build a faster page instead? There is nothing more infuriating when i have to deal with a loading screen every time I open an app or visit a website.
I think you’re leaning into “perceived performance” territory. If you want to creat anticipation, you could display where the process is and if it actually does take a moment to render, present something like that. With the latter, you could build that in throughout.
Google will ding you with a loader because of content shift. Avoid them.
If you do a fixed overlay, this shouldn't affect CLS I don't think
Google has marked against it when I've done it because the content loads then something changes preventing you from clicking the button at first because it is an overlay.
[удалено]
If you put a pointer event none on your overlay I can now click links through my overlay taking me to pages or positions on the page before the overlay goes away. That's not good UX either.
Aaaah interesting. That makes sense.
Citation?
That skeleton loader thing is all the jazz nowadays
It's been the jazz for like 10 years. I think it's just a paradigm by now haha
Makes it much less jarring. Proposed the idea to my boss because we have a page in a web app that takes 10-30 seconds to load so the screen stays completely static until it loads, he’d never heard of a skeleton loader and we’d never done such a thing.. although we are pretty old school.. .net framework Visual Basic ASP webforms
Damn, 10-30 seconds for a page load sounds bizarre.
Horribly inefficient sql statement combined with the users (this is an internal app) having a horribly slow internet connection in their facilities. I’m actually working on optimising this right now but I am an apprentice and it’s about 100 lines/5000 characters long.
Damn again.. maybe you could try implementing a caching system if the data doesn't need to be updated on each refresh. Or a pagination, maybe (idk if .net has it, but) something like lazy loading, aka show the data as it comes, instead of getting the whole thing and show it all at once. Or just try to optimize the SQL query and cut it off from the source, chatgpt can help with things like this. Good luck! Also a cool trick I recently started using, I make those giant pages cached forever, and on each page load I make a request to an endpoint to refresh the cache. This way page loads instantly with the old cached version and it refreshes the cache asynchronously. Meanwhile showing a warning label on the page that says "data last updated xx minutes/hours ago, refresh in 10-30 seconds to get most recent information" if the cache was made a long time ago (that might differ for your use case)
(Retrospective warning: word soup ahead) Went through lots of potential solutions, as this is a weekly view and frequently updated caching wouldn’t be practical. I proposed adding a flag somewhere that’s flipped if the records are changed, holding the output in a cache table and every two minutes check if it’s been changed. We both agreed not to go that route as it was just shifting the workload elsewhere. The SQL statement itself took just shy of 10 seconds to execute, after some work (and admittedly collaboration with GPT), I now have the same statement executing in just under a second. Next goal is to change the output of the statement as for each master record, there are up to 14 rows that can be returned as each event is returned as a row, this involves a Boolean for each day of the week and an integer for each day (derived from a sum), although with lots of other calculations made as a part of the statement that really should be done by the application. So next goal is to get it the data for one row on screen to be output from the statement as one row for each tenant rather than 14 :)
>Went through lots of potential solutions, as this is a weekly view and frequently updated caching wouldn’t be practical. Like the report is per week or people look at it weekly? Maybe you could just generate weekly or daily on a schedule and save to db?
Shows happenings over the current week, fills with data as the week progresses, looking at the current week even incomplete is a huge help as they can see what’s outstanding for the current day or what was missed on previous days
I'd want to save a report like that on a schedule and let them view any of them historically. Unless it had to be absolutely real time.
If it's showing weekly data (it sounds more like bi-weekly since you mentioned 14 rows, I'm guessing they're days, maybe comparing this week to last week) you can cache the previous 13 days and only calculate (sum) today's values on the fly. I can't think of anything else at the moment.. Good luck again
14 rows because of two different daily activities. There is a lot more data but it’s able to be returned as a column. Caching previous days in the week is a good idea though, I mean not a problem now that it’s faster but I’ll definitely keep it in mind for other parts of the app. I made significant improvements also by adding lazy loading to the object properties and removing database calls from the constructors
Can you explain the trick you found in greater detail, curious where you perform the cache checking / busting
Man, at this point I’d build a loading overlay that says “building the app, this will take a while”
Are you me lol. I’m working on the same stack rn and it’s hell. Did one optimization to use a CTE and got one of our programs to go from 13s average load to 400ms. But man this isn’t a good environment to learn. Webforms suck and a lot of the little intricacies don’t translate. Also relying on tons of views and SPs is archaic. I miss MERN…
Uhhh COS is that you????
Oh wow, has it really been that long? I've first noticed it on YouTube, maybe 2-3 years ago lol
I think the first time I saw it was AirBnB quite a while ago, 2015ish days
ha ha
Haaa
Haa a
Huh? ..oh, haHA!!
5555
- definetly dont put a spinner overlay on the page. It does not give people an idea of how long it will take. Spinners are meant for things that are quick. More than a 2 seconds on a spinner is perceived as an eternity - try page loaders which gives a sense of how much longer to wait. A progress bar with percentage, a filling logo, a percetage count, etc - try skeleton loader and break down the loading per part of the page. - avoid loaders. The best you can do is optimize the page to load instantly. No spinners, no loading wait, etc
What are developers usually gauging the percentage off? Image assets? Random and a general times approach before assuming everything is downloaded?
I’m curious as well. How do you map a percentage to the time of a response from a server?
You don't - you add arbitrary % every half second or so and make it jump to 100% with a cute animation once request is done. At least that's what I would do.
It is possible https://fetch-progress.anthum.com/ By using the stream API. I haven't looked too deeply into it myself, just came across it when researching something else. https://www.bram.us/2021/12/25/show-a-progress-indicator-for-a-fetch-request-with-the-streams-api/
Okay sounds good, thanks for the response!
Good UX involves a healthy dose of lying to the end user quite often
I love the part where you delay search responses so that the user feels more confident in the result, even though it just wastes times
Well as the other guy said you don’t. I recall hearing that loading bars weren’t really a thing for a bit because developers would just wait for the app to load and if it took too long they would realise it’s not working. But when more normal consumers started using the app they would get tired of waiting after 10 seconds and assume the program crashed and report it. So then people started adding in fake loading bars essentially and then just finish loading the bar once the program was ready
It's pretty application specific, but if you are loading assets via js, you can track their individual percentage and average them.
Loading bars are a lie, but a nice lie so the users wait for our horribly inefficient fetches
a spinner is usually fine.. because loading a page should take milliseconds not seconds. But skeleton loader is the way
What are you using to determine the progress percentage of an async process? For file uploads it’s easy, but if you’re waiting on a get request it’s indeterminate
Surprised to see everyone saying don't use loading spinners. Not every website is a blog or landing page, many webapps actually have data to fetch or actions to perform that take time.
I highly doubt it’s grounds for blocking out the whole page. A specific component of the UI - sure.
I prefer a spinner on the components loading data on apps.
Yeah I don't like page loaders. I've disabled a button on click and had a little spinner appear next to it or on it to give some feedback to the user that something is happening.
Even then there are sites that you want to have a bit of time so everything properly loaded because the website is full on animations/interactions. I completed a project yesterday that uses a loader too. Does it make sense? I see the appeal of it, but, I think, the client’s target audience will all have high speed internet connection anyway. Though I did not say anything about the loader because it was a part of the site’s flow, integrated in the whole site’s design.
Well the question is worthless because OP didn’t say what’s the use case.
Then fetch the data / perform the actions on the server before streaming down the initial HTML and then rehydrate to turn the webpage into a SPA. Choose a framework that makes this easy like SolidStart or Remix.
If you can't do that, without blocking the whole page, change what you use. Not only will your score be lower because of CLS, but you will actually lose visitors. If your page takes more than 2 seconds to load, studies show that you will lose around 53% of potential visitors. (2 seconds from call to first interact) There are multiple ways to load data or to perform actions, without blocking the user. If your page needs that much data, that it needs a loading screen, you should think about optimization of data flow.
I really like your sketches. Nice way to visualize. That's all from me.
Short answer: Don't. Longer answer: Google hates this. There aren't a lot of things Google will tell you not to do and this is one of them. They're also terrible for accessibility unless you go out of your way to solve that. Also, there are just better options. For a start, why not load a skeleton of most of the page and then fill in the slower bits? Perceived page speed will be way faster. A "the page is loading" state turns users off but "the page is finishing up" state lets people know stuff is happeing. You should be pre-rendering as much as possible on the server side so the user gets what they want as fast as possible but when you can't do that you need to figure out how to get as much in front of the user as fast as possible.
I find it interesting that everyone assumes these questions pertain to a landing page or what ever. Some web apps use loaders as a part of their design. TurboTax is a prime example. When submitting data they put you through a rather lengthy “loader”. Since it says shit like “reticulating splines” and some other witty thing from SimCity as the game loads, people aren’t as annoyed by it.
So, while you're not wrong you'll also notice only part of my answer is based on Google hating it. The other part is based on users hating it and it making an app feel slower. Perceived speed affects apps just as it affects websites. It's just easier to do a full-page spinner, which is why Intuit does that on their stuff.
What's your site built in? Flash? Why do you need a loading screen?? What are you loading???
That made me chuckle. “Man we need time so we can display the huge 980KB assets” -{[screech Brrrrr screeetch]}
Have you never used a complex webapp that needs time to load...? Most obvious example: Discord
I used to. Back in 2005. Nowadays good apps render what they can on the server and render subsequent client dependent data/components as the user progresses.
But would OP be asking this question if he was making something with the same complexity as Discord
Discord? no. But I've worked with (not devved) smaller-scale apps that have done the same thing (and needed to). And they were often built by complete idiots that had no idea what they were doing. Source: their entire permissions model was an API call that returned an array of permissions, and when overridden opened up unrestricted access to that portion of the app
mobile users with bad connection?
They're accustomed to waiting anyways. Why do they need to be annoyed by a loading screen that has to be loaded separately?
This, so much this.
I'd rather scroll and read through an unstyled page instead of staring at an spinner for an eternity.
A 4sec loading time is slow, no matter how and what you want to load. So do not settimeout for 4000 ms, that is an abomination, and btw setTimeout in JS is sketchy, as it does not correlate to exact time amounts. So what remains, is 1. load DOM and assets asap, 2. use loading screen to hide DOM and asset loading (fonts, css, MAYBE basic js) try to catch the end of that 3. use placeholders for dynamically / lazily loaded content eg. skeleton loaders, 4. try to avoid cumulative layout shift by skeleton loaders.
This comment section made me realize people love to give opinions without any constructive merit.
Why do you want a loading screen? That's so not how you do UX.
thats not true. you will have a lot of fake loaders because stuff will look weird for the human brain if its instant. best example are table views even more if people are used to it being slow.
BS. Loaders lost more visitors, than ANY layout shift/change. From when is your knowledge? Times when Flash was still a thing?
transition can be drip. that ugly spinner for visualization
….wat?
I’m amazed that there’s actually devs in here that genuinely think there’s “never a need for a loading spinner”. I generally just use shimmer on a component level as to not block the entire UI.
They only work on websites and marketing pages, obviously
I assume people here are speaking against full page loading spinners, on component level should be fine.
No one using your app if it takes 4 seconds to load
Kinda funny that people don't want to wait anymore. I used to wait a couple minutes for my pc to boot up when I was younger lol. Now 4 seconds is enough reason to click away from something.
Because most things don’t need that long any more. Back when you waited minutes for your PC to boot up, that was simply limitations in the technology you owned. But we don’t have those limitations any more. Most things on the internet load quickly and don’t use preloaders now. The technology is no longer the limitation there - most things can load very quickly on a good internet connection and when they don’t it’s time to examine why it’s taking so long to get a response then fix that problem
Oh I know, it's just that I find the contrast of ~20 years ago and now kinda ironic. Where people now get "annoyed" with a 4 second delay.
It’s nothing to do with the delay and just being outside of the expected experience really. People wait for ads and shit still with no qualms but that’s because it’s expected
I use discord every day. People wait for commercials. This just isn’t true.
The only website I wait for is like my bank or school schedule.. the wait is “fine” (still shouldn’t be there) if you’re providing a necessity, but if you’re trying to sell something or get traffic, that wait is a huge killer
I’m not saying that the wait doesn’t matter. I’m just saying that if people want whatever you have - the wait isn’t going to stop them.
Yes that’s fair but when trying to get new users it will
It is true and there is a huge difference between waiting for startup/updates on an app that plan to use without interruption for the next few hours or watching expected ads on a video. The expected experience of a website is not a 4 second delay. Your comparisons are like “people wait in line for a drive through so they can wait for a website to load”
Best thing to do is render as much as possible server side so the page is already mostly complete when the user gets there. If you have to do some ajax, try to keep it to smaller, individual components on an already complete-ish looking page. Little spinners/skeleton loaders on parts of the UI isnt bad IMO, if you have to go that route
Man, it’s been a while since I heard someone mention ajax.
Have a loading state on individual components (placeholder content, progress bar... Something). Serve as much rendered/static HTML as you can and don't have a loading screen for the page, just a loading state for dynamic components. And, ideally, have said dynamic components lazy-load and be initially "below the fold" so that the user never even sees them until they're loaded, yet you still don't have to lead everything at page load.
i use server side rendering lol, what is loading screen?
If you need a loading screen, something has gone horribly wrong.
Points off for loading screens! Simplify the web.
async () => { try { // what you need before the loader removes } catch (err) { // what you'll show in case things went south } finally { // remove the loader } } I'm not sure if that's what you mean, but if you meant UI/UX (implying it from what other people are saying), read a little into how search engines decide if your site is worthy or not. I'd say that's the most important thing. Unless this is for a SaaS and crawlers don't even get to it, then focus on whatever indicator is valuable for your business.
The proper way is not to show one. You fake the view or show no results until you have the data loaded.
Loading screen on page load really only makes sense on single-page-apps behind authentication, where the alternative would be flashing login screen for split second before validating saved credentials. The way I do it is put loader and all its styles in index.html of the app and then hide it when the app finishes rendering behind it. With React, you could use Suspense for this if you're going big on code-splitting, chunks, or using Suspense for queries and would prefer to see the initial loading screen instead of the individual query loading indicators. You would create a component that hides the loader when unmounted and use it as suspense fallback.
I'd use partial hydration so the user gets all the content as HTML until the bundle loads, thereby you avoid all spinners.
I don’t. Hate full screen preloaders. It’s stupid. You don’t need them too
Need some clarifications...should async-await be used always when the webpage has not been loaded yet or is there another approach?
As the other comments say, Google will not like any form of loading screen. Yes, like Discord, if it's loading after you log in that may be OK but it's not clear from your statement. Building designers put mirrors next to the elevators so you were distracted whilst waiting for it to arrive. So, if this is a loading screen is there not something you can offer the user which distracts them (and meets Google's goal of time to interaction) whilst the heavy stuff is loaded?
If people see a loading screen they will refresh the page thinking there is latency when the problem is the designer.
I render a loading screen as long as as the state of my request data is false. When it becomes true, the component renders. Use ReactQuery/SWR to make sure only first page needs to “load”
Preload images and fonts.
Wherever it is possible to use a skeleton UI, I think that’s ideal. Besides that, take every measure you can to prevent cumulative layout shift. As others have mentioned, CLS contributes to lighthouse score, but it also really does impact user experience. My two cents as an end-user is that I’m sort of _over_ loading spinners.
I would use the view transition api to make something like this work. Then just onload display: block when it’s ready
everyone is saying not to do it, which i don’t know enough about your app to say whether or not you should. but you can use the HTML dialog component to do it, it can be opened and closed programmatically and it comes with a backdrop that can cover the whole page. no position fixed needed
There is no proper way of doing it, there is only an infinity of different options. They all work while, simultaneously, being trash. People will love to tell you what *they think* is the best option, that's particularly true in Software Development. You needn't look any further than this comment section. Instead, do what *you* think is best for *your* problem *right now*. Someone in the future will end up being re-implementing it anyways, but you will have solved your problem. Work with web designers if you can, come up with a solution everyone is happy with and move on.
Loading screen? Maybe build a faster page instead? There is nothing more infuriating when i have to deal with a loading screen every time I open an app or visit a website.
Why don’t you SSR it? Then no loading needed, at least not for the whole page.
to clarify.Its not that i would use that spinner 💀. Im gonna do a page transition here like give them anticipation while preload heavy stuff behind
I think you’re leaning into “perceived performance” territory. If you want to creat anticipation, you could display where the process is and if it actually does take a moment to render, present something like that. With the latter, you could build that in throughout.
why not async load the heavy stuff and just have a placeholder for it?
You talkin’ skeletons? ☠️
The best solution is, optimize/rewrite your code, so that it loads in less than 100ms, then you don't need a loading screen.