성능 문제로 간주되기 전에 화면이 표시되는 데 얼마나 걸립니까?


12

다양한 화면이있는 Windows 응용 프로그램 개발에 참여하고 있습니다. 그 중 하나가 스피너 나 화면이로드되고 있다는 표시없이 10 초가 걸립니다. 나는 이것이 심각한 성능 문제라고 생각하지만 걱정하는 유일한 사람 인 것 같습니다.

내가 열심 인거야? 화면이 나타날 때까지 허용되는 시간은 얼마입니까?


2
개발자의 레인지 머신에서 10 초입니까, 아니면 평균 사용자의 요즘 머신에서 10 초입니까?
MZB

@MZB : 개발자 컴퓨터에서 10 초 ...
blue

@ 8kb 화면이 오래 표시되는 문제는 무엇입니까?
AttackingHobo

3
내가 잘 기억한다면 안드로이드는 5 초 후에 화면이 멈추는 것을 고려할 것입니다. 그런 다음 사용자가 응용 프로그램을 종료하거나 계속 기다릴 것인지 묻습니다.
Federico klez Culloca

답변:


23

이것은 오래된 연구이지만 10 초는 나쁩니다.

http://www.useit.com/papers/responsetime.html

페이지에서 :

응답 시간에 대한 기본 조언은 30 년 동안 거의 동일했습니다 [Miller 1968; Card et al. 1991] :

• 0.1 초는 사용자가 시스템이 즉각적으로 반응하고 있다고 느끼게하는 한계에 관한 것이므로 결과를 표시하는 것 외에는 특별한 피드백이 필요하지 않습니다.

• 1.0 초는 사용자가 지연을인지하더라도 사용자의 생각 흐름이 중단되지 않는 한계에 가깝습니다. 일반적으로 0.1 초 이상 1.0 초 미만의 지연 동안에는 특별한 피드백이 필요하지 않지만 사용자는 데이터에서 직접 작동하는 느낌을 잃게됩니다.

• 10 초는 사용자의주의를 대화에 집중시키는 한계입니다. 지연 시간이 길어질 경우 사용자는 컴퓨터가 완료되기를 기다리는 동안 다른 작업을 수행하기를 원하므로 컴퓨터가 완료 될 때를 나타내는 피드백이 제공되어야합니다. 사용자가 무엇을 기대해야하는지 알 수 없으므로 응답 시간이 매우 가변적 일 경우 지연 동안 피드백이 특히 중요합니다.


1
사용자가 소프트웨어를 깨뜨 렸는지 궁금해하지 마십시오. 완료된 예상 시간과 함께 즉시 나타나는 작은 알림 창조차도 최종 사용자의 불안을 멈추고 통제력을 느끼게합니다.
Patrick Hughes

4
나는 타이밍 데이터가 오래되어서 약 20 년 전에 쓰여졌다 고 주장했다. 오늘날 모든 데스크탑에서 매우 강력한 시스템과 실시간 상호 작용의 확산으로 사람들은 10 초보다 훨씬 짧은 응답 시간에 익숙합니다.
Eran Galperin

2
피드백없이 화면이 표시 되기에는 10 초가 너무 길다는 데 동의합니다. ~ 2 초 이상 걸리는 작업의 경우 진행률 막대가 아닌 경우 프로그램이 무언가를 수행하고 있음을 보여주기 위해 (적어도) 물레를 넣을 것입니다 .
DMan

1
데이터는 개인의 사고 과정과 관련이 있습니다. 따라서 아마도 구식이 아닐 것입니다. 그러나 현재 피드백이없는 10 초는 너무 깁니다. 인식 된 응답 성을 향상시키는 기술이 있습니다.
BillThor

9

모래 시계가없는 2 초 이상 나는 이미 꽤 회의적입니다. 사람들마다 다른 기대가 있지만 버튼을 클릭했거나 거의 모든 사람을 괴롭히는 것을 인정하기 위해 피드백없이 10 초를 기대합니다. 사용자를 귀찮게하는 것이 중요한지 여부는 또 다른 질문입니다.


동의- "대기 커서"또는 다른 표시가 매우 빠르게 나타납니다. UX 규범을 기준으로 2 초가 아닌 0.1 ~ 0.25 초와 같이 보입니다.
밥 머피

3

이 응용 프로그램의 의도 된 사용자는 어떻게 생각합니까? 그들이 괜찮다면 걱정하지 마십시오. 많은 양의 데이터를 처리해야하는 일부 응용 프로그램은 열기 전에 창 열기 명령이 약간 지연되는 것이 좋습니다.

그것은 시작 화면 또는 진행률 표시 줄 또는 추가 할 수 있다면 무언가 가 그 좋은 것 작동하고 있음을 사용자에게 나타냅니다. 테스트에서 창을 표시하는 데 2-4 초 이상이 걸린다는 것을 보여 주면 일반적으로 일종의 진행률 표시기를 추가하려고합니다.


1

사용자에게 피드백이 표시 되려면 2 초 이상 걸리지 않아야한다는 규칙을 고수합니다.

2 초 이내에 전체 페이지를로드 할 수없는 시간이 있기 때문에 의견을 보내주었습니다. 처음 2 초 후에 사용자에게 무엇을 기대해야하는지 알려 주어야합니다.


1

DKnight는 그의 답변에서 좋은 연구를 인용 했지만 , 고려해야 할 또 다른 사항은 시스템의 성능 요구 사항입니다. 사용자가 시간에 민감한 작업을하고 있거나 어떤 이유로 빠른 요구 사항이 필요한가요? 어떤 응답 시간을 원하는지 사용자에게 물어볼 수있는 경우, 특히 허용 가능한 최소 시간 측면에서 가장 좋습니다. 관찰을 통해 사용성 테스트를 수행하면 전체적인 사용성에도 도움이되며 특정 작업을 수행 한 후 사용자가 대기하면서 좌절감을 느끼는 경우 시스템의 해당 부분의 성능을 다시 확인해야합니다.

그러나 일반적으로 10 초가 실제로 오래 걸린 것으로 생각됩니다. 오래 실행되는 작업이 있으며,이 경우 실제로 시스템이 작동 중임을 사용자에게 알리고 계속 대기하는 것이 중요합니다.


0

나는 10 초가 확실히 너무 많다는 데 동의합니다. 소프트웨어 하우스에서 인트라넷 응용 프로그램을 작업했으며 (직원이 내부적으로 만 사용) 페이지를로드하는 동안 최대 지연 시간은 5 초였습니다. 이것은 나에게 한계였습니다.

그러나 다른 내부 응용 프로그램을 보았지만 실제로는 매우 복잡했지만 로딩 시간이 극적인 곳이었습니다. 최악의 상황에서 실행 된 레코드 / 쿼리의 수초로 인해 약 2 분이 걸렸습니다! 그러나 이것은 물론 일반적인 맥락과는 거리가 멀다.

따라서 좋은 응답 서비스를 제공하는 데 3 초 또는 4 초가 한계라고 결론을 내릴 것입니다.


0

이것은 성능 문제가 아니라 GUI 문제입니다. 사용자는 프로그램의 기능을 말해야하며 1-2 초 이상 걸리면 진행률 표시 줄이 표시되어야합니다.

즉,이 경우, 이것에 대한 이유가있을 수 있습니다 말했다 사용 빠른 것으로,하지만 당신이 무엇을 요구하지 않습니다.

이러한 응용 프로그램의 일반적인 문제는 실제 메모리가 부족하여 디스크 I / O가로드 및 스왑의 병목 현상이되는 것입니다. 데이터 집합이 너무 커져서 O (N ^ 3) 알고리즘이 빛을 발할 수도 있습니다.


진행률 표시 줄은 지속 시간 또는 총 작업이 알려진 경우에만 사용해야한다고 생각합니다. 그렇지 않으면 더 불확실한 것이 사용되어야합니다.
토마스 오웬스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.