What Is fetchpriority="high" and Who Should Use It ?

Kaan Hanoğlu — Wed, 01 Jul 2026 09:30:44 +0000

If you've ever analyzed your website with Lighthouse or PageSpeed Insights, you've probably come across a recommendation similar to this:
The LCP image should have fetchpriority="high"

The first time I saw this warning, I was confused.

The website was already well optimized. It was running LiteSpeed Cache, images were compressed, WebP was enabled, lazy loading was configured correctly, Critical CSS was working, and LiteSpeed was even generating preload tags for my hero image.

So why was Lighthouse still complaining?

This question led me to spend several hours researching how modern browsers prioritize resources, what fetchpriority actually does, and why preloading an image is sometimes not enough.

I first encountered this issue while optimizing one of my client's production websites. During the optimization process, I was documenting performance improvements, Core Web Vitals tests, and SEO experiments on one of my own projects. That real-world testing environment helped me compare different optimization techniques and better understand how browsers handle resource prioritization. If you're curious, you can take a look at one of those production projects: Esenyurt Korsan Taksi. It's one of the websites I use to test real-world SEO and Core Web Vitals optimizations.

This article brings together everything I learned about fetchpriority="high"- what it is, when you should use it, when you shouldn't, and why such a small HTML attribute can make a measurable difference to your Largest Contentful Paint (LCP) and overall Core Web Vitals.

What is fetchpriority?

fetchpriority is an HTML attribute that allows developers to give the browser a hint about how important a particular resource is during page loading.

Modern browsers are incredibly intelligent.
Whenever someone visits your website, the browser immediately starts downloading dozens of different resources:

HTML
CSS
JavaScript
Fonts
Images
Icons
Videos
API requests

Since all of these resources compete for bandwidth, the browser needs to decide what should be downloaded first.

Usually, it does a pretty good job.

But browsers don't actually know which image is the most important for your visitors. That's where fetchpriority comes in.

For example:
<img src="hero.webp" alt="Hero Image" fetchpriority="high">

This simple attribute tells the browser:

This image is extremely important. Please prioritize downloading it before less important images.

It doesn't make your internet connection faster. It simply helps the browser make better decisions.

Why was `fetchpriority` introduced?

For many years, browsers relied entirely on their own algorithms.
They looked at things like:

Is the image visible?
Where does it appear in the HTML?
Has the page layout already been calculated?
Is it inside the viewport?

Most of the time those guesses were correct. Sometimes they weren't.
Imagine a landing page containing:

one large hero banner
twelve product images
several SVG icons
partner logos
background decorations
social media icons

Without any priority hints, the browser has to decide which image deserves attention first. Sometimes it starts downloading gallery images before the hero image.

Sometimes decorative assets compete with the image that users actually see first.

Every unnecessary delay affects Largest Contentful Paint. Google introduced fetchpriority to solve exactly this problem.

Understanding Largest Contentful Paint (LCP)

Largest Contentful Paint, commonly known as LCP, is one of Google's Core Web Vitals.

Instead of measuring how fast your entire website loads, it measures something much more important:

How long does it take until the largest visible content appears on the screen?

That content is often:

a hero banner
a featured article image
a landing page illustration
a large promotional image

Google recommends keeping LCP below 2.5 seconds. A slow LCP doesn't necessarily mean your server is slow.

Very often it means the browser simply didn't download the most important image early enough.

Preload and Fetch Priority are NOT the same thing

One of the biggest misconceptions I found while researching this topic is that many developers believe image preloading automatically gives an image high priority.

It doesn't. Let's compare both.

Image Preload
<link rel="preload" as="image" href="/hero.webp">

This tells the browser:

You will need this image soon.

The browser starts downloading it earlier.

Fetch Priority

<img src="/hero.webp" fetchpriority="high">

This tells the browser:

Among all images on this page, this one matters the most.

These are two completely different signals.

One starts the download earlier. The other influences download priority.

Using both together provides the strongest possible hint.

Why Lighthouse still complains

Many people believe preload is enough.

Technically, preload only tells the browser that a resource will probably be needed.

It does not explicitly say:

This resource should receive higher priority than other images.

Once the HTML parser reaches multiple <img> elements, the browser still has to prioritize them internally.

Without fetchpriority, it continues relying on its own heuristics.

That's why Lighthouse recommends adding both.

How browsers actually prioritize resources

Think about an airport. There are dozens of passengers waiting to board.

Without special instructions, everyone joins the queue.

Now imagine one passenger is told:

Please board first.

Nothing else changes.

The airplane doesn't become faster.

The runway doesn't become longer.

The order simply changes.

That's exactly how fetchpriority works.

It changes priority—not speed.

This tiny change can reduce waiting time for your most important content.

Should every image use `fetchpriority="high"`?

Absolutely not.

One of the most common mistakes developers make is adding:

fetchpriority="high" to every image.

For example:

<img fetchpriority="high">
<img fetchpriority="high">
<img fetchpriority="high">
<img fetchpriority="high">

This defeats the entire purpose. If everything is important...

Nothing is important.

The browser ignores excessive priority hints because they stop being meaningful.

When should you use it?

fetchpriority="high" is ideal for:

Hero banners
Landing page images
Featured article images
The image identified as your Largest Contentful Paint element
Above-the-fold content

These are the images users are waiting to see.

When should you NOT use it?

Avoid using it on:

Gallery images
Product thumbnails
Team member photos
Logos
Icons
Decorative illustrations
Images below the fold
Footer graphics

These resources don't need to compete with your hero image.

Can it improve performance?

Yes.

But it's important to have realistic expectations.

Adding fetchpriority="high" won't suddenly make your website one second faster.

Performance optimization rarely works that way.

Instead, it helps the browser make slightly better scheduling decisions.

During my own testing, I noticed:

Faster hero image rendering
Slightly lower LCP values
Better Lighthouse reports
More consistent loading on slower mobile devices

The improvements were usually measured in milliseconds rather than seconds.

But in Core Web Vitals, milliseconds matter.

My solution

Since LiteSpeed Cache wasn't adding the attribute automatically to the actual LCP image, I decided to create a small WordPress plugin for my own projects.

The plugin has one simple responsibility.

Whenever LiteSpeed preloads the main hero image, the corresponding <img> element also receives:

fetchpriority="high"

No settings.
No configuration.
No database tables.
No unnecessary features.

Just one tiny improvement that complements LiteSpeed's existing optimization.

Is LiteSpeed doing something wrong?

Not necessarily.

LiteSpeed Cache already provides an impressive amount of automatic optimization.

Every website has a different layout, different themes, and different methods of rendering images.

Determining which image is truly the Largest Contentful Paint element isn't always straightforward.

That's probably one of the reasons why LiteSpeed doesn't automatically add fetchpriority="high" to every preloaded image.

It leaves that decision to developers.

Final thoughts

One thing I've learned after optimizing many websites is that performance isn't always about installing more plugins or buying a faster server.

Sometimes it's about understanding how browsers think.

fetchpriority="high" is a perfect example.

It's a tiny HTML attribute.
It doesn't compress images.
It doesn't reduce file sizes.
It doesn't improve your hosting.

Yet it helps browsers identify the single most important image on your page and prioritize it accordingly.

If your Lighthouse report recommends adding fetchpriority="high", don't ignore it.

Take a few minutes to identify your LCP image, verify whether it's already preloaded, and make sure the browser also knows that it's your highest-priority visual element.

When combined with proper image optimization, modern formats like WebP or AVIF, responsive image sizes, caching, and intelligent preloading, this small attribute becomes another piece of the performance puzzle.

And as every performance engineer eventually discovers, websites rarely become faster because of one huge optimization.

They become faster because dozens of small optimizations work together.

PHP ile Güvenli Bir Giriş Sistemi Nasıl Oluşturulur? (Ve Sık Yapılan Güvenlik Hataları)

Kaan Hanoğlu — Mon, 16 Jun 2025 18:05:33 +0000

Web projelerinde kullanıcı giriş sistemi (login system), saldırıya en açık bölümlerden biridir. Özellikle PHP ile geliştirilen sistemlerde güvenliğe dikkat edilmediğinde XSS, SQL Injection, Session Hijacking gibi ataklar sisteminizi tehdit eder.

Bu yazıda, sıfırdan güvenli bir PHP giriş sistemi kurmanın temel prensiplerini ve dikkat edilmesi gereken noktaları paylaşacağım.

En Yaygın Saldırılar ve Önlemleri

SQL Injection Kullanıcının girdiği veriler doğrudan SQL sorgusuna aktarılırsa, saldırgan veritabanınızı silebilir veya kullanıcı bilgilerine erişebilir.

Çözüm:
Her zaman prepared statements (PDO veya MySQLi) kullanın:

$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute(['email' => $email]);

2. XSS (Cross-Site Scripting)
Formlardan gelen veriler filtrelenmeden ekrana yazılırsa, saldırgan kötü amaçlı JavaScript kodları çalıştırabilir.

Basit Çözüm:
formdan gelen verileri bir clean funcksiyondan geçirdikten sonra, Çıktıları htmlspecialchars() ile güvenli hale getirin: echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8');

3. Session Hijacking
Kullanıcı oturumu ele geçirilirse, saldırgan tüm işlemleri onun adına gerçekleştirebilir.

Çözüm:
session_regenerate_id(true) ile her login işleminden sonra session ID yenileyin.
HTTPS zorunluluğu ve SameSite, HttpOnly, Secure cookie ayarlarını kullanın.

Güvenli Giriş Sistemi İçin Ekstra İpuçları
Şifreleri daima password_hash() türlerinden biri ile şifreleyin.
Brute force saldırılarına karşı giriş deneme limiti koyun.
CSRF token kullanın.

Gerçek Hayatta Kullanım Örneği:
PHP ile geliştirilmiş bir ulaşım hizmeti sistemi olan İstanbul Korsan Taksi, kullanıcı deneyimini ve güvenliği ön planda tutarak php pdo ile geliştirilmiştir. Bu sistemde hem müşteri paneli hem de yönetici girişleri için güvenlik önlemleri titizlikle uygulanmıştır.

DEV Community: Kaan Hanoğlu