입문

문제

페이지에 표시할 이미지의 양이 많고 페이지를 읽는 데 걸리는 시간

사용자의 투고 이미지를 표시하기 때문에 미리 크기를 조정할 수 없음

환경

Active Storage

mini_magick

image_processing

EC2 & S3

활용

생각한 일

업로드 시 크기 조절
=> 어떻게 해야 할지 몰라 포기했다

생각한 일

읽을 때 서버에서 다시 크기를 맞추면 빨라지지 않을까.
완성!

참고 자료

이 보도를 참고했다.
활성 스토리지에 다양한 Variant 지정 방법
[2020.12.1 추기]
"Active Storages ImageProcessing transformer doesn't support:combine_options, as it always generates a single ImageMagick command. Passing:combine_options will not be supported in Rails6.1."경고...
이 글쓰기는 Rails 6.1부터 사용할 수 없을 것 같아요.
그리고 해소 방법을 찾았을 때, 아래의 기사는 참고로 실렸다
Rails6.0의 활성 스토리지 처리 transformer doesn't support:combine_options 경고 처리 방법
또 일본어 참고는 방법의 상세한 설명이 없기 때문에 이곳의 영어로 쓴 참고를 참고했다.
ActiveStorage::Variant
역시 정식으로 한 번 통과하는 것이 중요하다.image_처리 없이는 전환이 안 될 것 같습니다.왠지 개요를 이해한 것 같아.
구글 번역.

단계

자세한 절차는 참조된 URL에서 확인하십시오.
한 일
example.rb

image_tag @hoge.image.variant(combine_options:{gravity: :center, resize:"AxB^", crop:"AxB+0+0"}).processed, class: 'hoge'

variant 사용 방법

치수 조정

중심합체

절단

태그 요소의 표시 속성을 수정합니다.사이즈는 CSS에서 지정한 것이기 때문에 그것에 맞추었다.(이러면 CSS 사이즈 표시가 필요 없으니 안 하는 게 낫나요?)
또한processed 옵션을 추가하면 두 번째 이후의 읽기는 다시 크기의 URL로 되돌아갈 수 있기 때문에 더욱 빨라진다(논리를 잘 몰라서 자신감이 없지만...이 근처는 열심히 공부해야 한다)
결론적으로 이렇게 CSS를 모두 조정하는 것이 아니라 서버에서 이미지를 정리해서 프론트에 건네주는 것이 중요하다.
[2020.12.1 추기]
앞에서 설명한 대로 Rails6.1은 더 이상 이 설명을 지원하지 않습니다.
combine_옵션은 NG인 것 같습니다.
따라서 다음과 같이 개작한다.
example.rb

image_tag @hoge.image.variant(resize_to_fill: [128, 128]), class: 'hoge'

하는 일은 똑같다.
processed 옵션에 대해 나는 좀 모르겠기 때문에 다시 한 번 조사하고 싶다.연기에 큰 지장이 없을 것 같아서 일단 기사를 삭제했다.

개선 전

홈페이지 첫 페이지가 여기 있습니다.

투고 일람에 화신을 싣고 페이지당 10건 단위로 이미지를 불러온다

투고에 이미지를 추가할 수도 있고 일람표에 표시할 수도 있다

읽기가 끝나기 전에 10초 이상 걸리는 경우도 있습니다.
사이트 설명


화면에 포함되는 것을 잊어버렸지만 읽기가 끝날 때까지 4.3초 (확실) 의 점수였다.
그림이 너의 뒷다리를 끌고 있는 것이 분명하다.
측정 정보
이번에는 PageSpeed Insights로 읽기 속도를 측정했다.
PageSpeed Insights는 이 글에서 배웠습니다.
사이트의 성능에 대해서도 이것이 정말 옳은 것이냐는 지적이 있다. 한마디로 현재 광범위하게 사용되고 있는 서비스인데 입구로서 사용하는 데 문제가 없느냐.

개선 후

"웹 페이지의 읽기 시간 단축"

읽기 완료 시간은 4.0초입니다.
점수와 읽기 완료 시간은 기대에 미치지 못했지만 개선 항목에서 이미지가 한꺼번에 사라졌다.
좋은 개선 아닙니까?매우 만족스럽다.
(참고로 PageSpeed Insights는 모바일과 PC에서 결과가 달라집니다. 여기에 게재된 것은 모바일 결과입니다. PC에서는 94분(0.9초)을 기록했습니다.이렇게 되면 수동적인 관계의 프론트 데스크 기술이나 프론트 데스크와 서버 간의 처리가 좋지 않을 수도 있다)

끝내다

업데이트할 때 크기를 다시 저장하려고 했지만 잠시 포기하고 variant로 디스플레이 처리를 개선해 보았습니다.
이번에 새로운 발견이 생겨서 다행이다.
나중에 Nginx와 연계해서 처리 속도를 높일 수 있을 것 같아요. (업데이트 얘기인가요?)냉정해지면 나도 여러 가지 다른 방법을 시도해 보고 싶다.
✔︎