Herkese merhabalar, Zeo takipçileri. Bugün biraz daha geliştiricilerin ve proje yöneticilerinin ilgisini çekecek bir konuyla daha karşınızdayız. Bugün birazcık daha teknik bir konudan bahsedeceğiz: yukarıda görülen "single page apps" ve "client-side framework" söylemleri size biraz yabancı gelebilir, eğer geliştiricilik dünyası içerisinde değilseniz. Bunların hepsini yavaş yavaş size açıklayacağız, en basitinden yola çıkarak. Şimdi aslında burada gördüğünüz bu iki kavram, sizin hemen hemen birbirine yakın kavramlar zaten. Sizin daha akıcı bir web deneyimi yaşamanızı sağlamak adına, yeni nesil geliştiriciler tarafından hazırlanan kavramlar. Burada aslında bu sistemin nasıl çalıştığını anlayabilmemiz için önce sistemin temeline inelim. Normal koşullarda siz web'de bir sayfayı açtığınız zaman, aslında "zeo.org" yazıp enter'a bastığınız zaman tarayıcınızda, tarayıcınız bir DNS sunucusuna gidiyor ve diyor ki: "Bana zeo.org'un IP adresini ver."
Yani bana yerini söyle. O da ona dört noktalık bir satırla dönüyor ve diyor ki: "Şu IP'de, git oraya sor." Sonra gidiyor benim tarayıcım, oraya bir istek atıyor: "Bana zeo.org'un bilgilerini verir misin? Burada olduğunu söylediler." diyor. O da ona cevap veriyor. Dolayısıyla burada bir sunucu var, burada bir tarayıcı var; ikisi birbirleriyle konuşuyorlar ve veri transferini tamamlayıp sizin gördüğünüz web sayfasını oluşturuyorlar. Bu güzel bir çalışma, gayet web'in bugüne kadar gelmesini sağlayan ve neredeyse web'deki sitelerin %90'ından fazlasının kullandığı bir teknoloji. Ancak günümüzde daha akıcı sayfa geçişleri vs. isteyen kullanıcılar, şey, geliştiriciler, yeni bir katman daha koyuyorlar buraya. Diyorlar ki: "Burada bir sunucu var, burada bir tarayıcı var; ben araya bir app yapayım, bir app yaratayım." Ama bu app, böyle mobil uygulamalardaki app'imiz gibi düşünmeyin bunu; tarayıcımızın içerisinde yaşayan bir uygulama gibi.
Ve ben burada, sayfada değişen ne varsa, bunu bu app'e yükleyeyim, kullanıcı da buradan bunu alsın. Aslında bana ilk başta diyor ki: "Yiğit, ben sana bir app gönderiyorum, 550 kilobaytlık. Bunu bir al, sonra ben sana bütün değişimleri söyleyeceğim, sen onu app'in üzerinde değiştir." diyor aslında. Ve böylece ben her sayfayı tekrar yüklemiyorum ve çok akıcı bir şekilde bir deneyim elde etmiş oluyorum. İşte o yüzden bunun adı "single page apps". Çünkü tek bir sayfa var, bir kere yükledim; sadece değişen şey, benim sayfada yaptığım işlemlere göre, tıkladığım yerlere göre, bana sistemden gelen dönüşler.
Burada da API sistemi kullanılıyor; yani uygulamaların kendi aralarında konuştukları bir dil. JSON olabilir, XML olabilir. Bu formatta, sadece sayfanın değişen kısmını sunucu gönderiyor. Böylece ne oluyor? Her sayfa arası geçişte neredeyse 20-25 kat daha az veri transferi oluyor ve inanılmaz akıcı bir deneyim oluyor. Bunun avantajlarını konuşacak olursak, tabii ki boyutun azalmasından ötürü en büyük avantajı mobil görüyor. Çünkü neden? Mobil telefonlarımız aslında eskimiş bilgisayarlar, yavaş bilgisayarlar ve her zaman harika internet hızına sahip olamayan ortamda olabiliyorlar. Çünkü yerleri sürekli değişiyor. Öyleyse mobil deneyimde bu "single page apps"ler bize inanılmaz bir avantaj sağlıyor, her şeyden önce. Bunlar nasıl uygulamalardır? Bunları nerede bulabilirim, nasıl test edebilirim diyorsanız, aşağıya sizin için serpiştirdik bunları: React'ler var, Backbone var, Vue.js var, muhtemelen duydunuz; Angular.js var, Ember, Meteor, Knockout gibi birçok farklı şey var.
Hatta ve hatta burada boşluk bulunca bir de Yiğit JS yazdık. Her gün yeni bir client-side framework hayatımıza giriyor ve bununla alakalı bir standardizasyon henüz oluşmuş durumda değil. Aslında problem de biraz burada başlıyor. Avantajlarda temelde mobil deneyim dedik. Buradaki yapıyı hatırlarsanız, app'i bir kere bir browser'ıma ben yüklemiştim. Hani bu sizin böyle fark ederek yüklediğiniz bir şey değil ama, o sitenin çekirdeğini yüklemiştim ve bütün sayfada değişen veriyi bana API dediğimiz sistem aracılığıyla geliyordu. Evet, bu da ne anlama geliyor? Daha hızlı bir sayfa geçiş deneyimi yaşayacağım. Çok akıcı olacak bütün sayfalar arası geçiş. Böyle olunca ne olacak? İnsanlar sitede daha fazla kalacak ya da bir kullanıcı, bir oturum başına daha fazla sayfada gezecek.
Çünkü bir sayfayı tıkladığı zaman, birkaç yarım saniye içerisinde o sayfanın içeriği onun için yüklenmiş oluyor. İnanılmaz bir sayfa hızı demek. Bu sayede kullanıcı dostu, çok akıcı ve de bakım maliyeti nispeten daha ucuz. Bir kere ürettikten sonra. Çünkü bütün data API'ler aracılığıyla sunuluyor ve çok rahat bir şekilde bunu yönetebiliyorsunuz. Şimdi gelelim bunun dezavantajlarına. Dezavantajlar noktasına geldiğimiz zaman, en temel problem ilk yüklenme hızı. Ne demiştik? Sunucu bana önce bir app gönderiyor ve diyor ki: "Yiğit, sen bu app'le konuş, ben bu app'e bilgileri gönderirim API aracılığıyla."
Okey, peki bu app ne kadar? Bu app'ler gerçekten büyük, boyut olarak. Dolayısıyla bu sistemlerin ilk yüklenme hızları gerçekten yavaş oluyor ve bu çok arzu etmediğimiz bir durum. Maalesef bu bir dezavantaj. Öte yandan SEO implementasyonu. SEO sürecinde Google Bot, bir sayfaya geldiği zaman sayfaları tıklayarak geziyor ve buradaki bilgiyi kendi veri tabanına kaydediyor demiştik. İşte burada SEO için bir negatif durum söz konusu. Çünkü standart yaklaşım diyor ki: "Google Bot, JavaScript olan sayfaları çalıştıramaz." Yani bu bir web teknolojisi ve bu web teknolojisini kullanan sayfalarda ben diyor, bu teknolojiyi çalıştıramıyorum diyor.
Öyle olduğu zaman ne yapıyor? Aslında benim app'imi çalıştıramıyor. Çünkü Google Browser Server, Browser Server eski tip bu yapıya alışmış ve eskiden bunu indeksleyemiyordu. Çünkü JavaScript zorunlu. Bir diğer dezavantaj. İkisi çünkü birbiriyle ilişkili. İşte Google artık bunu çözdü. Nasıl çözdü? Nasıl bir aksiyon alacağım? Bunu ilerleyen adımlarda daha rahat konuşacağız. Öte yandan bu sistemler genellikle tek sayfa olduğu için, geri butonuna basıldığı zaman bütün app'ten bir adım geriye gidebiliyor. Bunun için push state gibi farklı farklı çözümlerimiz var ama basit implementasyonlarda bu da bir negatif durum. Öte yandan geliştirme maliyeti. Şu aşağıda yazılı olan teknolojilerin hepsini yazan harika developer'lar hem çok pahalılar hem de nesilleri tükenmek üzere.
Çünkü çok az sayıdalar. Onların çoğalması için çaba sarf ediyoruz ama az sayıda bulunmaları geliştirme maliyetlerini de yükseltmiş oluyor. Şimdi bu konuyla alakalı aslında burada bu kadar güzel avantajım varken, bizim SEO danışmanları olarak, "Siz single page apps kullanmayın, siz client-side framework kullanmayın" demek gibi bir özgürlüğümüz bence yok. Çünkü biz aslında SEO'nun temelinde kullanıcıların deneyimini artırmak ve onları daha iyi bir noktaya, daha iyi bir deneyime taşımak istiyoruz. Burada harika avantajlar var. Evet, burada dezavantajlar olabilir. Peki ben bu dezavantajları nasıl elimine edebilirim ki bu avantajları kullanmak hâlâ benim için kârlı ve mantıklı olsun?
İşte tam olarak bu noktada, burada farklı çözüm önerileriyle geliyoruz. Bu çözümlerden ilki, Ajax Scrolling dediğimiz sistem. Aslında Google diyor ki: "Okey, web değişiyor, ben bunu biliyorum ve bu web'in değişimine karşılık olarak da benim bu JavaScript'leri indekslemem lazım." Ama Google'ın bu JavaScript denilen sistemi çalıştırmak için bir yeterliliği yok diyemeyiz. Çünkü dünyanın en büyük teknoloji şirketinden bahsediyoruz. Bizim basit cep telefonlarımızda bile yorumlanabilir bir JavaScript'i Google nasıl çalıştıramaz? Buradaki temel problem aslında taramanın genelinden başlıyor. Google web'i genel olarak tarıyorken aslında bu JavaScript'lerin hepsini çalıştırıyor olsa, bu sefer bu tarama işlemi inanılmaz yavaşlayacak. Çünkü bu inanılmaz derecede kaynak isteyen bir şey, işlemci gücü gerektiren bir şey ve Google buna girişmek istemiyor.
Bu tarihlerde, 2015'lerden, 2014'lerden bahsediyorum. Bu durumda Google diyor ki: "Tamam, ben JavaScript'i crawl edemiyor olabilirim. Siz bana JavaScript'le oluşan sayfanın benim okuyabildiğim şu ikili sistem vardı ya, sunucudan browser'a, o sisteme göre bana HTML çıktılarını verin." Yani bir nevi screenshot'ları gibi düşünün bunu siz. Bunun snapshot'ları, HTML şeklinde tabii ki. Buradan serve edilsin, buradan servis edilsin ve bana diyor ki: "Bunu escape fragment adında bir parametreyle bana bunu push edin." diyor Google. Bu, Google'ın çok önerdiği bir çözümdü. Uzun yıllar boyunca kullanıldı. Böylece Google JavaScript'i indekslemek zorunda kalmadı. Kullanıcılar kendi JavaScript'leriyle indeksleterek oluşan sayfaları Google'a verdiler. Ama bunun da birçok dezavantajı var.
Teknik bir konu, çok detaylarına girmeyeceğim ama sayfa her değiştiğinde burada tuttuğum cache'i de değiştirmem gerekiyor ki Google bunu görebilsin gibi tonla problem var ve bu Google'ın uzun vadede tercih edeceği bir sistem değil. İşte bu noktada Ajax Scrolling aslında şu an hâlâ SEO uzmanları tarafından sıkça öneriliyor olsa da, aslında mükemmel bir sistem değil. Neden derseniz, tamamen ve tamamen kullanıcıya bırakıyor işi. Yüksek bir oranda implementasyon yapmak gerekiyor, teknik bir tarafı da var bu işin ve bunu herkes uygulayamaz. Öyleyse Google'ın buna bir alternatif bulması gerekiyordu ve 2015 yılının sonunda dedi ki: "Hayır, ben artık burayı depreşe ediyorum, yani burayı kapatıyorum.
Yakın tarihte bunu tamamen yayından kaldıracağım." Ama hâlâ kullanıyorsanız, bir şey değiştirmenize gerek yok. Eğer bunu yapmak zorundasanız da yapın, ama ben zaten JavaScript'lerinizi indeksleyebiliyorum, dedi. Öyleyse client-side framework'ler ve altta gördüğünüz sonu JS ile biten her şey, madem Google tarafından indekslenebiliyor, öyleyse hiçbir problem yok. Aslında Google'ın bütün problemi çözmüş olması lazım, değil mi? Beklediğimiz durum bu. Ama aslında hayır. Oluşan gerçeklik bu değil. Google, bu JavaScript framework'leri hâlâ etkili bir şekilde indeksleyemeyebiliyor. Çünkü bunu bütün dünya scale'ında yapıyor. Çok büyük bir oranda yapıyor ve belli hatalar olabilir. Biz SEO'lar olarak bizim görevimiz de bu hataları elimine etmek. Öyleyse farklı çözümler bulmamız gerekiyor. Önerilen temel değişikliklerden birisi, "Gelin bu sistemi biz responsive yapalım."
Yani üçlü yapıdan çıkarıp ikili yapıya çevirelim. Bu bence çok noob, çok basit ve olmaması gereken bir öneri. Çünkü zaten bu sistemin kullanmamızın sebebi burada görülen avantajlar. Standart responsive bir sitede arada bir app share olmadığı için aslında bu performans değerini kaybediyorum. Dolayısıyla burada responsive'e geçelim, bence bir çözüm değil. Öte yandan Google'ın yeni, işte ortaya koyduğu progressive web apps gibi çözümler, teorik olarak client-side framework sayılsa da, Google tarafından desteklenen ve bizim için avantajlı olabilecek seçenekler olabilir. Bu da güzel bir sistem aslında. Kullanmak adına birçok artı avantajı da var ama bunun da geliştirme maliyeti çok yüksek ve biz şu an bir sistemi değiştirerek bu işin dışına çıkmak istemiyoruz. Mevcut sistemi SEO uyumlu hale getirmek istiyoruz.
Okey, o zaman burada üçüncü ve asıl bugün anlatmak istediğim çözüme odaklanmamız gerekiyor ki bu da isomorphic apps. Yani kullanıcıların kendi bilgisayarlarında, kendi tarayıcılarında bu app'ten gelen veriyi her seferinde almaları yerine, ufak bir trick'le bu durumu birazcık daha değiştirme durumundan bahsediyorum aslında. Detaylarına gireceğim. Bu durum server-side rendering olarak da biliniyor. Bu şekilde araştırabilirsiniz. Şimdi şu aşağıda gördüğünüz framework'lerin tamamı, React'ler, Backbone'lar, Angular'lar, Ember'lar, hepsi bu yapıyla çalışıyorlar temelde, mantıken ve bu app üzerinden bana bilgileri veriyorlar. Ama en temel dezavantaj neydi? İlk yüklenme hızı. Çünkü burada görülen bu app'i yüklememiz ciddi manada 2-3 saniyelik bir zaman alabiliyor iyi hızlı bir internette. Ve bu birçok kullanıcı için yüksek bir rakam. Ben bunu beklemek istemiyor olabilirim ve bu ilk yüklenme hızının yavaş olması beni rahatsız ediyor olabilir.
İşte burada aslında progressive enhancement adı verilen bu yaklaşım bize şunu söylüyor. Diyor ki: "Yiğit, madem app'in bu kadar büyük, sen önce kullanıcının ana ekranında göreceği alanı bir yükle." Yani bu mobil telefonumun ekranı olabilir, bilgisayarımsa bilgisayarımın ilk açıldığı ekrandaki görüntüsü olabilir. "Sen," diyor, "bunu kullanıcıya gönder. Sen bunu gönderdikten sonra kullanıcı burayı anlamaya çalışıyorken zaten diğer kalan app'i yükleyebilirsin. Bu senin için bir avantaj. Sen adamı orada bütün app'i yükletene kadar bekletme. İlk görmesi gereken veriyi göster, ilk yüklemede, initial load'da. Daha sonra o aşağıya doğru inerken sen zaten app'in kalanını yüklersin." İşte buna isomorphic apps deniyor. Airbnb biliyorsunuz, işte ev kiralama konusunda dünya lideri. Bu konuda çok ciddi emekleri var. Harika da bir yazıları var. Zaten araştırdığınızda mutlaka göreceksiniz.
Ve yaklaşım olarak diyor ki: "Google JavaScript'i indeksliyor ya da indekslemiyor. Biz isomorphic apps denilen sistemle kullanıcının ilk göreceği şeyi, standart ikili sistemdeki gibi, sunucu browser'daki gibi kullanıcıya verelim. Kullanıcı sayfayı geziyorken biz arkada app'i yükleriz ve app kullanıma hazır olduğu zaman sağdaki bütün avantajları bana sağlar." Böylece ne oldu? Ben bu sistemi kullanarak ilk yüklenme hızını arttırdım mı? Arttırdım. Standart ikili yapıdaki gibi bir sayfa açtığım için Google için bir problem var mı? Artık yok. Hayır, SEO implementasyonum da iyi durumda. Evet, JavaScript hâlâ zorunlu ama neredeyse artık crawler'lar dışında bütün tarayıcılar JavaScript destekliyor.
Evet, API ihtiyacım hâlâ var mı? Var. Modern ihtiyaçlardan birisi. Geri butonu problemini çözüyor muyum? Zaten bunu uygulayan bir yazılımcı muhtemelen push state'i de uyguluyor ve çözüyor. Tek sıkıntım geliştirme maliyeti olmuş oluyor. Dolayısıyla bu isomorphic apps yapısını işin içerisine entegre ettikten sonra hem buradaki avantajların tamamını kullanabiliyorum hem dezavantajlardan kaçınabiliyorum hem de harika bir SEO performansı sağlayabiliyorum. Biz SEO'cular her ne kadar bugüne değin JavaScript sistemlerinden kaçınmış olsak da, web'in geleceği, kullanıcının ihtiyaçları, ona hızlı tepki verebilmek, hızlı cevap verebilmek gibi nedenlerden ötürü kendimizi artık pivot etmek ve birazcık da olsun JavaScript öğrenerek front-end developer'ların yanına oturduğumuzda onlara derdimizi anlatıyor olabilmemiz gerek.
Şimdilik bu konuyla ilgili anlatmak istediklerim bunlar. Bu konuyla ilgili isomorphic apps yazarsanız, Medium'da harika yazılar var, Airbnb'de mükemmel yazılar var. Bunların hepsini inceleyerek projenize ya da müşterinize destek verirken çok daha manalı yaklaşımlar getirebilirsiniz. Şimdilik anlatmak istediklerim bu kadar. Bir sonraki videoda görüşmek üzere. Kolay gelsin.
Hey everyone, Zeo followers. Today's topic is more for developers and project managers. We're going a bit more technical today. The terms above — "single page apps" and "client-side framework" — might sound foreign. Especially if you're not in the dev world. We'll walk you through all of it, slowly. We'll start with the basics. These two concepts you see here are pretty close to each other. New-generation developers built them for one reason. They wanted to give you a smoother web experience. Let's start at the foundation to see how this system works. Normally, you open a page on the web. You type "zeo.org" and hit enter in your browser. Your browser goes to a DNS server. It says: "Give me the IP address for zeo.org."
Basically, tell me where it lives. The DNS comes back with a four-part line. It says: "It's at this IP. Go ask over there." So my browser goes and fires off a request. It asks: "Can you give me zeo.org's data? They said it's here." And it gets an answer back. So there's a server on one side. There's a browser on the other. The two talk to each other. They finish the data transfer and build the web page you see. It's a solid setup. It's the technology that got the web this far. Over 90% of sites on the web still use it.
But these days, users want smoother page transitions. Well, developers do. So they add another layer here. They say: "There's a server here, a browser here. Let me build an app in between." But don't think of this app like a mobile app. It's more like an app living inside your browser. And whatever changes on the page, I load into that app. The user gets it from there. Basically it tells me up front: "Yiğit, I'm sending you an app. It's 550 kilobytes. Take it. Then I'll tell you every change. You apply it to the app." That's what it's saying.
So I'm not reloading every page. And I get a really smooth experience. That's why they're called "single page apps". Because there's just one page. I loaded it once. The only thing that changes is what comes back from the system. Based on what I do on the page. Based on where I click. There's an API system here too. It's a language apps use to talk to each other. Could be JSON. Could be XML. In that format, the server only sends the part of the page that changed. So what happens? Every page transition moves almost 20-25 times less data. And the experience is incredibly smooth.
If we talk about the advantages, mobile wins the most. Obviously, because the size drops. Why is that? Our phones are really just old computers. Slow computers. And they're not always somewhere with great internet speed. Because their positions keep changing. So on mobile, these "single page apps" give us a huge advantage. First and foremost. What kind of apps are these? Where can I find them? How do I test them? We sprinkled some in below for you. There's React. There's Backbone. There's Vue.js, you've probably heard of it. There's Angular.js, Ember, Meteor, Knockout. Lots of different options.
We even found a gap and wrote our own Yiğit JS. A new client-side framework enters our lives every day. And there's no standardization around it yet. That's honestly where the problem starts. On the advantages, we said mobile experience first. If you remember the setup here, I loaded the app into my browser once. It's not something you notice loading. But I loaded the core of that site. And all the changing data came to me through a system we call the API. Yes, so what does that mean? I get a faster page transition experience. Every transition between pages feels smooth. And what happens then? People stay on the site longer. Or a user browses more pages per session.
Because when they click a page, the content loads in half a second. That's incredible page speed. So it's user-friendly, very smooth, and maintenance costs are relatively cheaper. Once you've built it. Because all the data gets served through APIs. And you can manage that really easily. Now let's talk about the downsides. When we get to the drawbacks, the biggest one is initial load speed. What did we say? The server sends me an app first. It says: "Yiğit, talk to this app. I'll send it data through the API."
Okay, but how big is this app? These apps are genuinely huge in size. So the initial load times get really slow. That's not what we want at all. Unfortunately, that's a drawback. Then there's SEO implementation. We said Google Bot lands on a page during the SEO process. It clicks around the pages. Then it saves that info to its own database. And here's where SEO takes a hit. Because the standard take is: "Google Bot can't run pages with JavaScript." So it's a web technology. And on pages using that web technology, it says it can't run it.
So what happens then? It basically can't run my app. Because Google Browser Server got used to the old-school setup. It couldn't index this back in the day. Because JavaScript is required. That's another drawback. The two are related, after all. Now Google has solved this. How did it solve it? What action should I take? We'll cover that more comfortably in the next steps. On the other hand, these systems are usually single page. So hitting the back button can step you back out of the whole app.
We have different solutions for this, like push state. But in simple implementations, this is still a negative. On the other hand, there's development cost. The amazing developers who write all the technologies listed below are expensive. And they're a dying breed. Because there are so few of them. We're working hard to grow that pool. But their scarcity drives development costs up. Now, with all these great advantages on the table. I don't think we as SEO consultants have the freedom to say. "Don't use single page apps. Don't use a client-side framework."
Because at its core, SEO is about improving the user experience. We want to move people to a better place, a better experience. There are great advantages here. Yes, there can be downsides too. So how do I eliminate those downsides? I want using these advantages to stay profitable and sensible for me. This is exactly where we come in with different solution proposals. The first one is a system called Ajax Scrolling. Google basically says: "Okay, the web is changing. I know that. And in response to that change, I need to index this JavaScript."
But we can't claim Google lacks the capability to run JavaScript. We're talking about the biggest technology company in the world. Our basic cell phones can interpret JavaScript. So how could Google not run it? The core problem here actually starts with crawling itself. Google crawls the web broadly. If it ran all that JavaScript, crawling would slow down like crazy. It's incredibly resource-hungry. It takes serious processor power. Google doesn't want to go there. I'm talking about 2014, 2015 here. So Google says: "Okay, maybe I can't crawl JavaScript. So give me HTML output instead. Remember that two-way system, server to browser? Serve me the JavaScript-built page that way."
Think of them like screenshots, basically. Snapshots of the page. In HTML form, of course. Serve it from there. And Google says: "Push it to me with a parameter called escape fragment." Google pushed this solution hard. People used it for years. That way Google never had to index JavaScript. Users rendered pages with their own JavaScript. Then they handed those pages to Google. But it has plenty of downsides too. It's a technical topic. I won't go too deep. But every time the page changes, I have to update the cache I keep here. Otherwise Google can't see it. Tons of problems like that. It's not a system Google would pick long term. So Ajax Scrolling still gets recommended a lot by SEO folks. But honestly, it's not a great system.
Why? Because it leaves everything up to the user. You have to do a ton of implementation work. There's a technical side to it too. Not everyone can pull that off. So Google needed an alternative. At the end of 2015, they said: "No, I'm deprecating this. I'm shutting it down." "I'll pull it completely soon." But if you're still using it. You don't need to change anything. If you have to do it, go ahead. But I can already index your JavaScript, they said. So client-side frameworks and everything ending in JS down there. If Google can index them, there's no problem.
So Google should have solved the whole thing, right? That's what we'd expect. But no. That's not the reality. Google still can't always index these JavaScript frameworks well. Because it does this at world scale. It does it at massive volume. Certain errors can happen. As SEOs, our job is to eliminate those errors. So we need to find different solutions. One suggested change: "Let's make this system responsive." Let's go from a three-part setup to a two-part one. Honestly, that's a noob suggestion. Too simple. It shouldn't even be on the table. We use this system for the advantages you see here. On a standard responsive site, there's no app share in between. So I lose that performance benefit.
So switching to responsive here? I don't think that's a solution. On the other hand, there's stuff Google just rolled out, like progressive web apps. Technically they still count as a client-side framework. But they're backed by Google. That could work in our favor. It's actually a nice system. There are plenty of upsides to using it. But the development cost is really high. And right now we don't want to rip out a system to solve this. We want to make the current system SEO-friendly.
Okay. So now we focus on the third option. This is the one I really want to cover today. It's isomorphic apps. Instead of users pulling data from the app every single time. On their own machines, in their own browsers, we use a small trick. That trick shifts the whole picture a bit. I'll get into the details. This is also known as server-side rendering. You can search for it that way. Now, every framework you see down there. React, Backbone, Angular, Ember. They all basically work this way. That's the logic behind them. And they hand me the data through this app.
But what was the core downside? Initial load speed. Loading the app you see here can seriously take 2-3 seconds. And that's on a good, fast connection. For a lot of users, that's way too long. I might not want to wait that long. And that slow first load might really bug me. This is where the approach called progressive enhancement comes in. It tells us this. It says: "Yiğit, your app is huge. So load what the user sees on the main screen first." That could be my phone screen. Or on desktop, whatever shows up when the page first opens.
It says: "Send that to the user first. Once you've sent it, the user starts taking it in. Meanwhile you can load the rest of the app. That's a win for you. Don't make the guy wait for the whole app to load. Show the data they need to see first, on the initial load." "Then as they scroll down. You load the rest of the app." This is what we call isomorphic apps. You know Airbnb, the world leader in home rentals. They've put serious work into this. They also have a great write-up on it. You'll definitely run into it if you look around.
Their approach says this: "Google either indexes JavaScript or it doesn't. With this isomorphic apps system, let's hand the user the first thing they see. Just like the standard two-part setup, server to browser. While the user browses the page, we load the app in the background. And once the app is ready, it gives me every advantage on the right." So what happened here? Did this system speed up my initial load? It did. I'm serving a page like the standard two-part setup. So is there still a problem for Google? Not anymore. No, my SEO implementation is in good shape too. Yes, JavaScript is still required. But almost every browser except crawlers supports JavaScript now.
Yes, do I still need an API? I do. It's one of the modern requirements. Am I solving the back button problem? A developer building this probably implements push state too. So it's solved. My only downside is development cost. Once I integrate this isomorphic apps structure, I get all the advantages. I avoid the disadvantages. And I get great SEO performance. We SEO folks have avoided JavaScript systems until now. But look at the future of the web. Look at user needs. Look at responding fast to them. We have to pivot. We need to learn a little JavaScript. Then we can sit down with front-end developers. And actually explain what we need.
That's what I wanted to cover for now. Search for isomorphic apps on this topic. There are great articles on Medium. Airbnb has excellent ones too. Read through them all. You'll bring much smarter approaches to your project or your client. That's all for now. See you in the next video. Take care.
This transcript was generated using AI speech recognition and verified against subtitle style rules.
