Szybkość pobierania witryny na Opencart, zgodnie z instrukcjami PageSpeed Insights

Jest strona na Wix Studio. Na stronie kategorii produktów (strona dynamiczna) na urządzeniach mobilnych pojawiają się duże białe przerwy między kartami produktów, gdy niektóre pola są puste. Karty produktów bez danych zajmują ~1949px wysokości na urządzeniu mobilnym. Bloki akordeonów („Skład”, „Opis”, „Specyfikacje techniczne”) rezerwują dużą pustą przestrzeń, nawet gdy danych nie ma. Blok z galerią zdjęć również tworzy dużą białą przerwę, gdy zdjęcia nie ma. Co należy zrobić: Kiedy pola „Skład”, „Opis”, „Specyfikacje techniczne” są puste w CMS — nagłówki akordeonów powinny pozostać widoczne, ale pusta przestrzeń wewnątrz nie powinna być rezerwowana Kiedy zdjęcia nie ma - blok galerii nie powinien tworzyć dużej białej przerwy Poprawki powinny działać na wszystkich stronach kategorii, nie tylko na jednej Ważne: Nagłówki sekcji („Skład”, „Opis” itp.) powinny zawsze pozostawać widoczne. Należy usunąć tylko pustą białą przestrzeń wewnątrz.

Jest strona na Wix Studio. Na stronie kategorii produktów (strona dynamiczna) na urządzeniach mobilnych pojawiają się duże białe przerwy między kartami produktów, gdy niektóre pola są puste. Karty produktów bez danych zajmują ~1949px wysokości na mobilnym. Bloki akordeonów ("Skład", "Opis", "Specyfikacje techniczne") rezerwują dużą pustą przestrzeń, nawet gdy danych nie ma. Blok z galerią zdjęć również tworzy dużą białą przerwę, gdy zdjęcia nie ma. Co należy zrobić: Kiedy pola "Skład", "Opis", "Specyfikacje techniczne" są puste w CMS — nagłówki akordeonów powinny pozostać widoczne, ale pusta przestrzeń wewnątrz nie powinna być rezerwowana Kiedy zdjęcia nie ma - blok galerii nie powinien tworzyć dużej białej przerwy Poprawki powinny działać na wszystkich stronach kategorii, nie tylko na jednej Ważne: Nagłówki sekcji ("Skład", "Opis" itp.) powinny zawsze pozostawać widoczne. Należy usunąć tylko pustą białą przestrzeń wewnątrz.

Jestem profesjonalnym projektantem 3D, tworzę wysoko szczegółowe rendery pomników i kompleksów memorialnych (format pionowy 9:16). Moimi klientami są właściciele warsztatów i pracowni, którzy potrzebują wygodnego cyfrowego katalogu moich modeli do pokazania swoim detalicznym klientom. Co potrzebuję: Wybrać optymalną platformę i stworzyć lekki, szybki web-app (katalog), który będzie idealnie wyglądał na smartfonach i poprawnie otwierał się na komputerach. Kluczowe wymagania dotyczące katalogu: Design: Maksymalny minimalizm. Ciemny motyw (czarne tło), duże pionowe zdjęcie (proporcje 9:16), pod nim tylko nazwa/artykul modelu. Żadnych długich opisów. Zarządzanie bazą: Potrzebuję maksymalnie prostego systemu dodawania nowych modeli (idealnie — przez znane Google Arkusze lub bardzo wygodną wewnętrzną bazę danych). Muszę po prostu załadować zdjęcie i wpisać artykuł, nie łamiąc układu. Integracja z klientami (Najważniejsze): Katalog musi łatwo integrować się na stronach moich klientów-warsztatów (niektórzy mają WordPress, inni własne rozwiązania). Należy przemyśleć elegancki sposób osadzania: przez Iframe (aby katalog działał bezpośrednio w ich stronie) lub przez odpowiednie ustawienie przycisku-linku. Co już próbowałem: Testowałem Glide i Adalo. W Adalo uzyskałem potrzebny wizual (9:16 na czarnym tle), ale zarządzanie wewnętrzną bazą danych i zabawa z linkami do Google Dysku okazały się zbyt niewygodne do stałej pracy. Poza tym mam wątpliwości co do prawidłowego osadzania Iframe w cudzych stronach, aby nie rozjeżdżał się na szerokich monitorach. Oczekuję od was w odpowiedzi: Na jakiej platformie (Adalo, Glide, Bubble, Webflow, Glide + Airtable lub coś innego) proponujecie to zrealizować i dlaczego? Jak zostanie rozwiązany problem z przechowywaniem ciężkich zdjęć (renderów)? Jak proponujecie technicznie osadzić ten katalog na zewnętrznych stronach moich klientów? Szukam specjalisty, który zamknie ten techniczny ból pod klucz, abym mógł spokojnie zajmować się modelowaniem 3D.

Strona internetowa jest już uruchomiona i działa. Główne zadanie to zrozumienie obecnej struktury projektu, sprawdzenie jakości realizacji, naprawienie znalezionych problemów technicznych oraz pomoc w dalszych zmianach.Główna technologia Next.js 15 React 19 TypeScript Tailwind CSS Zod Redux Toolkit W projekcie mogą być również używane: Prisma JWT-uwierzytelnianie Stripe Mailgun Google APIs Vercel lub Netlify FunctionsGłówne zadania przeprowadzenie audytu istniejącego projektu; ocena struktury i jakości kodu; naprawa błędów i rozwijanie obecnej funkcjonalności; poprawa renderowania po stronie serwera i szybkości ładowania stron; sprawdzanie poprawności wyświetlania strony na urządzeniach mobilnych; praca z formularzami, częścią administracyjną i zewnętrznymi integracjami; wnoszenie technicznych zmian SEO; wspieranie i stopniowe ulepszanie istniejącej strony.Co jest dla nas ważne dobre doświadczenie w pracy z Next.js, React i TypeScript; umiejętność rozumienia cudzych kodów; zrozumienie SSR i specyfiki Next.js App Router; uwaga na wydajność i jakość realizacji; umiejętność wyjaśniania znalezionych problemów i proponowania zrozumiałych rozwiązań; samodzielność i staranna praca z działającą stroną. Na pierwszym etapie należy zapoznać się z projektem, przeprowadzić audyt techniczny i zaproponować listę priorytetowych zmian. Po tym możliwa jest stała praca nad dalszym rozwojem strony.

Szukamy doświadczonego programisty Embedded do stworzenia energooszczędnego oprogramowania dla urządzenia noszonego (format: pas piersiowy) do monitorowania stanu psychofizjologicznego. Projektowanie schematu zostało zakończone, rozwój będzie prowadzony na bazie płytki deweloperskiej (Development Kit) z późniejszym przeniesieniem na niestandardową płytkę.Stos i baza sprzętowa:MCU: Nordic Semiconductor nRF52840 lub nRF5340.Środowisko programistyczne: nRF Connect SDK / Zephyr RTOS (wyłącznie C/C++).Peryferia:Optyczny czujnik pulsu (PPG) — komunikacja przez I2C.6-osiowy czujnik inercyjny (IMU akcelerometr + żyroskop) — komunikacja przez SPI.Sterownik silnika wibracyjnego (LRA 1030) — sterowanie przez PWM.Zewnętrzna pamięć SPI Flash do cyklicznego logowania.Zakres pracy według etapówEtap 1: Uruchomienie, sterowniki peryferiów i telemetria BLECel: Ożywić sprzęt, skonfigurować stabilne zbieranie danych i ich przesyłanie na smartfon/PC.Konfiguracja pracy szyn I2C i SPI z wykorzystaniem DMA (Direct Memory Access) w celu odciążenia procesora.Pisanie/integracja sterowników dla PPG i IMU (konfiguracja częstotliwości próbkowania, buforów FIFO czujników).Rozwój niestandardowego profilu BLE (usługa GATT) do przesyłania surowych danych z czujników w czasie rzeczywistym.Podstawowa inicjalizacja PWM do sterowania silnikiem wibracyjnym LRA (uruchomienie testowych wzorców wibracji).Etap 2: Warstwa algorytmiczna (DSP i wielopoziomowa logika sprzężenia zwrotnego)Cel: Zrealizować matematyczne przetwarzanie sygnałów bezpośrednio na chipie (Edge Computing) oraz logikę reakcji urządzenia.Realizacja algorytmów filtracji artefaktów ruchu: oczyszczanie sygnału PPG z wykorzystaniem danych z akcelerometru (IMU).Wydobycie interwałów R-R (HRV) z oczyszczonego sygnału PPG.Realizacja 4-poziomowej logiki stabilności systemu:Poziom Dryfu: Śledzenie płynnych zmian HRV i oddechu.Poziom Predykcji: Obliczanie matematycznego trendu na pogorszenie stanu.Poziom Mikro-korekcji: Generowanie ledwo zauważalnych wzorców wibracji na silniku LRA przy wykrywaniu docelowego wzorca danych.Poziom Sprzętowego resetu: Realizacja logiki bezpieczeństwa (wysokointensywny impuls wibracyjny przy krytycznych wskaźnikach).Etap 3: Oszczędność energii, logowanie i odporność na awarieCel: Przygotowanie urządzenia do autonomicznej pracy z miniaturową baterią i zapewnienie stabilności „24/7”.Głęboka optymalizacja zużycia energii. Przełączanie MCU w tryb uśpienia (System ON/OFF) między cyklami pomiarów. Procesor powinien budzić się tylko na przerwania z buforów FIFO czujników lub timera.Pisanie odpornej na awarie systemu plików w zewnętrznej pamięci SPI Flash (np. LittleFS) do autonomicznego cyklicznego zapisywania logów.Konfiguracja sprzętowego timera watchdog (Watchdog Timer) w celu zapobiegania zawieszaniu się oprogramowania.Wymagania wobec wykonawcy:Doświadczenie w komercyjnej produkcji dla chipów Nordic (nRF52/nRF53) od 3 lat.Pewna znajomość Zephyr RTOS i narzędzi debugowania (Segger Embedded Studio / VS Code, J-Link).Zrozumienie zasad działania cyfrowej filtracji sygnałów (DSP) i pracy z niskim zużyciem energii (Low-Power design).Posiadanie własnego zestawu deweloperskiego (nRF52840-DK lub podobnego) do rozpoczęcia pracy jest mile widziane.Format pracy:Płatność etapowa (Milestones) z dokumentacją wyników na GitHubie. Proszę podać swoją stawkę godzinową lub przybliżoną wycenę kosztów i terminów dla każdego z trzech etapów.