Computers & Electronics
88,661 views
25 min · 3 min read
7 steps
Advanced

How to build a personal photo website with a static site generator and image optimization

This guide walks you through creating a fast, attractive personal photo website using a static site generator and pragmatic image optimization. You’ll get a working site in a few hours, with responsive images, short build times, and simple hosting. Follow concrete steps and numbers to keep the project manageable and performant.

Verified by pleasexplain editors
  1. Step 1: Choose a static site generator

    Pick a generator focused on static assets and simple templates, such as Hugo, Eleventy, or Jekyll. Consider trade-offs: Hugo builds very fast for large galleries, Eleventy is highly flexible with JavaScript templates, and Jekyll integrates well with GitHub Pages. Allow 30–60 minutes to read quickstart docs and install the one that matches your comfort with templates and CLI.

    [Illustration: computer screen showing icons for Hugo Eleventy Jekyll with a checklist and a clock]

  2. Step 2: Organize your photo library

    Create a project folder with subfolders: raw/ for originals, edits/ for cropped JPEGs, web/ for final optimized assets; name files with YYYY-MM-DD-descriptor.jpg for consistent sorting. Limit initial upload to 200–500 images to keep builds under 1–2 minutes and to make testing faster. Spend 1–2 hours organizing and deleting duplicates before optimizing.

    [Illustration: folder structure diagram with examples of file names and a small stack of photos being sorted]

  3. Step 3: Set up the site scaffold

    Initialize a new site with the generator CLI, choose a minimal theme or starter, and create content folders like content/photos and layouts/partials. Configure baseURL, title, and output formats in the generator config file. Expect 20–40 minutes to scaffold, adapt a template, and confirm a local dev server runs at http://localhost:1313 or similar.

    [Illustration: terminal window showing site init commands and a browser displaying a starter photo page]

  4. Step 4: Resize and convert images

    Use a batch tool like ImageMagick or a script in Node/Python to generate multiple sizes (e.g., 320, 640, 1280, 2048 px width) and WebP versions in web/; keep quality at 75–85 to balance size and look. Automate this step with a single command that processes a folder in 5–30 minutes depending on number of images and CPU. Creating several sizes enables responsive srcset and reduces wasted bandwidth.

    [Illustration: photo thumbnails with different pixel width labels and image conversion command lines]

  5. Step 5: Integrate responsive templates

    Update templates to emit picture or img elements with srcset and sizes attributes, mapping to your generated filenames. Implement lazy loading with loading="lazy" and include width and height attributes or aspect-ratio CSS to avoid layout shift. Test a gallery page in 10–20 minutes to verify the browser picks appropriate sizes and lazy loading defers offscreen images.

    [Illustration: HTML snippet showing picture element and a webpage mockup with images loading progressively]

  6. Step 6: Optimize builds and caching

    Configure the static generator to skip large rewrites and to cache processed metadata; use incremental builds if available and limit image processing to changed files only. Add long Cache-Control headers for static assets on the hosting side (e.g., 1 year with hashed filenames) and a short max-age for HTML to allow updates. Spend 30–60 minutes setting up build caching and verifying headers on a test deployment.

    [Illustration: pipeline flowchart showing build steps, cache icons, and CDN with headers]

  7. Step 7: Deploy and monitor performance

    Host on a static platform like Netlify, Vercel, or an S3 + CloudFront setup; deploy directly from a Git repo with automated builds. Run Lighthouse and measure Largest Contentful Paint and total image bytes — aim for LCP under 2.5s on mobile and <1–2 MB total image payload for an initial view. Schedule a review every month to remove unused images and regenerate optimized sizes.

    [Illustration: deployment dashboard, Lighthouse scorecard, and a line graph of performance metrics over time]


  • Start with 100 images to prototype and scale later to avoid long build cycles.
  • Automate image generation with a script that records hashes to skip unchanged files and save CPU time.
  • Keep an editable copy of raw images offsite and only commit optimized web assets to the repo to reduce repo size.
  • Use descriptive filenames and add simple EXIF metadata (date, camera, location) to help search and organization.
  • Prefer WebP plus a JPEG fallback for older browsers; modern browsers will choose the smaller WebP automatically.
  • Use a CDN close to your expected audience and enable Brotli or gzip compression for HTML, CSS, and JS assets.

  • Don’t commit large binary originals to Git; repositories can balloon and slow clones—use external backups instead.
  • Avoid relying solely on client-side JavaScript to build galleries; heavy scripts can negate performance gains from static generation.
  • Be careful with automated overwrite scripts—always run on a copy or use version control to prevent irreversible loss.
  • Over-compressing images (quality <60) will introduce visible artifacts; test quality at multiple sizes before bulk processing.

Was this guide helpful?