Image SEO: alt text, file names and compression
Image SEO is mostly three habits done consistently: write alt text that actually describes the image, name the file something a human would understand, and compress it before you upload. None of this will single-handedly rank a page, but on a heavy-image site like a hotel, restaurant or product catalogue, ignoring it costs both accessibility and load time, and load time is the part that costs you visitors on mobile data.
Most guides to image SEO oversell it. Alt text on a decorative background image will not move your rankings, and no amount of file-name cleverness turns a mediocre photo into a reason to rank higher. Google has said plainly that image search and image-related signals are a small piece of overall ranking for most queries.
What image SEO actually buys you is threefold: your product and gallery photos become eligible to show up in Google Image search, which is real traffic for anyone selling something visual, a screen reader user can understand what a blind visitor to your site is looking at, and a page full of uncompressed 4MB photos stops being the reason your site loads like it's 2010 on a 3G connection. For a Nepali hotel, trekking operator, restaurant or retailer whose whole product is visual, that combination is worth doing properly.
Alt text and file names, briefly, then the technical side
This site has a dedicated beginner's guide to writing alt text that covers the wording in full: describe the image in one specific sentence as if speaking to someone who can't see it, skip 'image of' and 'picture of', use alt="" on purely decorative images, and never stuff keywords. The same discipline applies to file names, rename the camera's IMG_4021.jpg to something like deluxe-double-room-mountain-view-pokhara.jpg before you upload, using lowercase words separated by hyphens.
If you only came here for the writing rules, that guide, not this one, is the right page. What follows here is the part that guide deliberately leaves out: what happens to the image file itself after the words are right, compression, format, loading behaviour and layout stability, which is where most of the actual page-speed cost of images lives.
Compression and file size: this is the part that actually affects speed
If you only do one thing from this guide, compress your images before uploading. A phone camera or a professional DSLR routinely produces photos of several megabytes each, and a page with a dozen of those loading uncompressed is a multi-megabyte page. On a fast fibre connection in an office that's barely noticeable. On mobile data in most of Nepal, it is the single biggest reason a site feels slow, and it directly hurts the Largest Contentful Paint metric covered in this site's Core Web Vitals guide.
The good news is that compression is close to a free lunch. Modern compression tools can cut a photo's file size by 60 to 90 percent with no visible quality loss to a normal viewer, because photography files carry far more data than a screen actually needs to display them well.
- Resize to the display size first. Don't upload a 4000px-wide camera photo to display in a 600px-wide content column, resize it to roughly what it will actually render at, plus a bit of headroom for retina screens.
- Use a modern format where you can. WebP is now widely supported and typically produces meaningfully smaller files than JPEG at equivalent visual quality; AVIF compresses even further where your platform supports it.
- Run photos through a compressor before upload, tools like Squoosh, TinyPNG or your image editor's own 'save for web' export all work. Most CMS platforms and WordPress plugins can also compress on upload automatically, worth checking whether yours already does this.
- Set an explicit width and height (or CSS aspect-ratio) on every image tag so the browser reserves the space before the image loads, this stops the page jumping around as images pop in, which is its own separate ranking and usability issue covered under Cumulative Layout Shift.
- Don't over-compress to the point of visible artifacts, especially on food, product or room photos where quality is doing real selling work. There's a sensible middle ground between a 6MB original and a blurry, blocky mess.
Lazy loading: the basics, and where it backfires
Lazy loading means the browser doesn't fetch an image until it's about to scroll into view, instead of downloading every image on the page immediately regardless of whether the visitor ever scrolls that far. For a long page with a lot of images below the fold, a gallery page or a product listing, this can meaningfully cut how much data loads on first visit.
The mistake, and it's a genuinely common one, is lazy-loading the image at the very top of the page, the hero photo or the first thing a visitor sees. That image is often what Google measures as your Largest Contentful Paint, and lazy loading it means the browser deliberately delays fetching the one image whose speed you're being graded on. Lazy loading is right for the tenth photo in a gallery. It is actively harmful for the first thing on the page.
- Add loading="lazy" to images below the fold, most modern browsers support this natively with no library needed.
- Never add loading="lazy" to the hero image, the header banner, or anything visible without scrolling, let those load eagerly.
- If you're on WordPress or a similar CMS, check whether a plugin is lazy-loading everything indiscriminately, including your logo and header image, this happens more often than you'd expect and is worth a five-minute check.
- Lazy loading fixes how much loads late, not how heavy each individual image is. Do both: compress the file and load it at the right time.
When images genuinely help rankings, and when they're just accessibility hygiene
It's worth being honest about the ceiling here so you spend effort where it pays off. Image search traffic is real for visually driven queries, hotel rooms, trekking routes, food dishes, product photos, and Google Images is a meaningfully different, less crowded discovery channel from regular web search for those categories. Getting alt text, file names and structured product images right is a legitimate way to pick up incremental traffic there.
For a page whose ranking depends on a text query like 'best trekking agency in Kathmandu', though, the images on that page are not what will move it up or down in web search results. Text content, headings, links and technical fundamentals do that work. Treat image optimisation as: mandatory for accessibility and page speed on every image, worth extra care for a genuine chance at image-search traffic on product, food and destination photos, and not worth agonising over for a decorative background graphic.
Key takeaways
- ✓Alt text is an accessibility feature first, describe the image specifically and briefly, no keyword stuffing, alt="" for purely decorative images.
- ✓Rename image files to lowercase, hyphenated, descriptive names before uploading, not the camera's default IMG_ string.
- ✓Compress every image before upload and resize to display size; this is the single change most likely to speed up an image-heavy Nepali site on mobile data.
- ✓Set width and height on every image tag so the layout doesn't jump while images load.
- ✓Lazy-load images below the fold, never the hero image at the top of the page, that one needs to load immediately.
- ✓Images matter most for Google Image search traffic on visual categories like hotels, food and products; for regular web search rankings, text and technical fundamentals do the heavy lifting.
Explore the data behind this guide
Image SEO, FAQ
Does image compression affect SEO?+
Indirectly but meaningfully. Compression itself is not a ranking factor, but oversized image files slow a page down, and page speed feeds directly into Largest Contentful Paint, one of the Core Web Vitals Google measures as part of page experience. Compressing images is usually the single fastest way to improve that metric on an image-heavy site.
What's the difference between WebP and AVIF?+
Both are modern image formats that compress more efficiently than JPEG or PNG at similar visual quality. WebP has broader, more mature support across browsers, CMS platforms and plugins, making it a safe default. AVIF generally compresses further still but has slightly less universal tooling support, so it's worth using where your host or CMS serves it automatically but not worth chasing manually if your platform doesn't support it yet.
How much should I compress images before uploading?+
Enough that the file is resized to roughly its actual display width and run through a compressor like Squoosh, TinyPNG, or your editor's web-export option. Most photos can shrink 60 to 90 percent with no visible quality loss because cameras capture far more detail than a screen displays. Stop short of visible blockiness or blurring, especially on product and food photos.
Should I lazy-load every image on my page?+
No. Lazy-load images below the fold so the browser doesn't fetch what a visitor may never scroll to. Never lazy-load the hero image or anything visible on first load, that image is usually what Google measures as your Largest Contentful Paint, and delaying its fetch directly hurts your page speed score.
What format should I use, JPEG, PNG or WebP?+
WebP generally produces smaller files than JPEG at similar visual quality and is now widely supported, so it's a solid default for photos. Use PNG only where you need transparency or crisp flat graphics like logos. AVIF compresses further still where your CMS or hosting supports serving it.
Does lazy loading hurt my Largest Contentful Paint score?+
Only if you apply it to the wrong image. Lazy loading images below the fold is good practice and doesn't affect LCP, since those images aren't part of the initial render. Lazy-loading the hero image or anything visible without scrolling directly hurts LCP, because that's usually the exact element Google is timing, and lazy loading deliberately delays fetching it.
Related guides
Sources & data note
This guide describes documented practice from Google Search Central and web.dev, cited above, on alt text, image publishing and lazy loading. Nepal-specific framing, mobile-data conditions, and the recommendation to treat image work as secondary to text-based ranking factors are our own synthesis rather than a figure lifted from a cited source, and are not separately sourced. Guides are written from primary sources, Nepali government departments, operators, park authorities and standards bodies, and each guide lists the sources used for its own facts. Rules, fees and prices in Nepal change; treat figures as current at the review date shown on each guide and verify anything money- or visa-critical with the issuing authority before you rely on it.