Сетки видеокатегорий компании использовали прямые ссылки на большие, неоптимизированные миниатюры JPEG с стороннего CDN, что приводило к медленному времени загрузки Largest Contentful Paint (LCP) на мобильных устройствах. Это было вызвано тем, что изображения подавались в полном разрешении и масштабировались с помощью CSS, что приводило к значительной потере пропускной способности. Для решения этой проблемы была разработана служба на Go для управления процессом создания миниатюр. Эта служба использует FFmpeg для извлечения визуально отличимых кадров из исходных видео или постеров. Затем она кодирует эти кадры в несколько вариантов ширины в формате WebP, который более эффективен, чем JPEG. Служба на Go также управляет трафиком загрузки, обеспечивая эффективное управление процессами FFmpeg. PHP был признан непригодным для этой задачи из-за ограничений общего хостинга по времени выполнения и управлению процессами. Служба на Go использует флаги FFmpeg, такие как -ss перед -i для более быстрого поиска и thumbnail=300 для лучшего выбора кадра. Она также использует ограниченный пул рабочих и singleflight для предотвращения дублирования обработки и управления параллелизмом. Сгенерированные миниатюры записываются во временный файл, а затем атомарно переименовываются, предотвращая выдачу незавершенных файлов. Эта служба на Go запускается по расписанию cron, которое ставит в очередь задачи по созданию миниатюр. Затем фронтенд-приложение на PHP запрашивает простую базу данных SQLite для проверки статуса этих миниатюр. Схема базы данных является базовой, храня идентификаторы видео, исходные URL-адреса, статус и количество повторных попыток. Cron-задание PHP опустошает эту очередь, отправляя HTTP-запросы к службе на Go. Время ожидания записи службы на Go намеренно установлено дольше, чем бюджет выполнения задания, чтобы избежать усеченных ответов.