Hacker News 의견

• Tecno Spark 8C 리뷰에서 PUBG와 같은 3D 게임을 괜찮은 성능으로 실행할 수 있지만, 이것이 현대의 텍스트 중심 소셜 미디어 플랫폼이나 웹 포럼에서 글을 읽는 데 충분히 빠르다는 의미는 아니라는 점을 지적함. PUBG에서는 40fps를 달성할 수 있지만, 이러한 사이트에서 스크롤할 때 0.4fps 미만으로 떨어질 수 있음.
  • 마케팅 팀이 프론트엔드 팀에 새로운 추적 스크립트 구현을 요청할 때 사용자가 차이를 느끼지 못할 것이라고 가정하는 것에 대해 경계해야 함을 강조함.
• 세계의 다양한 불평등 수준에 대한 인식이 중요하며, 이는 중간 소득 국가들, 특히 라틴 아메리카와 동남아시아 국가들도 포함해야 함을 언급함.
  • 예를 들어, 한 달에 단위 GB가 한 자릿수인 데이터 플랜을 가진 사용자와 10년 전 미국 플래그십 스마트폰과 비슷한 RAM/CPU 프로필을 가진 사용자는 Discourse를 사용할 수는 있지만, 경험이 느리고 불쾌할 수 있음.
  • 이러한 사용자 카테고리가 CPU/RAM/디스크의 점진적 개선이 참여도를 눈에 띄게 향상시킨다는 Dan의 관찰을 설명하는 주된 부분이라고 믿음.
• 최하위 단말기 사용자들에게는 점진적 최적화가 도움이 되지 않을 수 있음을 Dan의 차트가 보여줌.
  • 유일한 해결책은 기능과 마감을 희생하여 가능한 가장 간소한 코드를 제공하는 완전히 다른 클라이언트 아키텍처일 수 있음. 즉, '라이트/베이직' 모드.
  • 불행히도 이러한 접근 방식은 성공적이라고 입증된 경우가 드물며, 미국 기반 개발자들이 성능을 위해 어떤 기능/마감을 유지하고 어떤 것을 버려야 하는지에 대한 잘못된 결정을 내리는 경우가 많음.
• 상대적으로 느린 안드로이드 폰을 사용한 최근 경험에서, 텍스트와 이미지만 제공하는 것처럼 보이는 일부 웹페이지를 로드하는 것이 매우 힘들 수 있음.
  • 이 문제는 여러 요인에 의해 복잡해짐. 하나는 오래되거나 느린 폰이 모바일용 Firefox와 같은 완전 기능의 브라우저를 사용할 수 없는 경우임. 앱 자체가 웹사이트를 열기 전에 너무 많은 리소스를 소모함.
  • 이로 인해 Firefox Focus와 같은 간소화된 브라우저로 전환해야 하지만, 확장 프로그램을 사용할 수 없음. 즉, ublock origin이 없어 웹 경험이 더욱 나빠짐.
  • 또 다른 문제는 "표준" 브라우저를 사용하지 않으면 일부 사이트가 사용 불가능해질 수 있음.
  • 이러한 상황에서, 회사들은 종종 앱을 강요하려고 함. 그 앱이 제한된 공간의 장치에서 얼마나 많은 공간을 차지하거나 얼마나 나쁘게 실행될지는 알 수 없음.
  • 많은 회사/사이트들이 느린 장치/연결을 고려하여 간소화된 버전을 제공했지만, 최근에는 이러한 버전이 점점 사라지고 찾기 어려워짐.
• 6년 된 LG 플래그십 폰에서 새로운 Galaxy로 최근 전환했을 때 성능 차이가 엄청남.
  • 그것은 출시 당시 매우 고급 폰이었고, 그렇게 오래되지 않았으며 여전히 새 것처럼 작동함.
  • 코드를 테스트하기 위해 사용하는 Galaxy S9도 같은 문제를 겪고 있음을 알고 있음.
  • Amazon을 테스트에 포함시켰으면 좋겠다는 의견을 제시함. Amazon 웹사이트는 약 4년 이상 된 모바일 장치에서 가장 최악 중 하나임.
• Raspberry Pi 3에서 YouTube가 사용 불가능하다는 데이터 포인트를 제시함.
  • 지난해에 발생한 문제로, 그 이전에는 약 10-15FPS로 "시청"할 수 있었음. 예를 들어, 수리 비디오를 작업장에서 볼 때 충분함.
  • Raspberry Pi Model B가 출시되었을 때, 저장 장치에서 1080p 비디오를 재생하고 YouTube를 시청하고 게임을 할 수 있었음.
  • YouTube가 무엇을 하고 있는지 확실하지 않지만, 이러한 문제는 심각하게 다뤄져야 함. 특히 기후 위기/변화 문제에 대해 진지하게 생각한다면, Google과 Meta와 같은 회사들이 저전력 장치에서 CPU 사이클을 소비하는 행위를 언론에서 크게 비난하고, 전반적인 UX가 더 나쁘더라도 더 효율적인 서비스를 사용해야 함.
• 48세의 사용자가 데스크톱에서 기사를 읽기 어렵다고 언급함.
  • 개발자 도구에서 body에 다음과 같은 스타일을 추가하여 가독성을 높임:

    font-size: 18px;
    line-height: 1.5em;
    max-width: 38rem;
    

  • 기술자들에게 페이지를 더 읽기 쉽게 만들기 위해 추가하는 것이 단지 64바이트라는 점을 강조함.
• 빠르고 고품질의 연결성을 위한 디자인 경향이 크다는 점을 지적함.
  • 예를 들어, 비행기 와이파이에서 Google 제품을 사용해보면, 채팅만 해도 몇 분에서 절대로 로드되지 않을 수 있고, 자주 죽어서 비싼 비용으로 다시 로드해야 함.
  • 소프트웨어 엔지니어들이 이상적이지 않은 조건에서 테스트하는 데 관심을 가졌으면 좋겠다는 바람을 표함. 낮은 속도, 간헐적 연결성, 패킷 손실은 현실임.
• "느린 장치를 가진 사용자"가 "몇 년 이상 장비를 유지하려는 사람"을 의미한다고 언급함.
  • 개발자들이 사용자의 하드웨어를 조사하고, 가장 느린 공통 시스템을 일주일에 하루 동안 사용하도록 강제해야 한다는 의견을 제시함. 효율성에 대한 관심이 없다면, 충분히 고통스러울 때 관심을 가질 수도 있음.
• Dan Luu의 글을 보통 좋아하지만, 이번 글은 목표를 놓쳤다고 느낌.
  • LCP/CPU 표는 좋지만, 그 이후로 글은 약간의 안락의자 심리학으로 변함. Discourse 창립자의 몇 가지 무작위 코멘트에서, 독자들은 소프트웨어 엔지니어들이 가지고 있다고 추정되는 태도에 대한 아이디어를 구성하도록 요청받음.
  • 이 글은 너무 부드럽고 인터넷 논쟁에 기대어 있어서 정말로 설득력이 없다고 느낌.
• 웹사이트의 접근성을 더 느린 장치를 가진 사람들, 특히 개발도상국에 사는 사람들에게 맞추고 싶다면, 더 많은 고려 사항이 있음을 언급함.
  • 더 명확한 영어와 간단한 문장 구조를 사용하면, 교육받은 미국인처럼 유창하게 영어를 읽지 못하는 사람들에게 내용을 더 접근하기 쉽게 만들 수 있음.
  • 페이지를 로드하는 데 필요한 요청 수를 줄이는 것이 좋음, 왜냐하면 대기 시간이 길 수 있고, 예를 들어 가장 가까운 클라우드플레어 엣지 노드까지의 대기 시간도 여전히 높을 수 있기 때문임.