[go: up one dir, main page]

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 문현경(Web Technologies GDE)님이 참여해 주셨습니다.>

Google에서는 스피디한 제품 디자인을 핵심 원칙으로 삼고 있습니다. AMP(Accelerated Mobile Pages) 형식은 콘텐츠의 빠르고 안정적인 로드에 도움이 되기는 하지만, 그보다 더 빠른 속도를 구현할 수 있습니다.

스마트 캐싱은 사용자가 Google 검색, Google 뉴스와 날씨 등의 제품에서 접하게 되는 거의 실시간에 가까운 AMP 사용자 경험에 있어 핵심 요소 중 하나입니다. 캐싱을 사용하면 콘텐츠를 요구하는 사용자에게 콘텐츠가 보통 물리적으로 더 가깝게 있도록 하여 바이트가 네트워크를 통해 사용자에게 도달하는 데 더 짧은 경로를 경유하도록 할 수 있습니다. 또한, 캐시와 같은 공통된 단일 인프라를 사용하면 캐시와 비교하여 콘텐츠 제공 지연 시간이 매우 상이한데다 훨씬 클 수도 있는 많은 호스트에서 콘텐츠가 제공되더라도 페이지 제공 시간을 더욱 일관되게 유지할 수 있습니다.

더욱 빠르고 안정적으로 제공하는 것이 바로 Google 검색의 AMP 사용자 경험에서 제공되는 페이지가 Google AMP Cache에서 제공되는 주된 이유입니다. 캐시의 통합 콘텐츠 제공 인프라를 통해 최적화를 구축함으로써 제공되는 수억 개의 문서 전체에 걸쳐 사용자 경험을 한층 개선할 수 있는 짜릿한 경험을 맛볼 수 있습니다. 모든 문서가 이러한 이점을 활용할 수 있도록 하는 것이 Google AMP Cache를 모든 사용자에게 무료로 제공하는 주된 이유 중 하나입니다.

이번 게시물에서는 최근에 도입한 두 가지 개선 사항에 대해 집중적으로 살펴보도록 하겠습니다. 첫 번째는 이미지 제공을 최적화한 것이고, 두 번째는 "AMP Lite"라는 프로젝트를 통해 대역폭이 제한된 조건에서 콘텐츠를 더욱 성공적으로 제공할 수 있도록 한 것입니다.


Google AMP Cache를 통한 이미지 최적화

전체 웹 환경에서 평균적으로, 이미지는 한 페이지의 총 바이트 중 64%를 차지합니다. 이는 곧 최적화를 구현할 때 이미지를 잘 활용하면 무척 큰 효과를 얻을 수 있음을 의미합니다.

이미지 최적화를 적용하면 네트워크를 통해 전달되는 바이트의 수를 효과적으로 줄일 수 있습니다. Google AMP Cache는 PageSpeed 모듈Chrome 데이터 압축에서 사용하는 이미지 최적화 스택을 활용합니다. 참고로, 위에서 설명한 변화를 이루기 위해 Google AMP Cache는 "Cache-Control: no-transform" 헤더를 무시합니다. 사이트 도구로 서버에 PageSpeed를 설치하여 해당 원본에 동일한 이미지 최적화를 구현할 수 있습니다.

다음은 저희가 구현한 몇 가지 최적화에 대한 설명입니다.

1) 표시되지 않거나 보기 어려운 데이터 제거
썸네일 이미지 및 위치정보 메타데이터와 같이 사용자에게 표시되지 않는 이미지 데이터를 삭제합니다. JPEG 이미지의 경우 화질과 컬러 샘플이 필요 이상으로 높을 경우 이를 낮춥니다. 정확히 말하자면 JPEG 화질을 85로 낮추고 컬러 샘플은 4:2:0(즉, 4픽셀당 컬러 샘플 1개)으로 낮춥니다. JPEG를 이보다 높은 화질이나 더 많은 컬러 샘플로 압축하는 경우 더 많은 바이트가 사용되지만, 시각적인 차이는 인지하기 힘듭니다.

이렇게 축소된 이미지 데이터는 철저하게 압축됩니다. 이러한 최적화를 통해 바이트 수가 40% 이상 감소하지만 사용자는 육안으로 이런 차이를 인지할 수 없다는 점이 확인되었습니다.

2) WebP 형식으로 이미지 변환

이미지 형식 중에는 상대적으로 모바일에 더 친화적인 형식이 있습니다. 따라서 저희는 지원되는 브라우저에 알맞게 JPEG를 WebP로 변환합니다. 이런 변환을 통해 화질 저하 없이 바이트를 25% 이상 더 줄일 수 있습니다.

3) srcset 추가

"srcset"이 포함되지 않은 경우 이를 추가합니다. 이는 "src" 속성은 있지만 "srcset" 속성은 없는 "amp-img" 태그에 적용됩니다. 이 작업에는 "amp-img" 태그를 확장하는 작업은 물론, 이미지를 여러 크기로 조정하는 작업도 포함됩니다. 이 작업을 수행하면 화면 크기가 작은 기기에서 바이트 수가 더 줄어듭니다.

4) 상황에 따라 더 낮은 화질의 이미지 사용

사용자가 원하거나 네트워크 속도가 매우 느린 경우 JPEG 이미지 화질을 낮춥니다(아래에서 설명하는 AMP Lite의 일부로서 수행). 예를 들어, Chrome 사용자가 데이터 세이버를 설정한 경우 JPEG 이미지 화질을 50으로 낮춥니다. 이러한 변환을 통해 JPEG 이미지의 바이트를 다시 40% 이상 줄일 수 있습니다.

다음 예에서는 최적화를 수행하기 (왼쪽)과 (오른쪽)의 이미지를 보여 줍니다. 원래는 이미지 크기가 241,260바이트였지만 1번, 2번, 4번 항목의 최적화를 적용한 후 이미지 크기가 25,760바이트로 감소합니다. 최적화를 수행한 후 이미지는 본질적으로 동일하게 보이지만, 전체 바이트의 89%나 절감되었습니다.




느린 네트워크 환경을 지원하는 AMP Lite

전 세계 많은 사람들이 연결 속도가 느린 네트워크나 RAM 사양이 낮은 기기에서 인터넷을 이용하고 있는데, 저희는 이렇게 대역폭이 크게 제한된 사용자에게는 일부 AMP 페이지가 최적화된 상태가 아니라는 점을 확인했습니다. 이 때문에 Google에서는 이러한 사용자를 위해 AMP 페이지에서 훨씬 더 많은 바이트를 삭제하는 AMP Lite도 출시했습니다.

AMP Lite를 사용해 위에서 설명한 모든 최적화를 이미지에 적용합니다. 특히, 항상 더 낮은 화질 수준을 사용합니다(위의 4번 항목 참조).

뿐만 아니라 amp-font 태그를 사용하고 글꼴 로드 제한시간을 0초로 설정하여 외부 글꼴을 최적화함으로써, 외부 글꼴이 이전에 캐시되었는지 여부에 관계없이 페이지를 즉시 표시할 수 있습니다.

AMP Lite는 베트남, 말레이시아 등 여러 국가에서 대역폭이 제한된 환경의 사용자와 전 세계에서 RAM 사양이 낮은 기기의 사용자를 대상으로 소개되고 있습니다. 참고로, 이런 최적화 과정에서 일부 이미지의 디테일이 바뀔 수도 있겠지만 광고를 포함하여 페이지의 다른 부분에는 영향을 미치지 않습니다.

* * *
요컨대, 위에서 설명한 모든 최적화에서 저희는 바이트 수가 통틀어 45% 줄어드는 것을 확인했습니다.

저희는 여기서 더 나아가 사용자 데이터의 사용 효율성을 더욱 높여 훨씬 더 빠른 AMP 환경을 제공할 수 있기를 바랍니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 김태호(Android GDE)님이 참여해 주셨습니다.>

25.1.0 Support Library가 출시됨에 따라 제품군에 ExifInterface Support Library가 새롭게 추가되었습니다. Android 7.1에서 프레임워크의 ExifInterface에 상당히 향상된 기능이 도입되면서, Support Library의 ExifInterface를 통해서는 모든 API 9 이상의 기기에서만 이러한 기능을 사용할 수 있습니다.

기본적인 사항은 종전과 같습니다. 이미지 파일에 포함된 Exif 태그를 여전히 읽고 쓸 수 있습니다. 하지만 이제는 카메라 자체, 카메라 설정, 방향 및 GPS 좌표 관련 정보를 비롯하여 140가지의 다양한 속성을 포함합니다(그 중 거의 100개는 Android 7.1/이 Support Library에 새로 추가된 것임).

카메라 앱: Exif 속성 쓰기

카메라 앱에서는 아마도 쓰기가 가장 중요한 기능일 것입니다. 속성 쓰기는 여전히 JPEG 이미지 파일로 제한됩니다. 대개의 경우 실제 카메라 캡처 작업 중에는 이 기능을 사용할 필요가 없습니다. 대신, JPEG_ORIENTATION, JPEG_GPS_LOCATION 또는 Camera1 Camera.Parameters에서 이에 상응하는 속성과 함께 Camera2 API CaptureRequest.Builder.set()를 호출합니다. 하지만 ExifInterface를 사용하면 사후에 파일을 변경할 수 있습니다(예컨대, 사용자 요청 시 위치 정보 제거).

Exif 속성 읽기

하지만 누군가에게는 이런 속성을 읽는 것이 가장 기본적인 작업일 수 있으며, 따라서 이 부분이 가장 크게 개선되었다고 볼 수도 있습니다.

먼저 JPEG 및 원시 이미지(특히, DNG, CR2, NEF, NRW, ARW, RW2, ORF, PEF, SRW 및 RAF 파일)에서 Exif 데이터를 읽을 수 있습니다. 이는 실제로는 중대한 구조적 변경 작업이었습니다. 모든 네이티브 종속 항목을 제거하고 모든 기능이 실제로 작동하는지 확인하기 위해 광범위한 테스트 세트를 빌드해야 했기 때문입니다.

content:// URI로 다른 앱에서 이미지(예: API 24 이상을 대상으로 하는 앱에서 전송한 이미지)를 수신하는 앱의 경우, ExifInterface는 이제 InputStream에서 직접 작동합니다. 따라서 임시 파일을 생성할 필요 없이 수신하는 content:// URI에서 바로 Exif 정보를 손쉽게 추출할 수 있습니다.
Uri uri; // the URI you've received from the other app
InputStream in;
try {
  in = getContentResolver().openInputStream(uri);
  ExifInterface exifInterface = new ExifInterface(in);
  // Now you can extract any Exif tag you want
  // Assuming the image is a JPEG or supported raw format
} catch (IOException e) {
  // Handle any errors
} finally {
  if (in != null) {
    try {
      in.close();
    } catch (IOException ignored) {}
  }
}

참고: ExifInterface는 원격 InputStream(예: HttpURLConnection에서 반환되는 InputStream)과는 작동하지 않습니다. content:// 또는 file:// URI로만 사용하세요.

대부분의 속성에는 단순히 getAttributeInt(), getAttributeDouble() 또는 getAttribute()(문자열의 경우) 메서드 중 적합한 메서드를 사용하면 됩니다.

이미지 표시와 관련하여 가장 중요한 속성 중 하나는 이미지 방향입니다. 이 속성은 적절한 이름의 TAG_ORIENTATION에 저장되어 있으며 ORIENTATION_ 상수 중 하나를 반환합니다. 이 값을 후처리하여 회전 각도로 변환할 수 있습니다.
int rotation = 0;
int orientation = exifInterface.getAttributeInt(
    ExifInterface.TAG_ORIENTATION,
    ExifInterface.ORIENTATION_NORMAL);
switch (orientation) {
  case ExifInterface.ORIENTATION_ROTATE_90:
    rotation = 90;
    break;
  case ExifInterface.ORIENTATION_ROTATE_180:
    rotation = 180;
    break;
  case ExifInterface.ORIENTATION_ROTATE_270:
    rotation = 270;
    break;
}

특정 Exif 태그에서 값을 추출하는 도우미 메서드가 몇 가지 있습니다. 위치 데이터의 경우, getLatLong() 메서드는 위도와 경도를 부동 소수점 값으로 제공하며 getAltitude()는 고도를 미터 단위로 제공합니다. 일부 이미지는 작은 썸네일 이미지도 포함합니다. hasThumbnail()을 사용하여 썸네일 이미지가 있는지 여부를 확인한 후 getThumbnail()을 사용하여 BitmapFactory.decodeByteArray()로 전달하는 데 가장 적합한 형식인 썸네일 이미지의 byte[] 표현을 추출할 수 있습니다.

Exif 작업: 모든 것이 선택 사항

Exif 데이터와 관련하여 이해해야 할 가장 중요한 점 한 가지는 필수 태그가 없다는 점입니다. 각각의 태그가 모두 선택 사항입니다. 일부 서비스는 특히 Exif 데이터를 제거하기도 합니다. 따라서 Exif 데이터를 전혀 지원하지 않는 이미지 형식(예컨대 흔한 PNG 또는 WebP 이미지)이나 특정 속성에 대한 데이터가 없는 이유로 인해 Exif 데이터가 없는 경우를 코드 전체에서 항상 적절히 처리해야 합니다.

ExifInterface Support Library를 다음 종속 항목과 함께 프로젝트에 추가하세요.
compile "com.android.support:exifinterface:25.1.0"

이미지가 잘못 회전되어 표시되는 것을 막는것이 목적이라면 ExifInterface Support Library가 더 나은 앱을 만들 수 있도록 도와줄 것입니다.

▶ 원문 링크

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 장정식(Google)님이 참여해 주셨습니다.>
2017년을 맞아, 지난 2016년 4분기에 출시된 기능과 현재 진행중인 프로젝트에 대해 검토해 보려고 합니다. 아래 요약한 내용에 대해 좀 더 자세한 부분은 AMP 로드맵을 참고해 주세요.


4분기 출시 기능

지난 4분기에 저희는 <amp-form>을 사용하는 양식에 대한 지원, <amp-app-banner>를 사용한 앱 설치 홍보, 그리고 amp-videoamp-youtube를 위한 음소거 자동 재생 기능 등을 통해 AMP의 형식 기능을 향상시켰습니다. 또한, 저희는 AMP-in-PWA 지원에 대한 향상된 기능도 발표했습니다. 이러한 기능으로는 PWA(Progressive Web App)를 통한 AMP 문서의 점진적 기능 향상과 PWA에서 AMP를 사용한 참조 구현이 있습니다.

광고의 경우 다중 크기 광고 요청, "플라잉 카펫" 광고 및 amp-sticky-ad에 대한 사용자 환경 개선을 위한 지원이 추가되었습니다. 한편, A4A(AMP for Ads)는 DoubleClick, TripleLift 및 Adsense 등의 지원되는 광고 서버를 통해 계속해서 AMP 형식의 광고 소재를 기반으로 한 광고 제공을 늘리고 있습니다.

Analytics 지원 역시 커뮤니티 피드백을 바탕으로 확대되었습니다. 이제, 트리거를 amp-carouselamp-form 기능에 사용할 수 있습니다.


현재 진행 중인 작업

새해에도 4분기나 그 이전에 시작된 많은 프로젝트를 계속해서 진행하고 있으므로 앞으로 몇 달 동안은 이러한 프로젝트에 집중할 계획입니다.

저희는 현재 요소 동작을 사용자 작업에 바인딩하는 메커니즘 관련 작업을 진행하고 있으며, 이 메커니즘이 구현되면 AMP 페이지에서 더 많은 유형의 대화형 환경이 지원될 것입니다. 또한, 개발자가 훌륭한 디자인의 AMP 페이지를 더욱 손쉽게 작성할 수 있도록 퀵 스타트 샘플 코드("AMP Start") 컬렉션을 제공하려고 합니다.

더불어, 기능이 더욱 풍부한 전자상거래 환경을 지원하기 위한 노력도 게을리하지 않고 있습니다. 여기에는 제품 갤러리탭을 이용한 콘텐츠 탐색은 물론, 더욱 향상된 전자상거래 분석 기능 지원이 포함됩니다.

분석 측면에서 계속 얘기하자면, 동영상 플레이어와의 사용자 상호 작용에 대한 네이티브 amp-analytics 지원 기능과 더욱 세밀화된 분석 지원 기능(예: 가변 필터 지원)도 구현하고자 합니다.

또한, 광고를 위한 UX 로드 기능이 향상되고 A4A에 대한 투자도 계속 이어질 전망입니다. 따라서 지원되는 광고 네트워크와 컨텍스트의 수가 날로 증가하고 AMP가 아닌 페이지도 AMP 광고를 표시할 수 있을 것입니다.

* * *

AMP 개발 커뮤니티 회원들께 그 동안의 노고와 의견을 주신 점에 대해 감사드립니다. 언제나처럼, 문제점이나 추가 기능에 대해서는 저희에게 알려주시기 바랍니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 양찬석(Google)님이 참여해 주셨습니다.>
2017년 초에 Play Game Services에서 몇 가지 사항이 변경될 예정입니다.

Google API 클라이언트 빌드 변경사항

작년 11월 Google Sign-In API 업데이트가 발표되었습니다. 더 나아가, 게임을 위한 사용자 인증에도 동일한 Google Sign-In API를 사용하도록 Play Game Services를 업데이트할 예정입니다. 이러한 변화에는 몇 가지 장점이 있습니다.
  • 하나의 Google API 클라이언트 연결을 통해, 플레이 게임 서비스 기능과 사용자 로그인 기능을 동시 지원
  • 단일 API로 백엔드 서버에 보낼 인증 코드 가져오기
이번 변경으로 Google 로그인과 Games API 로그인이 통합되므로, Google API 클라이언트를 생성하는 방법이 다음과 같이 변경됩니다.

// Defaults to Games Lite scope, no server component
  GoogleSignInOptions gso = new
     GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN).build();

// OR for apps with a server component
   GoogleSignInOptions gso = new
     GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN)
         .requestServerAuthCode(SERVER_CLIENT_ID)
         .build();

// OR for developers who need real user Identity
  GoogleSignInOptions gso = new
     GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN)
         .requestEmail()
         .build();

// Build the api client.
     mApiClient = new GoogleApiClient.Builder(this)
                .addApi(Games.API)
                .addApi(Auth.GOOGLE_SIGN_IN_API, gso)
                .addConnectionCallbacks(this)
                .build();
    }

 @Override
    public void onConnected(Bundle connectionHint) {
        if (mApiClient.hasConnectedApi(Games.API)) {
            Auth.GoogleSignInApi.silentSignIn(mApiClient).setResultCallback(
                   new ResultCallback() {
                       @Override
                       public void onResult(GoogleSignInResult googleSignInResult) {
                           // In this case, we are sure the result is a success.
                           GoogleSignInAccount acct = 
                              googleSignInResult.getGoogleSignInAccount());
 
                          // For Games with a server, send the auth code to your server.
                          String serverAuthCode = signInAccount.getServerAuthCode();
 
                         // Use the API client as normal.
                        Player player = Games.API.getCurrentPlayer(mApiClient);
                       }
                   }
            );
        } else {
            onSignedOut();
        }
    }

iOS 내에서 계정 생성이 더 이상 지원되지 않음

  • 현재는 신규 플레이어가 iOS에서 Play Games 계정을 만드는 기능이 지원되지 않습니다. 또한, iOS에서 Google+ 통합이 제거되었습니다. 따라서 "소셜" API는 성공을 나타내는 결과 코드를 반환하지만, 비어있는 목록을 반환합니다. 리더보드 및 멀티플레이어 초대를 위한 "표준" UI도 지원이 중단됩니다.

Google+가 더 이상 통합되지 않음

  • 작년에 발표한 바와 같이, 이번 전환 과정에서 게임 기능이 Google+에서 분리됩니다. 그 결과, 서클을 통해 플레이어들을 연결해주는 API는 작동이 중단되었지만, 멀티플레이어 초대와 소셜 리더보드에 대한 표준 UI는 계속 작동했습니다. 하지만 2017년 2월부터는 Google+ 데이터에 액세스할 수 없게 되므로 표준 UI 역시 소셜 그래프 결과를 표시하지 않을 것입니다. 이는 Android의 멀티플레이어 게임, 소셜 리더보드 및 선물 API에 영향을 미치게 됩니다. 이에 따라 이런 API가 성공적으로 반환되긴 하지만 빈 플레이어 목록이 반환될 것입니다.

Google+ 통합과 해당 C ++ 버전도 제거함으로써 지원이 중단되는 API는 다음과 같습니다.
  1. Games.Players.getPlayerSearchIntent()
  2. Games.Players.loadConnectedPlayers()
  3. Games.Players.loadInvitablePlayers()
  4. LeaderboardVariant.COLLECTION_SOCIAL
  5. Invitations.loadInvitations()
  6. RealtimeMultiplayer.getSelectOpponentsIntent()
  7. TurnBasedMultiplayer.getSelectOpponentsIntent()
  8. Requests 패키지의 모든 메서드

Play Game Services는 이러한 획기적인 변화를 통해 Google의 나머지 모바일 플랫폼과 훨씬 잘 조화를 이루고 Android 게임 개발자에게 더 나은 개발자 환경을 제공하게 될 것입니다.

<블로그 원문은 여기에서 확인하실 수 있으며, 블로그 번역 리뷰는 장정식(Google)님, 고재도(Web Technologies GDE)이 참여해 주셨습니다.>
별도의 언급이 없는 한, 아래에 기술된 변경 사항은 Android, Chrome OS, Linux, Mac 및 Windows용 최신 Chrome 베타 채널 릴리스에 적용됩니다.

HTTP 암호 및 신용카드 페이지의 “Not Secure” 경고

Chrome은 사용자들이 안전하게 탐색하도록 돕기 위해 주소 표시줄에서 아이콘을 사용해 연결 보안을 표시하고 있습니다. Chrome은 지금까지 HTTP 연결에 대해 명시적으로 Not Secure라고 표기하지 않았습니다. 저희는 모든 HTTP 사이트를 Not Secure로 표시하려는 장기 계획의 일환으로, 버전 56부터 암호나 신용카드 정보를 수집하는 HTTP 페이지를 Not Secure로 표시할 것입니다. 이 기능은 향후 몇 주에 걸쳐 점진적으로 배포될 예정입니다.

Not Secure로 레이블이 붙여지는 것을 피하기 위해서는 사이트가 HTTPS를 사용하여 트래픽을 보호하고 일반 보안 가이드라인을 따라야 합니다.

HTTP 연결을 사용하는 경우 사이트의 URL 표시줄에 Chrome ‘Not Secure’ 경고가 표시됨  



웹 블루투스

사이트는 이제 Web Bluetooth APIAndroid, Chrome OS 및 Mac에서 사용하여 블루투스 저전력(Bluetooth Low Energy, BLE) 기기와 상호 작용할 수 있습니다. Web Bluetooth API는 GATT 프로토콜을 사용하며, 이를 통해 앱 개발자는 JavaScript 단 몇 줄만으로 블루투스 기기(예: 프린터 및 LED 디스플레이)에 연결할 수 있습니다. Web Bluetooth를 물리적 웹 비콘과 결합하여 주변 기기를 검색하고 제어할 수도 있습니다. 시작하려면 GitHub에서 샘플데모를 확인하시기 바랍니다.

heart.gif
웹을 통해 BLE 지원 심박수 모니터에 연결하는 Android 기기(소스)


CSS position: sticky

Chrome은 이제 요소의 위치를 지정하는 새로운 방법인 CSS position: sticky를 지원합니다. position: sticky 요소는 상대적으로 위치가 지정되지만 사용자가 특정 스크롤 위치에 도달한 후에는position: fixed가 됩니다.


이전에는, 표시 영역의 맨 위에 고정되는 콘텐츠 헤더를 작성하려면 일반적으로 스크롤 이벤트를 듣다가 특정 임계값에서 position을relative에서 fixed로 전환했습니다. 이 솔루션은 동기화하기가 어려우므로, 작은 시각적 점프가 발생합니다. 이제, 사용자는 요소의 위치를 sticky로 간단히 지정함으로써 원하는 효과를 이룰 수 있습니다.


이번 릴리스의 기타 특징들

  • 모바일 환경에서 URL 표시줄을 표시하거나 숨기는 경우 더 이상 vh와 같은 뷰포트 단위에 맞게 초기 포함 블록 또는 요소의 크기가 조정되지 않습니다.
  • Text 입력 요소(예: <input type="text">)의 맞춤법 검사 기능이 이제 최소 512MB의 메모리와 시스템 사전을 갖춘 Android 기기에서 기본적으로 활성화되어 제공됩니다.
  • 콘텐츠가 UI 내부에 포함되도록 맞추는 데 사용되는 일반 글꼴 모음이 모든 플랫폼에 걸쳐 표준화되어 이름이 system-ui로 변경되었습니다.
  • Referrer-Policy HTTP 헤더가 추가되었으므로 사이트가 사용자의 세션 ID 또는 기타 개인 정보를 유출하지 않고 URL을 통해 사이트 트래픽을 전달할 수 있습니다.
  • KeyboardEvent.isComposing()을 통해서는 사이트에서 사용자가 키보드 이벤트를 직접 모니터링하지 않고 최신 KeyboardEvents를 기반으로 입력하는지 여부를 결정할 수 있습니다.
  • Android용 Chrome에서는 다른 모바일 브라우저와 맞추기 위해 이제 휴대폰 연결 시 동영상에 대한 기본 preload 속성을 metadata로 설정하여 미리보기 이미지 및 시간 정보를 표시합니다.
  • Chrome에서는 이제 TLS 1.3을 지원하고 draft-18을 기반으로 하는 1-RTT를 포함합니다.
  • 사이트는 ImageBitmapRenderingContext를 사용하여 ImageBitmap 형식의 픽셀 데이터를 렌더링하여 메모리 사용량 및 합성 오버헤드를 줄일 수 있습니다.
  • 사이트는 pinch-zoom CSS touch-action 속성을 사용하여 손가락 모으기 제스처에 응답할 수 있습니다.
  • ConstantSourceNodeAudioParam과 혼합된 상수 출력을 생성하는 새로운 오디오 소스 노드입니다.
  • Web Audio ChannelSplitterNode 인터페이스에는 새로운 읽기 전용 특성인 channelCount가 있습니다. 이 특성은 createChannelSplitter()에서 numberOfOutputs로 정의됩니다.
  • PannerNode.rolloffFactor가 이제 소스가 듣는 사람으로부터 멀리 이동되는 경우 볼륨 감소율을 규정하는 PannerNode 거리 모델의 공칭 범위로 고정합니다.
  • window.prompt()는 페이지가 현재 포그라운드에 있지 않는 경우 해당 상위 탭에 더 이상 포커스를 두지 않습니다.
  • Windows의 동작과 맞추기 위해 Chrome 확장 프로그램에서는 이제 Mac의 기본 검색, 시작 및 홈페이지 설정을 Chrome Settings Overrides API로 재정의할 수 있습니다.

지원 중단 및 상호 운용성 개선 사항

  • WebAudio API는 speedOfSound, dopplerFactorsetVelocity를 비롯하여 지원이 중단된 Doppler API를 더 이상 포함하지 않습니다.
  • 표준 적합성을 향상시키기 위해 RTCPeerConnection에서는 이제 iceTransportPolicyRTCConfiguration 매개변수로 받으며 iceTransports도 허용합니다.
  • webkitRTCPeerConnection이 여전히 남아 있기는 하지만 RTCPeerConnection을 이제 webkit 접두사 없이 사용할 수 있습니다.
  • 공백이 아닌 유니코드 제어 문자가 이제 무시되지 않고 사양에 따라 렌더링됩니다.
  • reflected-xss 지시문이 X-XSS-Protection 헤더의 래퍼일 뿐이며 다른 추가 기능을 제공하지 않았으므로 콘텐츠 보안 정책 2에서 제거되었습니다.
  • MediaStreamTrack.getSources() 메서드 지원 기능이 제거되었으며 MediaDevices.enumerateDevices()로 대체되었습니다.
  • CSP referrer 지시문이 더 이상 지원되지 않으며, 새 Referrer-Policy 헤더로 대체되었습니다.
  • ShadowDOM의 slotchange 이벤트가 발생해도, 슬롯assignedSlot에서 더 이상 다시 발생하지 않습니다.  
  • 레거시 CBC 모드의 ECDSA 암호화 집합 ECDHE_ECDSA_WITH_AES_128_CBC_SHAECDHE_ECDSA_WITH_AES_256_CBC_SHA가 제거되었으며 최신 암호화 집합(예: ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)으로 대체되었습니다.
  • SHA-1에 대한 종속성을 줄이고 TLS 1.3의 새로운 ECDSA 처리에 맞추기 위해 SHA-1 및 SHA-512를 모두 사용하는 ECDSA가 제거되었습니다.
  • Chrome이 더 이상 터치 스크롤(예: touchstarttouchmove)을 나타내는 입력이 수행되는 동안 팝업이 열리는 것을 허용하지 않습니다.
  • link preload를 사용하여 선언전 가져오기를 통해 트리거되지 않는 경우 사이트에서 더 이상 유효하지 않은 type 또는 language 특성(예: type="python")이 설정된 스크립트에 대한 가져오기 작업을 시작하지 않습니다.
  • MIDIMessageEvent.receivedTime has been deprecated in favor of Event.timeStamp, since Event.timeStamp now supports high-resolution monotonic time instead of epoch time.

게시자: Vincent Scheib, Web Bluetooth Orthodontist