When a product website has many images and feels slow on phones, start with one representative listing and one product detail page. Record the files actually downloaded, their display dimensions and when requests begin. Then work through image preparation, theme output and cache updates. Check product details, mobile reading and the enquiry entry point while comparing results under the same test conditions.
This checklist is for marketing staff, content editors and delivery teams managing business websites and export product catalogues. Use the website copy and image materials checklist for preparation and the product centre implementation guide for categories and specifications. Actual performance must be measured on the project pages.
1. Use two page records to locate the delay
Choose a listing with a representative number of images and a frequently used product detail. Open both language versions on a phone and follow the customer journey: enter the listing, open a model, inspect its image and find the enquiry link. Record where waiting or movement occurs. Ask the delivery team to inspect network requests and a performance trace.
| Observation | Evidence and next action |
|---|---|
| A long wait before page content appears | Record HTML response time, server and cache state for the maintainer |
| Text appears while the main image keeps waiting | Record image URL, bytes, request start, download and decoding |
| An arriving image moves a heading or button | Compare reserved layout space with the actual image ratio |
| Scrolling, galleries or menus feel sluggish | Inspect image count, pixel dimensions, decoding and script activity |
Assign the evidence to its owner. Editors supply originals and display files; theme developers handle markup and interactions; hosting maintainers investigate responses, caching and delivery. The SSR, static generation and SPA checklist covers rendering choices. Change one related group of factors at a time so the cause can be reviewed.
2. Prepare files for their display positions and retain originals
Keep a record for each image: model, view or purpose, original location, display file, page position, pixel dimensions, byte size, description and approver. Listing covers, detail images, close-ups and manual illustrations can have separate deliverables. Retain originals in the agreed team archive and publish approved display files.
First measure the rendered width. Choose export dimensions using target device density, any zoom requirement and a clarity review. For example, a 360 CSS pixel region can use a 720 pixel candidate for a 2x density trial. This is a dimension calculation example; real devices and detail inspection determine the final file. Review model markings, connectors, scales and safety information that customers need to identify.
For photos, compare JPEG or WebP candidates for bytes and visible detail. Verify transparency where needed. Formats such as AVIF also require checks against available tools, upload rules and target browsers. Prepare candidates with recorded dimensions, format and compression settings. Business staff approve image meaning and the delivery team records the selected file. Agree byte budgets using the image purpose and measured results.
Record pixel dimensions, file bytes and layout width separately. After CSS shrinks an image into a small region, inspect which file the browser actually downloads. Prepare an English version for images containing Chinese labels. Keep specifications in editable page text and check both languages with the multilingual content update checklist.
3. Deliver initial-view and offscreen images separately
Mark critical initial-view images and later images for the home page, listings and details. For the largest visible image, check discovery in the initial page, request delay and measured priority. Google's LCP optimization guide explains resource discovery and priority. Critical images usually use normal loading; offscreen images can use native browser lazy loading, with their placement checked across devices.
For multiple sizes of one photo, the theme can supply srcset and sizes with a fallback src. Generate and serve the actual candidate files first. Developers should inspect the chosen resource in the network panel. See the web.dev responsive image guide for markup and selection rules.
Reserve space matching the display image ratio through correct width and height attributes or the theme layout. Test landscape, portrait, transparent and missing-image cases in listings. On detail pages, check whether gallery changes hide explanations, crop connectors or move enquiry buttons. Carousels and zoom are theme-specific interactions that need both measurement and operation checks.
4. Make images understandable to customers and search engines
Give meaningful product images alternative text appropriate to the current position. For the matching view, an example is “PX-100 pressure sensor side view showing the threaded connector.” Decorative images can use empty alternative text. Express the same product facts in each language and keep the model, purpose and necessary explanation nearby. Google's image SEO documentation covers standard image elements, context and alternative text.
A team naming convention such as model, view and revision can help trace source files. Also record the actual resource URL after upload. Use page titles, body text and descriptions together to answer the product question. Continue using the approved source and usage records for licensed images, customer marks and photos of people.
Open each image URL before release and check its status, actual media type and content. Then verify the image matches its text in both listings and details. Use the website SEO checks for canonicals, language links, content and related links. Indexing, rankings and AI citations require their own observed evidence.
5. Confirm how CatchCMS data, uploads and themes work together
CatchCMS content records provide base fields including cover, gallery and body. Cover and body can be maintained by language. Organize product information with content models and custom fields; the public Blade theme reads and displays it. After saving an image URL, verify how the selected theme consumes that data.
Prepare display files first, then upload them using the project configuration. The local upload path reviewed for this guide saves the original file bytes. Confirm the actual upload entry point, driver and allowed formats for the project. Upload an approved sample and compare the returned file's dimensions and bytes. List responsive variants, automatic AVIF/WebP conversion, image CDN delivery, cache invalidation and batch processing of existing files individually in the project scope, with evidence for each delivered result.
Inspect srcset, loading priority, reserved dimensions, alternative text and galleries in the specific templates. For a separate business website theme, test image changes, language overrides and public output with one test record before a wider update. See the AI website and theme delivery checklist for compatibility and rollback planning.
6. Check caches and references when replacing an image
- Save the previous state: record content ID, language, old image URL, affected pages and the original file location.
- Upload the replacement first: check URL, dimensions, media type, clarity and source. Give versioned assets a new file URL to distinguish revisions.
- Update actual references: review cover, body, gallery, fixed theme positions and language overrides. Identify each page sharing the image.
- Handle the configured cache layers: have the maintainer confirm application, CDN and browser caching, then perform the required refresh or asset release.
- Read the public result: check normal and cold-cache visits for the downloaded URL, actual image, language and mobile crop. Retain the previous record for restoration.
Keep separate evidence of the new page and the new downloaded file. Agree retention periods, historical references and cleanup dates with the maintenance team. Check current references before removing old assets. With multiple sites, confirm the release scope and effects of shared resources by site.
7. Fictional example: an acceptance check for PX-100
All model details, dimensions and file sizes below are fictional workflow examples. An equipment company has Chinese and English PX-100 pages. Its listing image region is about 360 CSS pixels wide, and the detail page must show the connector. The materials include a 4000×3000, 3 MB original. The delivery team prepares a 720 pixel listing candidate and a 1440 pixel detail candidate, provisionally recorded as 90 KB and 220 KB. Business staff inspect markings and connector detail.
These file sizes illustrate the record format. The team verifies cropping and languages in preview, then releases approved files. It checks that the listing uses its candidate, the detail uses the intended main image, later images load as planned during scrolling and buttons remain stable as images appear. English alternative text describes the same view; Chinese labels within images receive separate treatment.
Enter actual before-and-after measurements for LCP, CLS, request bytes and experience checks. Mark unmeasured cells “pending measurement.” Candidate file sizes illustrate preparation; speed, traffic and enquiry changes each need real records. Where the scope includes an enquiry test, follow the form records and email checklist using an approved test submission.
8. Repeat under matched conditions and hand over evidence
Use the same URL, language, device, browser version, network and CPU settings for at least three runs per condition. Save every result and timestamp, and record the median. Keep cold-cache and repeat visits separate. Real phone checks can supplement simulation; export websites should add records from target customer regions. Log page versions, asset versions and third-party script changes during the comparison.
Measure when primary initial content appears, layout stability and actual interaction quality. The official Web Vitals guide defines current metrics and real-user assessment. Lab tests support diagnosis and comparisons. For real-user reports, record the source, time window, sample and page or origin scope. Keep scores, indexing and acquisition results in separate records.
- Page and conditions: URL, language, release, device and viewport, browser, region and network, cache state and time.
- Image delivery: original and display files, downloaded URL and bytes, rendered dimensions, loading position, alternative text and approver.
- Performance: each LCP and CLS result, image requests and bytes, interaction observations, raw reports, median and unresolved cause.
- Business acceptance: model and details, mobile crop and layout, language consistency, related links, enquiry entry point, owner and retest date.
To improve product image delivery: prepare Chinese and English URLs for one listing and one detail, three approved originals, target customer regions and existing measurements. Use CatchCMS project enquiries to confirm the scope for display files, theme image output and resource delivery. Complete acceptance for these representative pages, then apply the agreed process across the product library.