웹 기술과 브라우저의 진화

안녕하세요! 웹이 정확히 어떻게 작동하는지, 그리고 신비한 브라우저에 URL을 입력하면 실제로 어떤 일이 일어나는지 궁금한 적이 있습니까? 걱정하지 마세요. 혼자가 아닙니다.  우리 대부분은 웹을 일종의 블랙박스로 취급합니다. 하지만 이 블로그를 클릭하셨으니, 내부를 들여다보고 싶으실 수도 있을 것 같습니다. 정말 환상적이에요! 호기심이 고양이를 죽일 수도 있지만, 개발자에게는 이것이 비결입니다.

작동 방식에 대해 조금 알고 있더라도 왜 이런 식으로 진화했는지 의문이 생길 수 있습니다. 나는 “현재를 이해하고 미래를 예측하거나 영향을 미치려면 과거를 알아야 한다”고 믿습니다. 아니면 일부 사람들이 제안한 것처럼, hum chronology samajhna chahiye! 이제 웹 기술과 브라우저의 발전 과정을 명확하게 설명하기 위해 단순화된 4단계로 나누어 살펴보겠습니다. 이 여정이 끝나면 웹 기술이 어떻게 발전했는지뿐만 아니라 내부적으로 어떤 일이 일어나는지, 이러한 변화가 발생한 이유와 웹의 미래에 어떤 의미가 있는지 이해하게 될 것입니다.

참고 : 정확한 일정은 아니고 이해를 돕기 위해 단계를 단순화한 것입니다.

제로스 페이즈: 선사시대 거미줄

1980년대 이전으로 돌아가보자

많은 연구자들이 데이터를 전송하거나 공유하기 위해 컴퓨터 사이에 물리적인 전선을 설치하여 미국 대학을 돌아다니고 있다고 상상해 보세요. 이러한 기술 선구자들은 파일을 공유하고 이메일을 보내기 위해 FTP(파일 전송 프로토콜) 및 SMTP(간단한 메일 전송 프로토콜)와 같은 프로토콜을 확립했습니다. 대부분은 획기적인 실험과 가끔씩 발생하는 사무실 소문에 관한 것입니다. 예전에는 원격 클라이언트를 통해 연결하고, 작성된 명령을 사용하여 디스크에 파일을 저장하거나 가져올 수 있는 서버가 있었습니다.

이것은 적은 양의 데이터에는 좋았지만 데이터가 점점 더 빠르게 증가함에 따라 특정 정보를 찾는 것이 정말 골치 아픈 일이 되었습니다. 데이터를 검색하려면 정확한 경로, 서버 주소를 알아야 하고 컴퓨터 신들을 달래기 위해 약간의 춤도 추어야 했습니다. 양말이 빨래의 소용돌이 속으로 사라지는 것처럼 귀중한 정보가 디지털 셔플 속에서 서버 전체에 흩어져 손실될 위험이 있었습니다.

첫 번째 단계: 웹의 탄생

1980년대 후반~1990년대 초반으로 들어가세요

Tim Berners-Lee 경이라는 뛰어난 영국인이 함께 왔습니다. 그는 정보관리: 제안이라는 제안서를 썼습니다. 그는 거대한 거미줄처럼 연결된 관련 정보에 대한 링크를 포함하는 텍스트를 의미하는 "하이퍼텍스트"로 알려진 비선형 텍스트 시스템 사용에 대해 이야기했습니다. 따라서 관련 데이터를 탐색하고 탐색하는 것이 더 쉬워지고 정보 손실이 최소화됩니다!

이번 제안에서 그는 상호 연결된 컴퓨터를 '웹'이라고 부르기도 했습니다. 그리고 그렇게 월드와이드웹(World Wide Web)이 탄생했습니다! 그는 거기서 멈추지 않았습니다. 그는 계속해서 HTTP(HyperText Transfer Protocol)를 발명하고 WorldWideWeb이라는 매력적인 이름의 첫 번째 브라우저(나중에 Nexus로 브랜드 변경), 첫 번째 HTTP 웹 서버 및 첫 번째 웹사이트를 개발했습니다. 초과 달성에 대해 이야기해 보세요!

• HTTP(HyperText Transfer Protocol): 클라이언트(예: 웹 브라우저)와 웹 서버(예: 웹 브라우저) 간의 정보 전송에 사용되는 일련의 규칙, 구문 및 의미 체계입니다. 웹사이트를 호스팅하는 원격 컴퓨터). 이름이 궁금하다면 처음에는 HTML 파일 전송에만 사용되었습니다. 그러나 헤더, 특히 Content-Type 헤더가 도입된 이후 이후 버전에서는 모든 유형의 데이터 전송을 지원하도록 발전했습니다.
  
  

• HTTP 웹 서버 : 이 HTTP 프로토콜을 이해할 수 있는 컴퓨터입니다. 주요 작업은 요청을 구문 분석하고 요청된 응답을 제공하는 것입니다. 현재로서는 대부분 정적 HTML, CSS, JPG 파일입니다.

여기서 HTML(Hypertext Markup Language)이 등장하여 하이퍼텍스트 개념과 SGML(Standard Generalized Markup Language)을 결합하여 문서 서식을 지정하는 데 사용했습니다. HTML의 첫 번째 버전은 매우 기본적이었습니다. 제목, 단락, 목록 및 링크를 지원했습니다. 화려한 글꼴이나 화려한 애니메이션은 없습니다.  꼭 필요한 것만 있습니다.

처음 몇 년 동안 웹은 연구자와 학계의 전담 동아리와 같았습니다. 그러다가 일부 영리한 사람들이 이미지를 표시할 수 있는 모자이크라는 브라우저를 개발했습니다. 응, 이미지야! 이로 인해 일반 대중이 웹에 더 쉽게 접근할 수 있게 되었습니다. 왜냐하면 사진 한 장이 천 줄의 가치가 있기 때문입니다(이 블로그에는 사진이 없나요?)!

브라우저 내부

그러므로 바로 위의 기능을 갖춘 브라우저 내부에서 무슨 일이 일어나고 있는지 살펴보겠습니다

사용자 인터페이스: 모든 브라우저 상단에는 열려 있는 모든 탭(또는 당시 창)을 볼 수 있는 탐색 표시줄이 있었습니다. 그 아래에는 웹사이트 주소를 입력하는 주소 표시줄이 있었습니다. 그 아래에는 입력한 웹 사이트의 내용이 표시되는 장소(뷰포트)가 있습니다. 이는 검색 엔진 이전의 일이므로 정확한 주소를 모르면 운이 없는 것입니다.  GPS나 지도 없이 장소를 찾으려는 것과 같습니다.

데이터 가져오기 : 웹사이트 주소를 입력하면 브라우저의 네트워크 모듈이 DNS 확인과 같은 작업을 수행하고 서버와 보안 연결을 설정하여 통신을 시작하여 데이터를 가져옵니다. 그러면 브라우저는 서버로부터 HTML 형식의 데이터를 수신하게 됩니다.

렌더링 엔진 : 렌더링 엔진이 HTML 구문 분석을 시작합니다. 이미지() 또는 스타일(

그런 다음 HTML에서 DOM(문서 개체 모델) 트리를 구성합니다. 여기서 각 태그는 트리의 노드가 됩니다. CSS를 가져와서 구문 분석한 후 CSSOM(CSS 개체 모델)을 구축합니다. 이 두 모델을 결합하여 렌더 트리를 만들었는데, 이를 통해 무엇을 표시하고 어떻게 표시할지 파악하는 데 사용됩니다.

• 레이아웃 및 페인팅 : 다음은 렌더링 엔진이 페이지에 있는 각 요소의 크기와 위치를 계산하는 레이아웃 단계입니다. 뷰포트(웹 페이지의 표시 영역)와 관련된 태그부터 시작하여 렌더 트리를 통해 작동합니다. 마지막으로 페인팅 단계에서는 렌더링 엔진이 해당 운영 체제의 렌더링 API와 통신하여 화면에 모든 것을 그립니다.

한계를 안고 살아가기

이 단계가 끝나면 사용자는 정적 웹사이트를 보고 페이지를 탐색할 수 있습니다. 양식을 사용하면 텍스트 입력 및 버튼 클릭과 같은 기본적인 사용자 상호 작용이 가능하며 이 양식 데이터는 일반적으로 이메일을 통해 개발자에게 전송됩니다. 하지만 여기에 문제가 있습니다. 사용자 상호 작용에 따라 콘텐츠를 동적으로 변경할 수 있는 방법이 없었습니다. 사용자는 제공된 링크만 클릭하고 탐색할 수 있었습니다.

업데이트해야 할 사항이 있나요? 서버에서 전체 새로운 HTML을 다시 가져옵니다. 사용자마다 다른 콘텐츠를 표시하고 싶으십니까? 죄송합니다. 그런 일은 일어나지 않습니다. 어떤 프로그래밍 논리도 뿌릴 수 없습니다. 즉 루프도, 조건부도, 아무것도 없습니다. 여러 페이지에 탐색 메뉴를 표시하려면 모든 곳에 동일한 코드를 복사하여 붙여넣어야 합니다.

두 번째 단계: 서버 측 스크립팅의 부상

이제 1990년대 중후반으로 넘어가 보겠습니다

개발자들은 "프로그래밍 언어와 HTML을 혼합하여 논리를 추가하고 삶을 더 쉽게 만들 수 있다면 어떨까?"라고 생각하기 시작했습니다. 이로 인해 서버 측 스크립팅이 등장하게 되었습니다. Java, PHP, Python과 같은 언어가 HTML에 포함되어 개발자는 데이터를 처리하고, 결정을 내리고, HTML을 동적으로 생성할 수 있는 코드를 작성할 수 있습니다. 이제 서버는 정적 HTML 파일을 제공하는 대신 각 사용자에 맞게 콘텐츠를 맞춤화할 수 있습니다.

이로 인해 상황이 어떻게 바뀌었나요?

브라우저의 관점에서 : 브라우저는 여전히 HTML을 가져오고 렌더링했지만 수신된 콘텐츠는 더 동적이었습니다. 양식은 더욱 강력해졌으며 POST 요청을 사용하여 서버 엔드포인트로 데이터를 보낼 수 있습니다.

• 캐싱 및 쿠키 : 브라우저에서 캐싱이 더욱 정교해졌습니다. 이미지 및 스타일시트와 같은 리소스를 로컬에 저장하여 반복적으로 가져올 필요성을 줄였습니다. 상태 비저장 HTTP 프로토콜을 통해 상태를 유지하기 위해 쿠키가 도입되었습니다. 이를 통해 서버는 클라이언트 측에 작은 데이터 조각을 저장할 수 있었고, 이 데이터는 후속 요청과 함께 다시 전송되었습니다. 이는 세션 유지, 사용자 기본 설정, 사용자 로그인 유지와 같은 작업에 매우 중요하므로 눈을 깜박일 때마다 비밀번호를 입력할 필요가 없습니다.

서버 측 : 서버가 더 바빠졌습니다. 이전에는 정적 파일을 제공하는 데 사용되는 웹 서버만 있었습니다. 그러나 이 시점에서 애플리케이션 서버, 데이터베이스 서버(사용자 데이터 제품 카탈로그 등을 저장할 수 있음) 등과 같은 몇 가지 기능이 추가로 도입되었습니다. 이제 이들은 사용자 입력을 처리하고 데이터베이스와 상호 작용하며 사용자 정의 HTML을 생성할 수 있는 스크립트를 처리했습니다. . 전자상거래가 꽃피우기 시작한 시대다. Amazon 및 eBay와 같은 회사는 사용자 검색, 선호도 및 행동을 기반으로 제품을 동적으로 표시할 수 있습니다.

• 애플리케이션 서버 : 웹 서버는 본질적으로 어떤 스크립트도 실행할 수 없으므로 이 작업을 수행하기 위해 애플리케이션 서버가 도입되었습니다. 기본적으로 애플리케이션 서버는 웹 서버 뒤에 위치합니다. 요청이 올 때마다 Web Server는 구성에 따라 이 요청이 Application Server로 이동해야 하는지 여부를 확인하고 해당 요청을 Application Server로 보냅니다. 그런 다음 응용 프로그램 서버는 요청을 처리하고 스크립트를 실행하며 HTML 파일을 생성합니다. 그런 다음 이 파일은 클라이언트에 서비스를 제공하기 위해 웹 서버로 전송됩니다. 따라서 웹 서버는 애플리케이션 서버에 대한 역방향 프록시 역할을 합니다.

JSP(JavaServer Pages) 예제

대학시절 오래된 JSP 프로젝트를 만지작거리던 기억이 납니다. 이러한 스크립트는 일반적으로 공통 구조를 따릅니다. HTML로 구성되며 논리를 추가해야 할 때마다 와 같은 특수 식별자를 사용하여 삽입됩니다. (닫기) JSP의 경우. 다음은 간단한 예입니다.

greet.jsp

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

이 예에서 사용자가 이름을 제출하면 서버는 양식 데이터가 포함된 HTTP 요청을 수신하고 정보를 처리하며 사용자를 위한 개인화된 인사말을 동적으로 생성합니다. 더 이상 일반적인 "Hello, World!"가 아닙니다. 이제 "안녕하세요, [당신의 이름]!"입니다. — 즉각적인 자아 부스트.

동적 콘텐츠 생성: 목록이나 콘텐츠를 하드코딩하는 대신 데이터베이스에서 데이터를 가져와서 반복하거나 이를 사용하여 HTML 요소를 생성할 수 있습니다. 예를 들어 과일 목록을 표시하는 경우는 다음과 같습니다.

이 기능을 데이터베이스에서 과일을 가져오는 것으로 쉽게 확장하여 콘텐츠를 더욱 역동적이고 신선하게 만들 수 있습니다!

새로운 도전

서버 측 스크립팅은 판도를 바꾸었지만 어려움도 있었습니다.

전체 페이지 새로 고침: 양식 제출이나 링크 클릭 등 서버와 상호 작용할 때마다 전체 페이지를 다시 로드해야 했습니다. 모든 로직은 애플리케이션 서버에서만 실행될 수 있었기 때문입니다. 새로운 HTML. 사용자는 자신의 작업 결과를 보기 전에 서버가 응답할 때까지 기다려야 했습니다. 이로 인해 그다지 좋지 않은 사용자 경험이 발생했습니다.

서버 로드 : 서버는 스크립트 실행부터 데이터베이스 쿼리까지 모든 처리를 처리해야 했습니다. 웹사이트의 인기가 높아짐에 따라 서버는 증가된 로드로 인해 어려움을 겪게 되었고, 이로 인해 사용자의 로드 시간이 늘어나고 지연이 발생했습니다. 우리는 인내심이 미덕이라는 것을 알고 있지만 사용자가 넉넉하게 가지고 있는 인내심은 아닙니다. 브라우저와 클라이언트측 컴퓨터의 성능이 점점 향상되면서 '왜 성능과 응답성을 향상하기 위해 일부 작업 부하를 감당할 수 없는가?'라는 의문이 제기되었습니다.

세 번째 단계: 클라이언트 측 혁명

개발자가 전체 페이지를 다시 로드하는 데 지쳐가던 시기를 입력해 보세요. 이제는 변화가 필요한 시기였으며 그 변화는 클라이언트측 스크립팅 또는 클라이언트측 렌더링(CSR)의 형태로 이루어졌습니다.

1995년 넷스케이프가 조용히 선보였던 자바스크립트가 이제 주목을 받기 시작했습니다. 이를 통해 개발자는 사용자의 브라우저에서 직접 코드를 실행할 수 있었으며, 이는 모든 상호 작용이 서버를 포함할 필요가 없다는 것을 의미합니다. 이로 인해 훨씬 ​​더 부드럽고 반응성이 뛰어난 웹 경험이 가능해졌습니다. 이 혁명에는 몇 가지 주요 요인이 관련되어 있습니다.

향상된 브라우저 기능: 시간이 지남에 따라 사용자 장치는 점점 더 강력해졌고  브라우저도 마찬가지였습니다. 따라서 일부 작업을 서버에서 브라우저로 오프로드하는 것이 분명해졌고, 이는 사용자 경험을 대폭 향상시켰습니다. 브라우저는 더 이상 수동적인 문서 뷰어가 아닙니다. 복잡한 애플리케이션을 실행할 수 있는 플랫폼으로 진화했습니다.

웹 API: 이 새로운 기능을 활용하기 위해 브라우저는 JavaScript가 브라우저 기능과 상호 작용할 수 있도록 하는 기능 집합인 Web API 를 제공하기 시작했습니다. JavaScript의 발전을 도운 몇 가지 주요 웹 API는 다음과 같습니다.

• DOM API는 브라우저에서 웹페이지의 구조와 콘텐츠와 동적으로 상호작용하고 조작하는 방법을 제공했습니다. 또한 모든 요소에 클릭, 마우스 이동 등과 같은 이벤트 리스너를 추가할 수 있어 개발자가 사용자 상호 작용에 즉시 응답할 수 있습니다. 사용자가 버튼을 클릭할 때 새 단락을 추가하고 싶으십니까? 전체 HTML을 다시 생성하지 마세요. 쉽습니다.

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

• XMLHttpRequest는 획기적인 변화를 가져왔습니다. 이를 통해 개발자는 브라우저에서 실행되는 코드에서 직접 비차단 비동기 HTTP 요청을 만들고 서버에서 데이터를 가져올 수 있었습니다. 예전에는 데이터가 일반적으로 XML 형식(그래서 이름이 붙음)으로 전송되었지만 나중에는 덜 장황하고 작업하기 쉽기 때문에 JSON이 대신하게 되었습니다. 결국 고급 기능과 더욱 깔끔한 구문을 제공하는 fetch API가 등장했습니다.

AJAX(Asynchronous JavaScript and XML): AJAX는 이러한 혁명을 뒷받침하는 핵심 기술 중 하나였습니다. 전체 페이지를 다시 로드할 필요 없이 DOM API와 XMLHttpRequest를 모두 사용하여 웹 페이지가 백그라운드에서 서버와 통신하여 필요한 데이터를 얻고 브라우저에서 직접 콘텐츠를 업데이트하는 방법을 설명했습니다. 갑자기 웹이… 대화형으로 느껴지기 시작했습니다! 이번에도 이름은 데이터 전송에 사용되는 XML에서 따왔습니다.

이로 인해 상황이 어떻게 바뀌었나요?

브라우저 관점에서: 새로운 <script> 태그는 HTML에 도입되어 개발자가 HTML에 JavaScript 코드를 직접 추가할 수 있게 되었습니다. 브라우저의 렌더링 엔진이 HTML을 구문 분석하고 <script> 태그를 사용하면 스크립트를 가져오고 실행하여(순서는 비동기 및 지연 소품에 따라 다름) 동적 콘텐츠와 대화형 기능을 허용합니다.</script>

• JavaScript 엔진: 이러한 스크립트를 평가하기 위해 브라우저에 JavaScript 엔진이 도입되었습니다. 초기 엔진은 상대적으로 단순하고 느렸지만 Google의 V8 및 Mozilla의 SpiderMonkey와 같은 최신 엔진은 크게 발전하여 더 복잡한 클라이언트 측 로직을 허용합니다.
  
  

• 이벤트 루프: JavaScript는 언어를 단순하고 가볍게 유지하기 위해 단일 스레드 스크립트 언어로 설계되었습니다. 이 디자인 선택은 제한된 컴퓨팅 리소스, 스레드로부터 안전한 DOM(Document Object Model) 유지, DOM 조작 시 경합 조건 방지
  
  

  등의 요인의 영향을 받았습니다.

  모든 스크립트 실행 및 렌더링 작업이 단일 스레드를 공유하기 때문에 JavaScript에는 기본 스레드를 차단하지 않고 비동기 작업을 처리할 수 있는 방법이 필요했습니다. 이를 달성하기 위해 JavaScript는 이벤트 루프라는 개념을 사용합니다.
  
  

  내부적으로 어떻게 작동하는지 살펴보겠습니다.
  
  

  렌더링 엔진이 HTML을 구문 분석하고 <script> 태그를 사용하면 스크립트를 가져와 JavaScript 엔진에 전달합니다. JavaScript 엔진은 실행 컨텍스트를 호출 스택에 푸시하여 스크립트 실행을 시작합니다. <br><br> </script>

  JavaScript는 브라우저에서 제공하는 Web API를 사용하여 메인 스레드를 차단하지 않고 비동기 작업을 처리합니다. 여기에는 타이머용 API(setTimeout, setInterval), HTTP 요청(fetch, XMLHttpRequest), DOM 이벤트 등이 포함됩니다. 비동기 작업이 호출되면 JavaScript 엔진은 이를 콜백 함수와 함께 Web API에 전달하고 나머지 코드를 계속 실행합니다. 이 비동기 작업이 완료되면 브라우저는 콜백을 해당 작업 큐(마이크로태스크 큐 또는 매크로태스크 큐)에 푸시합니다.
  
  

  이벤트 루프가 렌더링과 함께 이 대기열을 관리하는 방법은 다음과 같습니다.
  
  

  1. 마이크로태스크 큐: Promise, MutationObserver 콜백 등이 여기에 들어갑니다. 이 대기열은 우선순위가 가장 높습니다. 호출 스택이 비면 이벤트 루프는 마이크로태스크 대기열을 확인합니다. 대기열에 있는 모든 마이크로 작업을 실행을 위해 호출 스택에 푸시하여 하나씩 처리합니다. 마이크로 작업이 대기열에 새로운 마이크로 작업을 추가하는 경우 해당 마이크로 작업도 계속 진행되기 전에 처리됩니다.
  
  

  2. 렌더링: 마이크로태스크 대기열이 비어 있으면 렌더링 엔진이 메인 스레드를 인계받아 필요한 경우 렌더링을 수행할 수 있습니다. 여기에는 스크립트 실행 및 마이크로태스크 처리 중에 이루어진 모든 DOM 변경 사항을 반영하도록 UI를 업데이트하는 것이 포함됩니다. 이는 성능을 최적화하기 위해 프레임당 한 번씩 장치 프레임 속도를 기준으로 수행됩니다.
  
  

  3 . 매크로태스크 대기열: setTimeout, setInterval, DOM 이벤트, I/O 이벤트 등의 콜백이 여기에 들어갑니다. 이 큐는 우선순위가 가장 낮습니다. 이벤트 루프는 이 큐에서 하나의 작업을 가져와서 실행합니다. 이 작업을 실행한 후 다음 매크로 작업을 가져오기 전에 모든 마이크로 작업과 렌더링을 처리합니다.
  
  

  [콜 스택 비우기] → [모든 마이크로태스크 처리] → [필요한 경우 렌더링] → [하나의 매크로태스크 실행] → 반복

서버 측: 클라이언트 측에서 더 많은 사용자 인터페이스와 사용자 상호 작용을 처리함에 따라 서버는 초점을 옮기기 시작했습니다. 서버는 API를 통해 데이터와 비즈니스 로직을 제공하기 시작했습니다. 이는 정적 HTML 파일 제공에서 요청을 처리하고 데이터베이스와 상호 작용하며 복잡한 계산을 수행하여 데이터를 제공하는 강력한 엔진으로 발전했습니다. 단순히 브라우저에만 서비스를 제공하는 대신 다양한 클라이언트(모바일 또는 데스크톱 애플리케이션, 기타 서버 등)에 서비스를 제공하기 시작했습니다.

REST: REST라는 개념이 대중화되었습니다. REST(Representational State Transfer)는 웹 서비스 설계에 대한 일련의 지침과 제약 조건을 제공하는 아키텍처 스타일입니다. 요약하면 각 리소스는 URL로 고유하게 식별되며 GET, POST, PUT 및 DELETE와 같은 표준 HTTP 메서드는 상태 비저장 클라이언트-서버 상호 작용에서 이러한 리소스를 조작하는 데 사용됩니다. 이는 서버를 단순하고 확장 가능하며 효율적으로 만드는 데 도움이 되었습니다.

애플리케이션이 대중화됨에 따라 서버는 더 많은 데이터 처리 및 비즈니스 로직을 처리해야 했습니다. 데이터를 매우 효율적으로 처리하려면 애플리케이션 서버와 데이터베이스 서버가 필요합니다. 서버는 이러한 과도한 로드에 대처하기 위해 서버 측 캐싱, 로드 밸런싱 및 확장성, 마이크로서비스 아키텍처 등과 같은 몇 가지 새로운 기술을 구현해야 했습니다.

단일 페이지 애플리케이션: 이제 JavaScript가 클라이언트 측에서 DOM 생성 및 조작을 수행하므로 복잡한 애플리케이션을 보다 효율적으로 구축하기 위한 프레임워크가 필요했습니다. Angular, React 등과 같은 프레임워크를 입력하세요. 이것이 클라이언트 측 스크립팅의 정점입니다. 기본적으로 SPA에서는 하나의 작은 HTML 파일만 서버에서 가져옵니다. 이 파일은 하나의 <script>에 있는 전체 애플리케이션의 번들 Javascript로 구성됩니다. 꼬리표. 그리고 이 스크립트는 초기 렌더링을 포함하여 모든 사용자 상호 작용과 UI 업데이트를 자체적으로 처리합니다.<p> <strong> 여전히 어려운 과제 이 단계에서는 이전 단계의 과제를 해결했지만 다음과 같은 새로운 과제가 생겼습니다.<h3> <p><ul>초기 로드 시간 연장:<li> SPA는 대규모 초기 JavaScript 번들을 의미하는 경우가 많으며 이로 인해 초기 로드 시간이 느려질 수 있습니다 , 특히 느린 네트워크나 기기에서 더욱 그렇습니다. 사용자가 영화의 일부만 원하더라도 전체 대본을 얻어야 합니다. 마치 예고편을 보기 위해 영화 전체를 다운로드하는 것과 같습니다. 개발자는 이를 최적화하기 위해 코드 분할, 지연 로딩, 트리 쉐이킹, 축소 등과 같은 기술을 사용해야 했습니다.<p><strong><br> <br>SEO 문제:<li> 대부분의 콘텐츠가 동적으로 생성되므로 검색 엔진은 이러한 웹사이트를 색인화하는 데 어려움을 겪습니다. Google 크롤러가 귀하의 사이트를 볼 수 없으면 알아채기가 어렵습니다. 서버측 렌더링(SSR) 및 사전 렌더링과 같은 기술로 이러한 문제를 해결할 수 있습니다.<p><strong> <li><p><strong>JavaScript 피로: 매일 새로운 프레임워크, 도구 및 라이브러리가 등장하면서 개발자들은 따라잡는 데 지쳤습니다. 최신 트렌드를 따라가는 것은 끝없는 런닝머신을 달리는 것과 같습니다! 또한 선택 사항이 너무 많아 올바른 스택을 선택하는 것이 매우 어려워졌습니다.<br><br> <li><p><strong>더 빠르지만 더 느립니다: 서버 측과 클라이언트 측 성능이 모두 향상되었지만 개발자가 사용자에게 감동을 주고 싶은 만큼은 아닙니다. 또한 브라우저는 빠르고 유능하지만 기본 애플리케이션만큼 빠르거나 유능하지는 않습니다. 예를 들어 게임이나 비디오 편집기와 같은 복잡한 애플리케이션을 구축할 수 없습니다.<br><br> <h2> 네 번째 단계: 최신 웹과 그 이후 <p>현대 웹 개발 시대에 오신 것을 환영합니다 . 웹이 그 어느 때보다 더 역동적이고 강력하며 사용자 중심적인 시대입니다. 이전 단계의 문제를 해결할 수 있는 현재 일어나고 있는 몇 가지 기존 문제에 대해 논의해 보겠습니다. <h3> 단일한 완벽한 렌더링 솔루션 없음 <p>이전 단계 이후 우리는 모든 사람에게 완벽한 단일 렌더링 전략은 없다는 사실을 알게 되었습니다. 우리는 요구 사항과 제약 조건에 따라 올바른, 때로는 하이브리드 렌더링 전략을 선택해야 합니다. 다음은 그러한 렌더링 전략 몇 가지입니다 <ol> <li> <p><strong>정적 사이트 생성(SSG): JavaScript가 사용자 브라우저에서 HTML을 생성하는 클라이언트측 렌더링(CSR)과 달리 SSG는 빌드 시 전체 HTML 파일을 생성하고 사전 생성된 정적 사이트를 제공합니다. 요청 시 HTML, CSS, JS 파일을 사용자에게 제공합니다. CDN을 사용하여 응답 속도를 높일 수도 있습니다. <p>긴 초기 로드 시간 및 SEO 문제와 같은 문제를 해결합니다. 또한 매우 빠른 First Contentful Paint가 있습니다. 정적 파일은 CDN을 통해 쉽게 제공될 수 있으므로 확장 문제에 대해 크게 걱정할 필요가 없습니다. 웹사이트의 콘텐츠 대부분이 정적인 경우 이 전략을 선택할 수 있습니다. 그러나 콘텐츠가 더욱 동적이고 사용자별로 특화된 경우에는 제대로 작동하지 않습니다. 이러한 경우 아래 설명된 대로 SSG 및 CSR과 Hydration을 사용하는 하이브리드 접근 방식을 선택할 수 있습니다. 또한 서버리스 API 및 Edge 기능과 함께 SSG를 사용하는 방법에 대해 자세히 설명하는 JAMStack을 확인해 보세요. <li> <p><strong>서버 측 렌더링(SSR): 두 번째 단계와 약간 유사하지만 여기서는 비즈니스 로직이 클라이언트 측 스크립트와 분리됩니다. 기본적으로 브라우저에서 스크립트를 실행하고 HTML을 생성하는 대신 서버에서 스크립트를 실행하여 HTML을 생성하고 사용자 요청이 있을 때마다 브라우저에 제공합니다. <p>다시 말하지만, 초기 로드 시간이 길어지고 SEO 문제가 발생하는 등의 문제가 해결되었음에도 불구하고 서버 로드가 증가합니다. 또한 우리 대부분은 사용자가 상호 작용할 때마다 페이지가 다시 로드되는 것을 원하지 않으므로 수분 공급을 포함하는 CSR을 포함한 하이브리드 접근 방식을 취해야 합니다. <p><strong>수화: 기본적으로 먼저 정적 HTML 파일을 제공하여 렌더링하고 초기 렌더링 후 JavaScript를 실행하여 사용자 상호 작용을 추가합니다. 이러한 정적 웹페이지를 동적 웹페이지로 변환하는 과정을 <strong>하이드레이션이라고 합니다. 수분 공급 후 애플리케이션은 CSR 애플리케이션과 유사하게 작동합니다. <p>수분 공급에는 몇 가지 문제가 발생하므로 사용자는 콘텐츠를 보자마자 상호 작용할 수 없습니다. 이 스크립트가 다운로드되어 실행될 때까지 기다려야 하며, 이는 CSR과 유사한 동일한 오버헤드 시간을 다시 추가합니다. 이를 완화하기 위해 점진적 수화 및 부분 수화와 같은 새로운 수화 접근 방식이 있지만 구현하기가 어렵습니다. <p>Next.js, Nuxt.js, Gatsby 및 React와 같은 최신 프레임워크는 증분 정적 재생성 및 스트리밍 SSR과 같은 새로운 기술과 함께 이러한 다양한 렌더링 전략을 제공합니다. <hr> <p>정말 지쳤죠! 네, 알아요. 하지만 거의 다 끝났어요. 또한 추가되거나 제안된 기존 웹 API도 많이 있습니다. 모든 기능을 다룰 수는 없지만 Web Workers, IndexedDB 및 Shared Storage와 같은 주목할만한 API를 확인해 보세요. <p>그러나 여기에 우리가 흥미를 가질 수 있는 두 가지 주요 웹 기술이 있습니다 <h3> 웹어셈블리(Wasm) <p>최신 JavaScript 엔진이 JS를 더 빠르게 만들기 위해 노력하고 있음에도 불구하고 주요 병목 현상은 JS가 동적으로 유형이 지정되고 컴파일되지 않은 언어라는 사실에 있습니다. 이는 실제로 성능이 많이 필요한 계산을 위해 JS에 의존할 수 없음을 의미합니다. 여기가 WebAssembly가 개입하는 곳입니다. WebAssembly는 C, C, Rust 등과 같은 언어로 작성된 코드로 생성된 바이너리 명령 형식으로, 플러그인 없이 모든 최신 브라우저에서 거의 기본 속도로 실행될 수 있습니다. <p>Wasm은 JavaScript와 함께 작동하여 둘 사이에서 함수를 호출할 수 있습니다. 아직은 DOM의 직접적인 조작이나 다른 웹 API의 사용을 지원하지 않지만, 지속적인 개발을 통해 이 기능을 곧 추가하는 것을 목표로 하고 있습니다. Wasm은 게임, 이미지 처리, 비디오 편집 등과 같이 성능 집약적인 모든 웹 애플리케이션에 사용할 수 있습니다. <h3> 프로그레시브 웹 앱(PWA) <p>이렇게 광범위한 웹 생태계에서 네이티브와 유사한 웹 애플리케이션을 구축할 수 없는 이유는 무엇입니까? 프로그레시브 웹 앱은 브라우저에서 직접 설치할 수 있고 기본 앱과 유사하게 작동하며 오프라인 지원, 푸시 알림 등을 제공하는 웹 애플리케이션입니다. 그리고 하나의 코드베이스로 플랫폼 전반에 걸쳐 빠르고 매력적이고 안정적인 경험을 제공합니다.<p>PWA의 핵심 구성 요소는 메인 브라우저 스레드와 별도로 백그라운드 스크립트를 실행하는 <strong>서비스 워커입니다. 웹 앱, 브라우저 및 서버 간의 프록시 역할을 할 수 있습니다. 서비스 워커는 요청 처리 방법을 제어하고 사용자가 안정적으로 연결될 때까지 특정 작업을 지연할 수 있습니다. 이를 통해 Cache API를 사용하여 리소스를 캐시할 수 있으므로 기기가 오프라인이거나 느린 네트워크에 있을 때에도 콘텐츠를 제공할 수 있으며 다시 온라인 상태가 되면 서버와 동기화할 수 있습니다. <p>그러나 아직 모든 기능이 브라우저 전반에 걸쳐 균일하게 지원되는 것은 아닙니다. 그리고 PWA를 구축하려면 캐싱 전략과 오프라인 동작을 신중하게 계획해야 합니다. 또한 PWA는 아직 기본 앱에 비해 모든 기기 기능에 액세스할 수 없지만 이는 확대되고 있습니다. <hr> <p>웹은 아직 완벽하지 않지만, 미래를 내다보면 웹, 네이티브, 데스크톱 애플리케이션 사이의 경계가 계속 흐려지고 있습니다. 새로운 기술이 너무 많아 가능성은 무한합니다. <p>이제 블로그를 마치겠습니다. 혹시 제가 틀린 부분이 있거나 놓친 부분이 있으면 알려주시기 바랍니다. 계속 탐색하고 계속 학습하세요. 안녕! </script>

위 내용은 웹 기술과 브라우저의 진화의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!