웹 사이트 최적화 초보자 가이드

Pexels의 이미지 제공.

저는 초보자이며 Google의 최적화 순위에서 99/100을 달성 할 수있었습니다. 내가 할 수 있다면 당신도 할 수 있습니다.

당신이 나와 같다면 당신은 증거를 좋아합니다. 다음은 내가 유지 관리하고 최근에 최적화하는데 시간을 보낸 웹 사이트 인 번거롭지 않은 비트에 대한 Google의 PageSpeed ​​Insights 결과입니다.

내 PageSpeed ​​Insights 점수의 스크린 샷.

이 결과가 매우 자랑 스럽지만 몇 주 전에 웹 사이트를 최적화하는 방법에 대한 단서가 없었 음을 강조하고 싶습니다. 내가 오늘 당신과 공유해야 할 것은 단순히 인터넷 검색 및 문제 해결의 많은 결과, 내가 당신을 아끼고 싶은 고통입니다.

이 기사는 각 최적화에 대한 하위 섹션으로 구성되어 있습니다.

나는 결코 전문가는 아니지만 아래 기술을 구현하면 결과가 나타날 것이라고 확신합니다.

이미지

Pexels의 이미지 제공 (그리고 확실히 Medium에 의해 최적화 됨).

초보 웹 개발자로서 이미지는 내가 생각한 것이 아닙니다. 웹 사이트에 고품질 이미지를 추가하면보다 전문적으로 보일 수 있지만 페이지로드 시간에 미치는 영향을 고려하지 않았습니다.

이미지를 최적화하기 위해 가장 중요한 것은 압축이었습니다.

되돌아 보면, 이것은 시작부터 상당히 직관적 이었어 야했지만 그것은 나에게는 맞지 않았으므로 어쩌면 당신에게도 그렇지 않을 것입니다.

이미지를 압축하는 데 사용한 서비스는 이미지를 업로드하고 원하는 압축 수준을 선택한 다음 압축 된 이미지를 다운로드하는 사용하기 쉬운 웹 사이트 인 Optimizilla였습니다. 일부 리소스의 경우 크기가 70 % 이상 감소하여로드 시간이 더 길어졌습니다.

Optimizilla는 이미지 압축 요구에 대한 유일한 선택은 아닙니다. 사용할 수있는 일부 독립형 오픈 소스 소프트웨어는 ImageOptim for Mac 또는 FileOptimizer for Windows입니다. 빌드 도구를 사용하여 압축하려는 경우 트릭을 수행하는 Gulp 및 WebPack 플러그인이 있습니다. 당신이하는 한, 당신이하는 방식은 중요하지 않습니다. 성능 향상은 최소한의 노력으로 가치가 있습니다.

사용 사례에 따라 파일 형식을 살펴 보는 것도 좋습니다. 일반적으로 jpg는 png보다 작습니다. 하나 또는 다른 것을 사용하는지의 주요 차이점은 이미지 뒤에 투명성이 필요한지 여부입니다. 투명도가 필요한 경우 png를 사용하고 그렇지 않으면 jpg를 사용합니다. 여기서 두 가지의 장단점을 자세히 살펴볼 수 있습니다.

또한 Google은 매우 달콤한 webp 형식을 제공하지만 아직 모든 브라우저에서 지원되는 것은 아니므로 사용하는 것을 주저합니다. 앞으로 더 많은 지원을 받으십시오!

위에서 보여준 결과를 얻기 위해 이미지를 압축하는 것 이상을 수행하지는 않았지만 여기에서 더 최적화하려면 훌륭한 기사가 있습니다.

비디오

Pexels의 Terje Sollie의 사진.

저는 현재 진행중인 프로젝트에서 비디오를 사용하지 않았기 때문에이를위한 최고의 리소스라고 생각하지 않기 때문에 간단히 설명하겠습니다.

이것은 내가 프로가 무거운 짐을지게 할 가능성이 높은 상황 중 하나입니다. Vimeo는 비디오 연결 속도를 낮추고 성능을 최적화하기 위해 비디오를 압축하는 비디오 호스팅을위한 훌륭한 플랫폼을 제공합니다.

또한 YouTube에서 비디오를 호스팅 한 다음이 youtube-dl 도구를 사용하여 비디오를 웹 사이트의 요구에 맞게 구성하면서 Youtube에서 다운로드 할 수 있습니다.

다른 가능한 해결책은 Brightcove, Sprout 또는 Wistia를 확인하십시오.

Gzip

알 겠어요? 지퍼? Pexels의 이미지 제공.

처음 웹 사이트를 배포했을 때 gzipping이 무엇인지 전혀 몰랐습니다.

간단히 말해, gzip은 대부분의 브라우저가 이해하고 있으며 사용자가 그 상황을 알지 않아도 뒤에서 뒤쳐 질 수있는 파일 압축 형식입니다.

응용 프로그램을 호스팅하는 위치에 따라 gzipping은 서버가 파일을 보낼 때 파일을 gzip으로 지정하도록 구성 스위치를 뒤집는 것처럼 간단 할 수 있습니다. 필자의 경우 내 웹 사이트는 Heroku에서 호스팅 되며이 옵션은 제공하지 않습니다.

결과적으로 서버 코드에 압축을 명시 적으로 추가하는 패키지가 있으므로 몇 줄의 코드만으로 gzipping의 이점을 얻을 수 있습니다. 이 압축 미들웨어를 사용하여 Javascript 및 CSS 번들의 크기를 75 % 줄일 수있었습니다.

호스팅 서비스가 gzip 옵션을 제공하는지 확인하는 것이 좋습니다. 그렇지 않은 경우 서버 측 코드에 gzipping을 추가하는 방법을 살펴보십시오.

축소

Pexels의 파인애플 제공

축소는 기능 (공백, 줄 바꿈 문자 등)에 영향을주지 않고 코드에서 불필요한 문자를 제거하는 프로세스입니다. 인터넷을 통해 전송하는 파일의 크기를 줄일 수 있습니다. 또한 코드를 난독 처리하는 데 유용하며 교활한 해커가 보안 취약점을 탐지하기가 더 어려워집니다.

요즘 축소는 일반적으로 Webpack 또는 Gulp 또는 일부 대안으로 빌드 프로세스의 일부로 수행됩니다. 이러한 빌드 도구에는 약간의 학습 곡선이있을 수 있으므로 더 쉬운 대안을 찾고 있다면 HTML 용 HTML-Minifier, CSS 용 CSSNano 및 Javascript 용 UglifyJS를 권장합니다.

브라우저 캐싱

브라우저가 데이터를 저장하는 방법은 아니지만 가능한 한 가깝습니다. Pexels의 의례.

브라우저 캐시에 정적 파일을 저장하는 것은 특히 동일한 클라이언트의 재 방문시 웹 사이트 속도를 높이는 매우 효율적인 방법입니다. 서버에서 보낸 HTTP 응답에 헤더가 누락되어 일부 리소스가 제대로 캐시되지 않았다는 사실을 Google이 알기 전까지는 알지 못했습니다.

내 홈페이지가로드 되 자마자 내 서버에 여러 곡에 대한 데이터를 가져 와서 음악 플레이어로 렌더링하도록 요청합니다. 이 웹 사이트의 노래를 자주 업데이트하지 않기 때문에 사용자가 내 웹 사이트를 방문하고 마지막으로 방문한 시간과 동일한 노래를 보더라도 내 페이지를 조금 더 빠르게로드 할 수 있는지 상관 없습니다.

성능 향상을 위해 서버의 응답 객체 (Express / Node 서버)에 다음 코드를 추가했습니다.

res.append ( "캐시 제어", "max-age = 604800000");
res.status (200) .json (응답);

내가하고있는 일은 캐시 컨트롤 헤더를 응답에 추가하는 것입니다 .1 주일 (밀리 초) 후에 리소스를 다시 다운로드해야한다고 말합니다. 이러한 파일을 더 자주 업데이트하는 경우 최대 연령이 짧을수록 좋습니다.

컨텐츠 배포 네트워크

Pexels가 제공 한 CDN의 실제 이미지.

CDN (콘텐츠 배포 네트워크)은 전 세계의 사용자가 지리적으로 콘텐츠에 더 가까이 갈 수 있도록하는 네트워크입니다. 사용자가 일본에서 큰 이미지를로드해야하지만 서버가 미국에있는 경우 도쿄에 서버가있는 경우보다 시간이 오래 걸립니다.

CDN을 사용하면 전 세계에 위치한 수많은 프록시 서버를 활용할 수있어 최종 사용자의 위치에 관계없이 콘텐츠를보다 빠르게로드 할 수 있습니다.

CDN을 구현하기 전에 위에서 본 결과를 얻을 수 있었다는 점에 주목하고 싶습니다. 웹 사이트 최적화에 대한 기사는 언급하지 않고 완료되지 않았기 때문에 언급하고 싶습니다. 전 세계 잠재 고객을 확보하려는 경우 웹 사이트에이 나쁜 소년 중 하나를 두어야합니다.

널리 사용되는 일부 CDN에는 CloudFront 및 CloudFlare가 포함됩니다.

여러 가지 잡다한

더 많은 주스를 짜기위한 몇 가지 팁이 있습니다.

  • 웹 사이트를 최적화하여 "접은 곳의"컨텐츠를 먼저로드하여 사이트 성능을 향상 시키십시오. 이 작업을 수행하는 일반적인 방법 중 하나는 방문 페이지에 표시되지 않는 이미지를 느리게로드하는 것입니다.
  • 응용 프로그램이 Angular 또는 React로 작성된 웹 사이트와 같이 HTML을 렌더링하기 위해 Javascript를 사용하지 않는 한 HTML 파일의 본문 섹션 맨 아래에 스크립트 태그를로드하는 것이 안전합니다. 이것은 대화식 시간에 영향을 줄 수 있으므로 모든 상황에 권장되는 기술은 아닙니다.

결론적으로

이것은 웹 사이트 최적화와 관련하여 빙산의 일각에 불과합니다. 수신하는 트래픽 양과 제공하는 서비스에 따라 여러 영역에서 성능 병목 현상이 발생할 수 있습니다. 더 많은 서버가 필요할 수도 있고, RAM이 더 많은 서버가 필요할 수도 있습니다. 아마도 트리플 중첩 for 루프가 리팩토링을 사용할 수도 있습니다.

사이트 속도를 높이는 데있어 딱 맞는 것은 없으며, 궁극적으로 측정을 기반으로 상황에 가장 적합한 결정을 내려야합니다. 최적화 할 필요가없는 것을 최적화하는 데 시간을 낭비하지 마십시오. 사이트 성능을 분석하여 병목 현상을 찾아 구체적으로 공격하십시오.

이 기사에서 유용한 정보가 있기를 바랍니다. 내가 언급했듯이, 나는 여전히이 영역에서 배울 것이 많다. 추가 팁이나 권장 사항이 있으면 아래 의견에 남겨주십시오!

이 기사가 마음에 드 셨다면 박수를 치고 확인하십시오.

  • 코딩을 시작할 때 알고 싶었던 도구
  • 코딩을 시작할 때 알고 싶었던 도구 : 재검토

또한 트위터에서 팔로우 해주세요.