Шесть layout-ов фотогалереи: почему «красиво» — это не «удобно»

Pinterest построил masonry. Это их фирменная фишка с 2011 года — переменная высота карточек, плотная упаковка, никаких обрезок, эстетически живой ритм. Идеальная фотогалерея для вдохновения. Десять лет эту идею копировали все: Unsplash, Behance, Erik Johansson, фотопортфолио на половине интернета.

А потом Pinterest начал от неё отказываться. Не везде, но в поиске — да. В поиске по конкретному запросу Pinterest вернулся к обычной сетке с предсказуемыми ячейками, потому что пользователь, который ищет «скандинавский диван IKEA», не хочет бродить по вдохновению — он хочет сравнить варианты. И masonry, при всех своих эстетических достоинствах, ломает этот сценарий.

В этом вся суть. Layout фотогалереи — это не эстетический выбор дизайнера. Это поведенческий выбор. Если пользователь сравнивает варианты (товары, отели, скриншоты), ему нужен один layout. Если он бродит в поисках вдохновения — другой. Универсального решения нет, и попытки его найти — главный источник плохих галерей в продакшене.

Центральный тезис. Выбор layout-а фотогалереи определяется тем, что пользователь делает — ищет конкретное или бродит. Для «ищет» работает uniform grid с pagination; для «бродит» — masonry (но только с нативной CSS-реализацией, когда она станет доступной); для смешанных и неизвестных сценариев безопасный default — curated grid с object-fit: cover, 3–4 колонки, pagination каждые 24–36 элементов.

Все имена хостов, скриншотов публичных сайтов, источников и eyetracking-изображений в этом материале — реальные публичные данные. Совпадения с внутренними дашбордами случайны.

Browse vs Find — рамка выбора

Есть два режима, в которых живёт фотогалерея. Это разные режимы, и они требуют разных интерфейсов.

Browse — пользователь не знает, что именно ищет. Он пришёл за вдохновением, идеями, «покажите что-нибудь красивое». В этом режиме работает высокая плотность контента, переменные размеры, infinite scroll. Чем больше покажешь — тем больше шанс, что он зацепится. NN/g называет это browsing и подчёркивает: в этом режиме пользователь готов листать долго (Hoa Loranger, NN/g, 2014).

Find — пользователь знает, что ищет. Конкретный товар, конкретный отель, конкретное фото для презентации. В этом режиме важна предсказуемость: пользователь сканирует строки слева направо, ожидает увидеть «страницу 3 из 12», нервничает, когда нет footer. NN/g и Baymard сходятся: для goal-oriented задач pagination лучше infinite scroll.

Ключевое следствие: смешивать режимы в одной галерее — провал. Если каталог товаров и раздел «вдохновение» живут в одной сетке, придётся либо убивать find-опыт (бесконечная лента для тех, кто хочет найти), либо убивать browse-опыт (pagination для тех, кто бродит). Pinterest это понял и развёл режимы по разным страницам.

Дальше — шесть layout-ов. Каждый закрывает свой сценарий, у каждого своя цена.

Uniform grid

Фиксированные ячейки одного размера, выровненные по сетке. Глаз пробегает по строкам, как по списку в Excel.

Amazon search — uniform grid в категориях товаров

Скриншот Amazon через image.thum.io. Категория «headphones» — фиксированные квадратные ячейки, сканирование предсказуемое.

Booking — uniform grid в списках отелей

Скриншот Booking.com через image.thum.io. Тот же паттерн, та же логика — пользователь сравнивает варианты.

Когда работает. E-commerce категории, каталоги услуг, любой список, где пользователь сравнивает позиции. Канонические примеры — Amazon, IKEA, Booking. Это default для find-режима.

Почему работает. Сетка естественно совпадает с F-паттерном чтения. Глаз пробегает первый ряд слева направо, потом чуть ниже и снова слева направо, потом чуть ниже — это эмпирически зафиксированный паттерн (Kara Pernice, NN/g, 2017). Когда ячейки выровнены, пользователь не тратит внимание на координацию — оно остаётся на содержание.

Цена. Одинаковые ячейки режут фотографии. Вертикальные портреты в квадрате — половина кадра теряется. Если контент mixed (часть горизонтальные ландшафты, часть вертикальные портреты), uniform grid начнёт портить хорошие кадры.

Реализация. Нативный CSS Grid, ноль JavaScript, лучший LCP. Это технически самый дешёвый layout из всех шести.

Eyetracking NN/g — изучение thumbnail-ов товаров

Источник: Jakob Nielsen, «Photos as Web Content», NN/g, 2010. Сравнение Pottery Barn (оптимизированные превью) и Amazon (стандартизированные превью) — в обоих случаях thumbnails товаров активно изучаются, когда фото информативно.

Masonry

Переменная высота карточек, плотная упаковка снизу-вверх. Никаких обрезок — каждое фото сохраняет свой aspect ratio.

Erik Johansson — masonry в фотопортфолио

Источник: Erik Johansson, Smashing Magazine CDN. Канонический пример — фотохудожник, каждое фото в своём размере, плотная упаковка без обрезки.

Pinterest — оригинальный masonry

Источник: Pinterest, Smashing Magazine CDN. Та же идея, та же плотность, миллионы карточек.

Kristian Hammerstad — masonry в фотопортфолио

Скриншот Kristian Hammerstad через image.thum.io.

Unsplash — masonry в фото-стоке

Скриншот Unsplash через image.thum.io.

Когда работает. Browse-режим: inspiration, фото-сообщества, фотопортфолио, photo discovery. Пользователь бродит, не ищет. Канонические примеры — Pinterest, Unsplash, Behance, Erik Johansson, Kristian Hammerstad.

Почему работает. Максимальная плотность контента на единицу площади. Никаких обрезок. Эстетически живой ритм — глаз не устаёт от одинаковых ячеек. Хорошо показывает разнообразие форматов, что и есть смысл browse-режима.

Цена — и она серьёзная.

Ломает F-паттерн. Глаз скачет между вершинами колонок, потому что горизонтальные «ряды» в masonry не совпадают с визуальными. Это не «плохо» в browse-режиме — там сканирование и не должно быть предсказуемым. Но это смерть для find-режима.
JavaScript. До того как нативный CSS Masonry (display: grid-lanes) станет Baseline, библиотека типа Masonry.js добавляет ≈ 24KB и блокирует LCP примерно на 600ms на 4G. Это из измерений Patrick Brosset, Smashing Magazine, Dec 2025.
Accessibility. Порядок в DOM не совпадает с визуальным порядком. Screen reader пройдёт по DOM, а пользователь видит совсем другое. Keyboard navigation требует отдельной работы.
Мобильный viewport. На маленьких экранах masonry вырождается фактически в одну колонку. Вся «магия» пропадает.

Когда НЕ работает. Любой goal-oriented сценарий. Сравнение товаров, выбор отеля, поиск скриншота для презентации. Pinterest это понял — и в поиске вернулся к обычной сетке.

CSS Masonry разные варианты track-ов и комбинаций:

CSS Masonry — columns + rows

Источник: Smashing Magazine CDN, статья Brosset, Dec 2025. Базовая схема — колонки и ряды как независимые оси.

CSS Masonry — разные размеры треков

Источник: то же. Треки разной ширины — управление через CSS-свойства.

CSS Masonry — элементы на нескольких треках

Источник: то же. Элемент может занимать несколько треков одновременно.

CSS Masonry — photo gallery на нескольких треках

Источник: то же. Конкретный пример photo gallery с элементами на нескольких треках.

CSS Masonry — photo gallery с разными треками

Источник: то же. Та же идея, другая раскладка.

Flexbox-имитация masonry

Источник: то же. Обходное решение через flexbox — работает, но с ограничениями. Использовать как fallback до нативной CSS-реализации.

Статья Brosset от декабря 2025 говорит: нативный display: grid-lanes уже «just starting to be implemented» в Chromium, webkit и mozilla в процессе. На середину 2026 это, вероятно, доступно в Chromium-семействе, но не Baseline. Решение использовать masonry сейчас — это решение либо ждать нативной поддержки, либо платить 24KB + 600ms JS-библиотекой за эстетику.

Curated grid

Фиксированная сетка колонок (3–4 колонки), но каждая ячейка имеет свой разрешённый aspect ratio (4:3, 1:1, 3:4, 16:9). Фото подгоняется через object-fit: cover.

Behance — curated grid на главной

Скриншот Behance через image.thum.io. Канонический пример — фиксированная сетка колонок, ячейки разных пропорций, content подогнан через cover.

Когда работает. Editorial-сайты, блоги, news-разделы, кейс-шоукейсы, любой контент, где найти и полистать должны сосуществовать. Канонические примеры — Behance (главная), Apple Newsroom, большинство editorial-CMS.

Почему работает. Лучший компромисс между эстетикой и предсказуемостью. F-паттерн сохраняется на уровне колонок (глаз всё ещё бежит слева направо по верхнему ряду), но визуальный ритм живой за счёт разных пропорций. Никакого JS. Никаких обрезок в полях — фото заполняет ячейку целиком, обрезаются только края, не композиция.

Цена. Обрезка краёв у нестандартных фото. Если снимать или подбирать контент специально под ячейки — проблем нет. Если контент mixed и заранее неизвестен — какие-то кадры будут резаться неудачно. Решается дисциплиной: композиция в кадре должна работать при crop в нескольких ratio.

Реализация. Нативный CSS Grid с aspect-ratio и object-fit: cover. Retina-safe через srcset и sizes (Mat Marquis, A List Apart, 2018, web.dev). Никакого JS.

Это безопасный default для неизвестного кейса. Если вы не знаете, какой layout выбрать, и не хотите A/B-тест — берите curated grid.

Hero + grid

Одно-два крупных изображения в верхней части, под ними стандартная сетка превью.

IKEA — hero + grid на homepage

Скриншот IKEA через image.thum.io. Один крупный hero-блок сверху на ~50% экрана, ниже — сетка превью других помещений.

Когда работает. Лендинги, кейс-шоукейсы, photography portfolios с одной-двумя «главными» работами. Тот же паттерн — у Erik Johansson и Kristian Hammerstad на главной, у Apple product pages.

Почему работает. По NN/g, Scrolling and Attention, 2018, 57% viewing time приходится на первый экран. Hero-фото получает максимум внимания. Чёткая иерархия: сначала эмоция (большое фото), потом варианты (сетка).

Цена. Одно фото съедает место. Scroll depth страдает — большая часть контента оказывается ниже fold. Не подходит для каталогов с десятками товаров.

Горизонтальный filmstrip

Горизонтальная лента с пошаговой прокруткой. Типичный пример — варианты одного товара на Amazon product page: разные ракурсы, разные цвета.

Когда работает. Сравнение связанных изображений одного объекта. Альтернативные ракурсы товара, фото одного отеля с разных точек, скриншоты одного экрана в разных состояниях.

Почему работает. Компактно по вертикали. Удобно для случая, когда пользователь уже внутри одной «сущности» (товар, отель, проект) и листает её детали.

Цена. NN/g предупреждает против горизонтального скролла на desktop (Katie Sherwin, NN/g). Discoverability низкая: пользователь не знает, что есть ещё. Подходит только для связанных вариантов одного объекта — не для разных объектов.

Скриншотов публичных примеров в материале нет: и Amazon product detail, и Booking hotel detail требуют авторизации или cookies, image.thum.io их не отдаёт.

Pagination и infinite scroll

Это не layout, но они неразрывно связаны с галереей. Eyetracking объясняет, почему masonry + infinite scroll — плохая комбинация для find.

Pagination — сетка из 24–36 элементов, внизу «1 2 3 ... Next». Работает для find: пользователь помнит «это на странице 3», понимает, сколько ещё. Footer на месте.

Infinite scroll — бесконечная лента, подгрузка при скролле. Работает для browse: пользователь бродит, лента не заканчивается. Но NN/g прямо говорит: для goal-oriented задач это плохо (Hoa Loranger, NN/g, 2014). Паралич выбора, пропавший footer, потерянная позиция.

Главная ошибка — комбинировать masonry с infinite scroll в каталоге товаров. Это и есть та самая «убитая find-логика».

Eyetracking: что говорят данные

Пять изображений от NN/g, на которых держится всё остальное. Это не «мнение» — это измерения.

F-паттерн чтения на вебе

Источник: Kara Pernice, «F-Shaped Pattern of Reading on the Web», NN/g, 2017. Глаз пробегает первый ряд слева направо, потом второй ряд чуть короче, потом третий ещё короче. Uniform grid совместим с этим паттерном; masonry — нет.

57% viewing time above the fold

Источник: Therese Fessenden, «Scrolling and Attention», NN/g, 2018. 57% viewing time на первом экране, 74% в первых двух экранах, резкий спад после fold. Hero + grid опирается именно на это.

80% фиксаций слева

Источник: Therese Fessenden, «Horizontal Attention Leans Left», NN/g, 2017. 80% фиксаций приходится на левую половину страницы, пик около 600px от левого края. Это значит: в любом layout-е первое фото в верхнем-левом углу получает максимум внимания — независимо от того, masonry это или grid.

Портреты реальных людей изучаются, stock-фото игнорируется

Источник: Jakob Nielsen, «Photos as Web Content», NN/g, 2010. Информативные фото (реальные люди, товары, достопримечательности) активно изучаются. Декоративные — игнорируются. Это про содержание фото, не layout, но влияет: в masonry декоративные фото чаще всего и есть проблема — они создают шум без пользы.

Увеличение фото по клику = хорошо

Источник: то же. Увеличенное фото по клику — пользователь хочет видеть детали. NN/g рекомендует увеличение ≥ 2x.

Эти пять изображений вместе отвечают на 80% вопросов про layout фотогалереи. F-паттерн → uniform grid. Above-the-fold → hero+grid. Лево-ориентированное внимание → первое фото всегда в верхнем-левом углу. Информативные фото → пользователь изучает, увеличение нужно. Декоративные фото → пользователь игнорирует, убирать.

Матрица выбора

Сводная таблица. Это не «единственно правильный» ответ — это default для каждого сценария.

Сценарий	Layout	Pagination	Почему
E-commerce категории (товары)	Uniform grid, единый aspect ratio	Pagination 24–36	F-паттерн, сравнение, zero JS, лучший LCP
Каталог услуг (отели, рестораны)	Uniform grid или curated grid	Pagination	Сравнение вариантов, предсказуемость
Photo community / inspiration (Pinterest, Unsplash)	Masonry	Infinite scroll	Browse-режим, плотность, эстетика
Photography portfolio (Erik Johansson, Kristian Hammerstad)	Hero + grid или masonry	Pagination	Продать 1–2 главные работы + остальное
Editorial / news / блог	Curated grid	Pagination	Компромисс эстетики и предсказуемости
Лендинг	Hero + grid	—	Hero-продажа, остальное — варианты
Product detail page	Горизонтальный filmstrip	—	Варианты одного объекта
Неизвестный кейс, нет A/B-теста	Curated grid, 3–4 колонки, `object-fit: cover`	Pagination 24–36	Безопасный default

Что не делать. Masonry + infinite scroll в каталоге товаров. Горизонтальный filmstrip для разных объектов (не связанных). Uniform grid с aspect-ratio 1:1 для вертикальных портретов — половина кадра теряется.

Что делать разработчику

Это не теория. Это последовательность шагов, которая работает в проектах, где я строил галереи.

Определить режим. Это find или browse? Если оба — разнести по страницам, как Pinterest.
Если find — uniform grid. Нативный CSS Grid, единый aspect ratio под контент, pagination, retina-через srcset. Zero JS, лучший LCP.
Если browse — masonry, но с native CSS. Подождать display: grid-lanes Baseline. До тех пор — fallback на библиотеку с явным acknowledgement в комментарии: «24KB + 600ms за эстетику, см. PE-XXX».
Если смешанно или неизвестно — curated grid. 3–4 колонки, разные aspect ratio, object-fit: cover, pagination. Безопасный default.
Hero + grid — для лендингов. Один крупный hero, ниже сетка. Не наоборот.
Horizontal filmstrip — только для связанных вариантов одного объекта. Не для разных объектов.
Eyetracking-проверка. Перед запуском — поставить себя на место пользователя с NN/g-данными: первое фото в верхнем-левом углу, F-паттерн для grid, скачки между колонками для masonry. Если это не работает в вашем контенте — не работает и layout.

Главное — не смешивать режимы в одной сетке. Это убивает оба.

Если выбрать не тот layout

Что будет, если поставить masonry в каталог товаров, или uniform grid в inspiration-раздел.

Masonry в find-режиме. Пользователь ищет конкретный товар, не может запомнить, где видел «тот синий свитер» — карточки разной высоты, сканирование не предсказуемое. Уходит. По NN/g — повышенный cognitive load, «паралич выбора», пропавший footer. Conversion падает.

Uniform grid в browse-режиме. Пользователь пришёл за вдохновением, видит 24 квадратные ячейки. Через 30 секунд понимает: «здесь нет ничего нового, обрезано». Engagement падает. Pinterest никогда бы не построил свой бизнес на uniform grid.

Hero + grid в каталоге. Один товар занимает половину экрана, остальные 200 — ниже fold. По NN/g, 74% viewing time в первых двух экранах, остальное игнорируется. Большая часть каталога мертва.

Curated grid с aspect-ratio 1:1 для вертикального контента. Половина фотографий обрезана сверху и снизу — главный объект (лицо, товар) теряется. Engagement падает, отказы растут.

Сценарий «если ошибиться» сводится к одному: layout не соответствует поведению пользователя. Данные есть — eyetracking NN/g, masonry cost Brosset, F-паттерн. Игнорировать их = выбирать layout на глаз.

Откуда это

Материал родился из нескольких проектов, где я строил галереи — от e-commerce категорий с десятками тысяч товаров до editorial-CMS и фотопортфолио для креативных агентств. Грабли были одни и те же. Masonry там, где нужен find — и conversion проседал. Uniform grid там, где нужен browse — и engagement падал. Hero-блок, съедающий половину каталога — и 80% товаров уходили ниже fold.

Eyetracking-данные NN/g за 2010–2018 годы я накладывал на эти кейсы задним числом, и они объясняли все наблюдения, без исключений. Это и есть origin grounding: не «я придумал теорию», а «я наблюдал одни и те же грабли в разных проектах, и есть публичные данные, которые объясняют, почему».

Отсюда — и рамка browse vs find, и безопасный default curated grid, и матрица выбора. Это не академический разбор причинности; это обобщение практики через готовые данные, которые я не собирал сам.

Дисклеймер

Это аналитический обзор, написанный на основе практики построения галерей в high-load проектах и публичных UX-исследований. Здесь нет академического разбора причинности, нет собственного A/B-теста masonry vs grid на аудитории, и нет претензии на универсальную модель. Каждая цифра в тексте — это или результат NN/g-измерений, или измерения Patrick Brosset (Smashing Magazine, Dec 2025). Если вы видите то же самое — открывайте issue с контрпримером или альтернативным источником. Если видите иначе — тем интереснее.

sources

Дата проверки источников: 2026-08-05.