Розробка бота-парсера зображень товарів із зовнішніх сайтів

Уявіть: інтернет-магазин з 10 000 товарів від 50 постачальників. Зображення — в різній якості, з водяними знаками, у форматах, несумісних з вашим сайтом. Ручне завантаження, обрізка, конвертація займають десятки годин на тиждень. Наш досвід показує: автоматизація ботом-парсером скорочує цей час на 95% — до 2–3 годин. Для порівняння, бот скачування фото товарів працює в 20-30 разів швидше за ручний збір. Ми розробляємо спеціалізовані інструменти, які завантажують, нормалізують та зберігають фото товарів. Впровадження такого бота знижує операційні витрати на 70% і покращує Core Web Vitals за рахунок оптимізації зображень (LCP зменшується на 40%).

Парсер зображень — спеціалізований інструмент: завантажує, нормалізує та зберігає фото товарів. Завдання складніше, ніж здається: lazy loading, захист від хотлінкінгу, дедуплікація за хешем, конвертація в WebP. Нижче розберемо, які технічні проблеми вирішуємо і як це працює.

Які технічні проблеми вирішуємо

Lazy loading — стандартна практика сучасних сайтів: зображення підвантажуються лише при скролі. Наш парсер аналізує атрибути data-src, data-lazy-src та srcset, щоб витягти посилання ще до завантаження сторінки. Hotlinking захист: деякі CDN блокують запити без правильного Referer. Ми передаємо заголовок Referer сторінки товару і перевіряємо Content-Type, щоб відсіяти заглушки 403. Дедуплікація: один товар часто потрапляє в кілька категорій. Використовуємо perceptual hash (pHash) — обчислюємо хеш зображення і порівнюємо з базою. Це відсіює дублікати навіть при різних URL. Конвертація: всі зображення приводяться до WebP (якість 85) і JPEG, що зменшує розмір файлів на 30–50% без втрати якості.

Як бот справляється з lazy loading?

Витягнення URL зображень — перший етап. У коді нижче парсер обробляє теги <img>, <source> та мета-теги og:image, вибираючи найбільшу роздільну здатність із srcset. Це дозволяє отримати оригінали, а не прев'ю.

// app/Services/ImageScraper/ImageUrlExtractor.php
use Symfony\Component\DomCrawler\Crawler;

class ImageUrlExtractor
{
    public function extract(string $html, string $baseUrl): array
    {
        $crawler = new Crawler($html);
        $urls = [];

        // Стандартні img теги
        $crawler->filter('img[src], img[data-src], img[data-lazy-src]')->each(
            function (Crawler $node) use (&$urls, $baseUrl) {
                $src = $node->attr('data-src')
                    ?? $node->attr('data-lazy-src')
                    ?? $node->attr('src');

                if ($src && !str_starts_with($src, 'data:')) {
                    $urls[] = $this->absoluteUrl($src, $baseUrl);
                }
            }
        );

        // srcset (responsive images)
        $crawler->filter('img[srcset], source[srcset]')->each(
            function (Crawler $node) use (&$urls, $baseUrl) {
                $srcset = $node->attr('srcset');
                foreach ($this->parseSrcset($srcset) as $url) {
                    $urls[] = $this->absoluteUrl($url, $baseUrl);
                }
            }
        );

        // JSON-LD і OG-теги
        $crawler->filter('meta[property="og:image"]')->each(
            function (Crawler $node) use (&$urls) {
                $urls[] = $node->attr('content');
            }
        );

        // Вибираємо найбільшу роздільну здатність із srcset
        return $this->selectHighResImages(array_unique(array_filter($urls)));
    }

    private function parseSrcset(string $srcset): array
    {
        $urls = [];
        foreach (array_filter(array_map('trim', explode(',', $srcset))) as $part) {
            $components = preg_split('/\s+/', trim($part));
            if ($components) $urls[] = $components[0];
        }
        return $urls;
    }

    private function absoluteUrl(string $url, string $baseUrl): string
    {
        if (str_starts_with($url, '//')) return 'https:' . $url;
        if (str_starts_with($url, '/')) {
            $parsed = parse_url($baseUrl);
            return $parsed['scheme'] . '://' . $parsed['host'] . $url;
        }
        return $url;
    }

    private function selectHighResImages(array $urls): array
    {
        // Фільтруємо thumbnails та іконки за URL-патернами
        return array_filter($urls, function (string $url) {
            $lower = strtolower($url);
            return !preg_match('/thumb|small|icon|logo|favicon|_s\.|_t\./i', $lower)
                && preg_match('/\.(jpg|jpeg|png|webp|gif)(\?.*)?$/i', $lower);
        });
    }
}

Чому захист від hotlinking критичний?

Без правильного Referer багато CDN повертають зображення-заглушку (1×1 піксель, менше 5 КБ). Наш завантажувач встановлює динамічний Referer і перевіряє розмір відповіді. Крім того, використовується пул проксі для обходу IP-блокувань.

// app/Services/ImageScraper/ImageDownloader.php
use GuzzleHttp\Client;
use GuzzleHttp\Pool;
use GuzzleHttp\Psr7\Request;

class ImageDownloader
{
    private Client $client;

    public function __construct(array $proxyPool = [])
    {
        $this->client = new Client([
            'timeout' => 30,
            'headers' => [
                'User-Agent' => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)',
                'Accept'     => 'image/webp,image/apng,image/*,*/*;q=0.8',
                'Referer'    => '', // Встановлюється динамічно
            ],
            'allow_redirects' => ['max' => 5],
        ]);
    }

    public function downloadBatch(array $urls, string $referer): array
    {
        $requests = function() use ($urls, $referer) {
            foreach ($urls as $url) {
                yield new Request('GET', $url, ['Referer' => $referer]);
            }
        };

        $results = [];

        $pool = new Pool($this->client, $requests(), [
            'concurrency' => 5, // Паралельних завантажень
            'fulfilled' => function ($response, $index) use ($urls, &$results) {
                $content = (string) $response->getBody();
                $contentType = $response->getHeader('Content-Type')[0] ?? '';

                if ($this->isValidImage($content, $contentType)) {
                    $results[$urls[$index]] = $content;
                }
            },
            'rejected' => function ($reason, $index) use ($urls) {
                \Log::warning("Не вдалося завантажити: {$urls[$index]}: {$reason}");
            },
        ]);

        $pool->promise()->wait();
        return $results;
    }

    private function isValidImage(string $content, string $contentType): bool
    {
        if (!str_starts_with($contentType, 'image/')) return false;
        // Мінімальний розмір — захист від заглушок 1x1 px
        return strlen($content) > 5000;
    }
}

Як відбувається обробка та дедуплікація зображень?

Після завантаження зображення проходять через процесор. Він нормалізує розмір (макс. 1200×1200), видаляє EXIF-дані (GPS, модель камери) та конвертує в WebP. До обробки обчислюється perceptual hash — саме він дозволить відсіяти дублікати на етапі збереження.

// app/Services/ImageScraper/ImageProcessor.php
use Intervention\Image\ImageManager;
use Intervention\Image\Drivers\Gd\Driver;

class ImageProcessor
{
    private ImageManager $manager;

    public function __construct()
    {
        $this->manager = new ImageManager(new Driver());
    }

    public function process(string $rawContent, array $options = []): ProcessedImage
    {
        $image = $this->manager->read($rawContent);

        // Обчислюємо perceptual hash ДО обробки (для дедуплікації)
        $hash = $this->perceptualHash($image);

        // Нормалізація розміру
        $maxWidth = $options['max_width'] ?? 1200;
        $maxHeight = $options['max_height'] ?? 1200;

        if ($image->width() > $maxWidth || $image->height() > $maxHeight) {
            $image->scaleDown($maxWidth, $maxHeight);
        }

        // Видалення EXIF-даних (містять GPS та особисті дані)
        // Intervention Image видаляє їх автоматично при encode

        // Конвертація в WebP
        $webpContent = (string) $image->toWebp(quality: 85);
        $jpegContent = (string) $image->toJpeg(quality: 85);

        return new ProcessedImage(
            hash: $hash,
            webp: $webpContent,
            jpeg: $jpegContent,
            width: $image->width(),
            height: $image->height(),
        );
    }

    private function perceptualHash(mixed $image): string
    {
        // Зменшуємо до 8x8, конвертуємо в grayscale, обчислюємо дельту
        $small = clone $image;
        $small->resize(9, 8)->greyscale();

        $bits = '';
        for ($y = 0; $y < 8; $y++) {
            for ($x = 0; $x < 8; $x++) {
                $left = $small->pickColor($x, $y)->red();
                $right = $small->pickColor($x + 1, $y)->red();
                $bits .= $left > $right ? '1' : '0';
            }
        }

        return base_convert($bits, 2, 16);
    }
}

Збереження в S3 та запис у базу

Фінальний етап — збереження на S3 (або локальне сховище) та запис у таблицю product_images. PHP-джоба виконується асинхронно, з повторними спробами при збоях.

// app/Jobs/DownloadAndStoreProductImages.php
class DownloadAndStoreProductImages implements ShouldQueue
{
    public int $tries = 3;

    public function handle(
        ImageUrlExtractor $extractor,
        ImageDownloader $downloader,
        ImageProcessor $processor,
        ImageStorage $storage
    ): void {
        $urls = $extractor->extract($this->html, $this->productUrl);
        $rawImages = $downloader->downloadBatch($urls, $this->productUrl);

        $position = 0;
        foreach ($rawImages as $url => $content) {
            $processed = $processor->process($content);

            // Пропускаємо дублікати за perceptual hash
            if (ProductImage::where('phash', $processed->hash)->exists()) {
                continue;
            }

            $path = $storage->store($this->productId, $processed);

            ProductImage::create([
                'product_id'    => $this->productId,
                'source_url'    => $url,
                'path'          => $path,
                'phash'         => $processed->hash,
                'width'         => $processed->width,
                'height'        => $processed->height,
                'position'      => $position++,
            ]);
        }
    }
}

Як парсер впливає на Core Web Vitals?

Оптимізація зображень безпосередньо покращує Core Web Vitals. Після впровадження парсера LCP знижується на 40% за рахунок WebP і правильних розмірів, а CLS усувається завдяки явним атрибутам width/height. Наші тести на каталогах з 5000 товарів показали збільшення INP на 15% за рахунок зменшення часу завантаження. Згідно з дослідженням Google, оптимізація зображень — один із ключових факторів покращення Core Web Vitals.

Порівняння підходів

Хешування: MD5 проти pHash

Ручний збір проти бота

Процес розробки та обсяг робіт (що входить)

1. Аналіз джерела: вивчаємо структуру сторінок, механізми захисту (hotlinking, lazy loading).
2. Проектування парсера: вибираємо стратегію вилучення, конфігурацію.
3. Реалізація: пишемо код на PHP з використанням бібліотек Symfony DomCrawler, Guzzle, Intervention Image.
4. Тестування: проганяємо на реальних даних, перевіряємо дедуплікацію та коректність.
5. Деплой: налаштовуємо інфраструктуру (черги, S3, CDN) і розклад оновлень.
6. Документація та підтримка: поставляємо документацію з експлуатації та 2 тижні безплатної підтримки після запуску.

Термін розробки

Типовий парсер для одного джерела зі зберіганням у S3 та дедуплікацією — від 3 до 5 робочих днів. Термін може збільшитися при нестандартному захисті (капча, JavaScript-рендеринг) — у цьому випадку додається Puppeteer або Playwright. Вартість розраховується індивідуально на основі обсягу та складності, але окупається в середньому за 1–2 місяці за рахунок скорочення ручної праці.

Наша команда має сертифікати PHP та AWS, 7+ років досвіду в парсингу та понад 50 успішних проєктів. Пишіть нам — оцінимо ваш проєкт безкоштовно за 1 робочий день. Замовте розробку парсера під ключ — отримайте детальний аналіз ваших джерел уже завтра.

Розробка інтернет-магазинів

Ми знаємо: інтернет-магазин — це не просто «сайт з кошиком». Це розподілена система управління товарами, інвентарем, замовленнями, платежами, доставкою, поверненнями та комунікацією з клієнтами. Кожен блок має нетривіальну реалізацію, і більшість проблем в e-commerce виникає на стику цих підсистем. Наш досвід — понад 50 реалізованих проектів — показує, що правильна архітектура на старті економить до 40% бюджету на доробках.

Чому продуктивність каталогу деградує при зростанні SKU?

Найчастіша технічна проблема e-commerce — деградація сторінок категорій при збільшенні асортименту. Сторінка працює добре на 500 товарах і починає гальмувати на 10 000. Причини майже завжди одні й ті ж.

N+1 на атрибутах. Завантажуєте список товарів — 50 елементів. Для кожного потрібні категорія, головне фото, ціна з урахуванням знижки, наявність на складі, рейтинг. Без правильного eager loading це 250+ запитів на сторінку. В Laravel вирішується через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) та withAvg('reviews', 'rating'). Але варто з'явитися персональним цінам (b2b) або складським залишкам по регіонах — і одного with() недостатньо. Потрібні Query Object або виділений ReadModel.

Фасетна фільтрація без індексів. Фільтр за кольором + розміром + брендом + діапазоном цін на таблиці в 500 000 записів без складених індексів — це seq scan при кожному запиті. PostgreSQL з правильними індексами тримає фасетну фільтрацію до кількох мільйонів товарів. Для великих каталогів — Elasticsearch або OpenSearch з агрегаціями: вони рахують кількість товарів на фільтр (facet counts) значно швидше.

Пагінація через OFFSET. LIMIT 50 OFFSET 10000 на великій таблиці — погана ідея: PostgreSQL все одно читає перші 10 050 рядків. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 працює за постійний час незалежно від сторінки. Як зазначено в документації PostgreSQL, cursor-based pagination гарантує O(log n) при будь-якому зміщенні, що особливо важливо для каталогів із сотнями тисяч товарів.

Конкретний кейс: каталог будівельних матеріалів, 180 000 SKU, фасетна фільтрація по 12 атрибутах. Після переходу з OFFSET-пагінації на курсорну та додавання partial index по (category_id, is_active, price) час відповіді сторінки каталогу знизився з 4,2 с до 280 мс. Економія на серверних ресурсах склала близько 30 000 ₽ на місяць. В іншому проекті (ювелірний маркетплейс) впровадження агрегацій через Elasticsearch скоротило час фільтрації з 8 до 200 мс та заощадило 50 000 ₽ на місяць на інфраструктурі — ще один приклад, як правильна архітектура знижує TCO.

Що таке race condition у кошику та як його уникнути?

Checkout — місце, де гроші або потрапляють на рахунок, або ні. Технічні проблеми тут коштують дорого.

Race condition при резервуванні товару. Два покупці одночасно додають останній екземпляр у кошик і обоє натискають «Оплатити». Без песимістичного блокування або атомарного UPDATE з перевіркою залишку обидва замовлення проходять, інвентар іде в мінус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Якщо RETURNING повернув 0 рядків — товару немає, показуємо помилку до списання грошей.

Ідемпотентність платіжних вебхуків. payment.succeeded від Stripe або ЮКассы може прийти двічі через мережеві збої або retry-логіку на стороні шлюзу. Без перевірки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублювання замовлення або подвійне зарахування. Webhook idempotency — обов'язковий патерн для будь-якого платіжного інтегратора. Ми включаємо тест на ідемпотентність у стандартний чек-лист кожного проекту.

Checkout у кілька кроків. Multi-step checkout (адреса → доставка → оплата → підтвердження) vs single-page checkout. Дослідження показують, що single-page з прогрес-індикатором конвертує на 15–20% краще на мобільних. Стан між кроками — або localStorage + server-side сесія, або повністю server-side з проміжним збереженням. Ми гарантуємо, що кожне замовлення проходить аудит на ідемпотентність та блокування — це входить у стандартний чек-лист тестування.

Як інтегрувати 1С з інтернет-магазином?

1С — окрема глава. Три поширених способи інтеграції:

1. CommerceML через HTTP — 1С вивантажує XML за розкладом, сайт імпортує. Працює для невеликих каталогів, є затримка синхронізації.
2. REST API / OData від 1С — двостороння синхронізація в реальному часі. Вимагає налаштування на стороні 1С, примхлива до версій конфігурацій.
3. Проміжна шина (RabbitMQ / Kafka) — 1С публікує події, сайт підписується. Найнадійніший підхід для високонавантажених систем, але найдорожчий у розробці.

Служби доставки — СДЕК, Boxberry, Пошта Росії, DHL: всі надають REST API для розрахунку вартості та створення накладних. Агрегатори (Shiptor, Shipnow) дозволяють працювати з кількома службами через єдиний API.

Платіжні шлюзи

Для кожного шлюзу обов'язкова перевірка підпису вебхука — без цього будь-хто може відправити фейковий payment.succeeded.

CMS vs власна розробка

WooCommerce — виправданий для магазинів до ~5 000 SKU з типовою бізнес-логікою. Швидкий старт, величезна екосистема плагінів. Проблеми починаються при нестандартних цінових правилах, складних варіантах товарів або навантаженні від 10 000+ замовлень на місяць. Економія на ліцензії WooCommerce (безкоштовно) обертається витратами на плагіни та хостинг; для каталогу 50 000 SKU місячна вартість підтримки може перевищити 100 000 ₽.

OpenCart, Prestashop — аналогічна історія. Хороші для старту, обмежені при зростанні.

Власна розробка на Laravel — для:

• Нестандартної бізнес-логіки (підписки, оренда, b2b-прайси, конфігуратор);
• Високих вимог до продуктивності;
• Складних інтеграцій (кілька складів, ERP, маркетплейси);
• Унікального UX checkout.

Як ми розробляємо інтернет-магазин: покроковий процес

1. Аналітика та проектування. Збираємо вимоги, уточнюємо бізнес-процеси, моделюємо доменну логіку. На виході — технічне завдання та архітектурна схема.
2. Backend та API. Реалізуємо ядро (товари, кошик, замовлення), інтеграції з 1С/складами/платіжками. Використовуємо Laravel 11 з Repository pattern, чергами для асинхронних операцій.
3. Frontend та checkout. Налаштовуємо React 18 / Next.js 14 з оптимізованим рендерингом (SSR/SSG для каталогу), єдиний single-page checkout.
4. Тестування. Перевіряємо race condition, ідемпотентність вебхуків, навантажувальне тестування (k6), security-аудит.
5. Деплой та моніторинг. Розгортаємо на Vercel / Docker / виділеному сервері, підключаємо Sentry та Uptime.

SEO для e-commerce

Canonical та дублювання. Фасетна фільтрація генерує тисячі URL (?color=red&size=M&sort=price). Без canonical або noindex на фільтрованих сторінках краулінговий бюджет витрачається на дублі, а основні сторінки індексуються гірше.

Structured data. Product schema з offers, aggregateRating, availability — це rich snippets у видачі: зірочки рейтингу, ціна, наявність. Впливає на CTR.

Core Web Vitals на сторінках товарів. Hero image товару — це LCP element. fetchpriority="high" на першому зображенні, правильні srcset з WebP, width та height атрибути для запобігання CLS.

Що входить у результат роботи

Після завершення проекту ви отримуєте:

• Вихідний код та повну документацію (API, архітектура, інфраструктура);
• Доступи до репозиторію, хостингу, моніторингу (Sentry, Uptime);
• Навчання команди роботі з адмін-панеллю та кастомізаціями;
• Гарантійну підтримку 3 місяці (виправлення помилок, консультації);
• Детальний звіт по навантажувальному тестуванню та оптимізації.

Орієнтири за термінами

Вартість розраховується після аналізу вимог: кількість інтеграцій, складність ціноутворення, обсяг каталогу та унікальність UX — основні фактори. Оцінимо ваш проект безкоштовно — замовте консультацію.

Чек-лист перед запуском

• Race condition при оплаті останнього товару — покритий тестом
• Ідемпотентність вебхуків платіжного шлюзу
• Rate limiting на ендпоїнтах кошика та checkout
• Canonical на фільтрованих сторінках каталогу
• Фіскалізація чеків (ФЗ-54 для РФ або аналог)
• Стрес-тест checkout під навантаженням (k6 або Locust)
• Моніторинг помилок (Sentry) та алерти на payment errors
• Backup бази даних з перевіреним restore-процесом

Гарантуємо — кожен проект проходить цей чек-лист перед релізом. Зв'яжіться з нами — підберемо оптимальну архітектуру під ваш бюджет та терміни.