Web geli\u015ftirme d\u00fcnyas\u0131nda Chrome DevTools, \u015f\u00fcphesiz en g\u00fc\u00e7l\u00fc ve vazge\u00e7ilmez ara\u00e7lardan biridir. Taray\u0131c\u0131n\u0131n derinliklerine inmemizi, performans\u0131 analiz etmemizi, a\u011f isteklerini izlememizi ve CSS\/HTML \u00fczerinde anl\u0131k de\u011fi\u015fiklikler yapmam\u0131z\u0131 sa\u011flar. Ancak, her ne kadar kapsaml\u0131 olsa da, bazen belirli i\u015f ak\u0131\u015flar\u0131 veya \u00f6zel ihtiya\u00e7lar i\u00e7in yetersiz kald\u0131\u011f\u0131 anlar olabiliyor. \u0130\u015fte tam da bu noktada, kendi \u00f6zel ara\u00e7lar\u0131m\u0131 geli\u015ftirme fikri do\u011fdu ve bu makale, bu ser\u00fcvenimi ve DevTools’a ekledi\u011fim \u00f6zellikleri anlat\u0131yor.<\/p>\n
Web aray\u00fczleri g\u00fcn ge\u00e7tik\u00e7e daha karma\u015f\u0131k hale geliyor. CSS, \u00f6zellikle modern d\u00fczen teknikleriyle birlikte, bazen y\u00f6netilmesi zor bir hal alabiliyor. DevTools, stil d\u00fczenlemeleri i\u00e7in harika bir ba\u015flang\u0131\u00e7 noktas\u0131 sunsa da, baz\u0131 senaryolarda daha fazlas\u0131na ihtiya\u00e7 duyulabiliyor.<\/p>\n
DevTools’ta yapt\u0131\u011f\u0131n\u0131z CSS de\u011fi\u015fiklikleri taray\u0131c\u0131 yenilendi\u011finde kaybolur. Bu durum, \u00f6zellikle karma\u015f\u0131k denemeler yaparken veya birden fazla stil kural\u0131n\u0131 test ederken can s\u0131k\u0131c\u0131 olabilir. Bu sorunu a\u015fmak i\u00e7in, taray\u0131c\u0131da yap\u0131lan t\u00fcm CSS de\u011fi\u015fikliklerini otomatik olarak kaydeden ve ge\u00e7mi\u015fini tutan bir ara\u00e7 geli\u015ftirdim. Bu ara\u00e7, sadece de\u011fi\u015fiklikleri kaydetmekle kalm\u0131yor, ayn\u0131 zamanda herhangi bir ad\u0131ma geri d\u00f6nme veya belirli bir de\u011fi\u015fikli\u011fi kal\u0131c\u0131 olarak uygulamak i\u00e7in CSS kodunu d\u0131\u015fa aktarma imkan\u0131 da sunuyor. B\u00f6ylece, deneme yan\u0131lma s\u00fcreci \u00e7ok daha verimli hale geliyor.<\/p>\n
CSS Grid ve Flexbox, modern d\u00fczenler i\u00e7in harika ara\u00e7lard\u0131r ancak karma\u015f\u0131k i\u00e7 i\u00e7e yap\u0131larla \u00e7al\u0131\u015f\u0131rken g\u00f6rselle\u015ftirmeleri zor olabilir. DevTools’un kendi g\u00f6rselle\u015ftiricileri olsa da, bazen daha detayl\u0131 veya \u00f6zelle\u015ftirilebilir bir g\u00f6r\u00fcn\u00fcme ihtiya\u00e7 duyulur. Geli\u015ftirdi\u011fim \u00f6zel g\u00f6rselle\u015ftirici, sadece sat\u0131r ve s\u00fctunlar\u0131 g\u00f6stermekle kalm\u0131yor, ayn\u0131 zamanda \u00f6\u011felerin kaplad\u0131\u011f\u0131 alanlar\u0131, bo\u015fluklar\u0131 ve hizalamalar\u0131 renk kodlar\u0131yla daha belirgin hale getiriyor. Ayr\u0131ca, belirli bir \u00f6\u011fenin neden beklenen yerde olmad\u0131\u011f\u0131n\u0131 anlamak i\u00e7in interaktif olarak \u00f6l\u00e7\u00fcmleri ve hizalama \u00f6zelliklerini de\u011fi\u015ftirmeye olanak tan\u0131yor.<\/p>\n
Bir \u00f6\u011fenin Web sitelerinin h\u0131z\u0131, kullan\u0131c\u0131 deneyimi ve SEO i\u00e7in kritik \u00f6neme sahiptir. DevTools’un Performance paneli olduk\u00e7a g\u00fc\u00e7l\u00fcd\u00fcr ancak bazen belirli performans darbo\u011fazlar\u0131n\u0131 tespit etmek i\u00e7in daha ni\u015f ara\u00e7lara ihtiya\u00e7 duyulur.<\/p>\n Performance paneli genellikle belirli bir zaman aral\u0131\u011f\u0131ndaki performans\u0131 analiz eder. Ancak, uygulaman\u0131n uzun s\u00fcreli kullan\u0131m\u0131 s\u0131ras\u0131nda veya belirli bir etkile\u015fimden sonra kaynak kullan\u0131m\u0131n\u0131n (CPU, bellek) nas\u0131l de\u011fi\u015fti\u011fini ger\u00e7ek zamanl\u0131 olarak g\u00f6rmek bazen daha faydal\u0131 olabilir. Geli\u015ftirdi\u011fim ara\u00e7, taray\u0131c\u0131n\u0131n performans API’lar\u0131n\u0131 kullanarak (\u00f6rne\u011fin B\u00fcy\u00fck projelerde yap\u0131lan k\u00fc\u00e7\u00fck CSS veya JavaScript de\u011fi\u015fiklikleri, fark\u0131nda olmadan ba\u015fka bir yerde g\u00f6rsel bozulmalara (regresyonlara) neden olabilir. DevTools’un bu konuda do\u011frudan bir \u00f6zelli\u011fi yoktur. Bu a\u00e7\u0131\u011f\u0131 kapatmak i\u00e7in, belirli sayfa b\u00f6l\u00fcmlerinin veya bile\u015fenlerin ekran g\u00f6r\u00fcnt\u00fclerini alan ve bunlar\u0131 \u00f6nceki referans g\u00f6r\u00fcnt\u00fclerle kar\u015f\u0131la\u015ft\u0131ran bir ara\u00e7 olu\u015fturdum. \u0130ki g\u00f6r\u00fcnt\u00fc aras\u0131ndaki farklar\u0131 vurgulayarak, g\u00f6rsel regresyonlar\u0131 otomatik olarak tespit ediyor ve geli\u015ftiricinin dikkatini \u00e7ekiyor. Bu, \u00f6zellikle s\u00fcrekli entegrasyon (CI) s\u00fcre\u00e7leriyle birle\u015ftirildi\u011finde paha bi\u00e7ilmez bir ara\u00e7 haline geliyor.<\/p>\n Taray\u0131c\u0131n\u0131n ana i\u015f par\u00e7ac\u0131\u011f\u0131 (main thread) \u00fczerinde \u00e7al\u0131\u015fan uzun g\u00f6revler, sayfan\u0131n donmas\u0131na veya yava\u015f tepki vermesine neden olabilir. DevTools’un Performance paneli bu g\u00f6revleri g\u00f6sterse de, bazen belirli bir e\u015fi\u011fin \u00fczerindeki t\u00fcm uzun g\u00f6revleri otomatik olarak filtreleyip \u00f6zetlemek ve bunlar\u0131n kaynak kodundaki yerlerini h\u0131zl\u0131ca bulmak istenir. Kendi arac\u0131m, Tek sayfa uygulamalar\u0131 (SPA) ve API tabanl\u0131 sistemler g\u00fcn\u00fcm\u00fczde standart haline geldi. DevTools’un Network paneli a\u011f isteklerini izlemek i\u00e7in harika olsa da, belirli senaryolarda daha fazla kontrol ve esneklik gerekebilir.<\/p>\n Network panelindeki filtreleme se\u00e7enekleri genellikle URL, t\u00fcr veya durum kodlar\u0131 ile s\u0131n\u0131rl\u0131d\u0131r. Ancak, bazen bir iste\u011fin ba\u015fl\u0131klar\u0131nda veya yan\u0131t g\u00f6vdesinde belirli bir anahtar kelimeyi aramak gerekebilir. Kendi arac\u0131m, RegEx destekli derinlemesine bir arama ve filtreleme mekanizmas\u0131 sunuyor. Bu sayede, binlerce a\u011f iste\u011fi aras\u0131ndan belirli bir veri par\u00e7as\u0131n\u0131 i\u00e7eren istekleri veya belirli bir ba\u015fl\u0131\u011fa sahip olanlar\u0131 h\u0131zla bulmak m\u00fcmk\u00fcn oluyor. Ayr\u0131ca, belirli istekleri favorilere ekleyip daha sonra kolayca eri\u015fme \u00f6zelli\u011fi de bulunuyor.<\/p>\n Geli\u015ftirme s\u0131ras\u0131nda backend API’lerinin hen\u00fcz haz\u0131r olmamas\u0131 veya belirli hata senaryolar\u0131n\u0131 test etmek istemeniz durumunda, API yan\u0131tlar\u0131n\u0131 taklit etmek (mocking) \u00e7ok i\u015fe yarar. DevTools’un bu konuda do\u011frudan bir \u00f6zelli\u011fi yoktur. Geli\u015ftirdi\u011fim ara\u00e7, belirli bir URL’ye yap\u0131lan isteklere \u00f6zel yan\u0131tlar d\u00f6nd\u00fcrmek i\u00e7in bir servis \u00e7al\u0131\u015fan\u0131 (Service Worker) kullan\u0131r. Geli\u015ftirici, bir JSON dosyas\u0131 y\u00fckleyerek veya do\u011frudan aray\u00fcz \u00fczerinden bir yan\u0131t g\u00f6vdesi tan\u0131mlayarak, uygulaman\u0131n farkl\u0131 API senaryolar\u0131na nas\u0131l tepki verdi\u011fini test edebilir. Bu, \u00f6zellikle offline modlar\u0131 veya hata durumlar\u0131n\u0131 test ederken b\u00fcy\u00fck kolayl\u0131k sa\u011flar.<\/p>\n Karma\u015f\u0131k uygulamalarda, bir API iste\u011finin ba\u015fka bir iste\u011fi tetiklemesi veya belirli bir dizi iste\u011fin belirli bir s\u0131rayla ger\u00e7ekle\u015fmesi gerekebilir. Network paneli bu s\u0131ralamay\u0131 g\u00f6sterse de, ba\u011f\u0131ml\u0131l\u0131klar\u0131 g\u00f6rsel olarak anlamak bazen zordur. Kendi arac\u0131m, a\u011f istekleri aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131klar\u0131 bir grafik veya ak\u0131\u015f \u015femas\u0131 \u015feklinde g\u00f6rselle\u015ftirir. Hangi iste\u011fin hangi iste\u011fi tetikledi\u011fini, kritik yolun neresi oldu\u011funu ve olas\u0131 darbo\u011fazlar\u0131 daha net bir \u015fekilde g\u00f6rmeyi sa\u011flar. Bu, \u00f6zellikle performans optimizasyonu ve hata ay\u0131klama s\u00fcre\u00e7lerinde faydal\u0131d\u0131r.<\/p>\n Hata ay\u0131klama, geli\u015ftirme s\u00fcrecinin ayr\u0131lmaz bir par\u00e7as\u0131d\u0131r. DevTools’un Sources paneli ve Console’u bu konuda \u00e7ok g\u00fc\u00e7l\u00fcd\u00fcr ancak bazen uygulaman\u0131n i\u00e7 durumunu daha derinlemesine anlamak i\u00e7in ek izleme ve hata ay\u0131klama yetenekleri gerekebilir.<\/p>\n Modern JavaScript \u00e7er\u00e7eveleri (React, Vue, Angular) genellikle bile\u015fen tabanl\u0131 ve durum y\u00f6netimi odakl\u0131d\u0131r. Bir uygulaman\u0131n durumunun zaman i\u00e7inde nas\u0131l de\u011fi\u015fti\u011fini takip etmek, karma\u015f\u0131k hatalar\u0131 ay\u0131klamak i\u00e7in kritik \u00f6neme sahiptir. Redux DevTools gibi \u00f6zel ara\u00e7lar olsa da, genel bir \u00e7er\u00e7eveden ba\u011f\u0131ms\u0131z olarak \u00e7al\u0131\u015fan bir ara\u00e7 geli\u015ftirdim. Bu ara\u00e7, uygulaman\u0131n belirli global de\u011fi\u015fkenlerini veya bile\u015fen durumlar\u0131n\u0131 d\u00fczenli aral\u0131klarla “snapshot” olarak kaydeder. Geli\u015ftirici, zaman \u00e7izelgesinde geri ve ileri giderek uygulaman\u0131n ge\u00e7mi\u015f durumlar\u0131n\u0131 inceleyebilir ve bir hatan\u0131n tam olarak ne zaman ve hangi durum de\u011fi\u015fikli\u011fiyle tetiklendi\u011fini anlayabilir.<\/p>\n JavaScript hatalar\u0131 genellikle konsolda g\u00f6r\u00fcnse de, bazen hatan\u0131n tam olarak nerede ba\u015flad\u0131\u011f\u0131n\u0131 veya hangi kullan\u0131c\u0131 etkile\u015fiminin tetikledi\u011fini bulmak zordur. Geli\u015ftirdi\u011fim ara\u00e7, taray\u0131c\u0131n\u0131n Web geli\u015ftirme s\u00fcrecinde bir\u00e7ok tekrarlayan g\u00f6rev bulunur: form doldurma, belirli bir navigasyon yolunu izleme, test senaryolar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rma vb. DevTools’un bu g\u00f6revler i\u00e7in do\u011frudan bir otomasyon arac\u0131 yoktur.<\/p>\n Bir kullan\u0131c\u0131n\u0131n bir web sitesinde yapt\u0131\u011f\u0131 eylemleri (t\u0131klamalar, form giri\u015fleri, sayfa gezintileri) kaydeden ve daha sonra bu eylemleri otomatik olarak tekrar oynatan bir ara\u00e7 geli\u015ftirdim. Bu, \u00f6zellikle manuel test s\u00fcre\u00e7lerini otomatikle\u015ftirmek veya belirli bir senaryoyu tekrar tekrar test etmek i\u00e7in \u00e7ok faydal\u0131d\u0131r. Kaydedilen eylemler bir JSON dosyas\u0131 olarak d\u0131\u015fa aktar\u0131labilir ve daha sonra farkl\u0131 taray\u0131c\u0131larda veya test ortamlar\u0131nda kullan\u0131labilir. Bu, “robotik s\u00fcre\u00e7 otomasyonu”nun (RPA) basit bir taray\u0131c\u0131 i\u00e7i versiyonu gibidir.<\/p>\n Geli\u015ftiricilerin s\u0131k\u00e7a kulland\u0131\u011f\u0131 JavaScript kod par\u00e7ac\u0131klar\u0131n\u0131 veya bir dizi DevTools komutunu tek bir t\u0131klamayla \u00e7al\u0131\u015ft\u0131ran \u00f6zel komut dosyalar\u0131 ve makrolar paneli olu\u015fturdum. \u00d6rne\u011fin, bir sayfadaki t\u00fcm resimlerin boyutunu de\u011fi\u015ftiren, belirli bir \u00f6\u011feyi gizleyen veya bir formdaki t\u00fcm alanlar\u0131 varsay\u0131lan de\u011ferlerle dolduran makrolar tan\u0131mlanabilir. Bu makrolar, geli\u015ftiricinin i\u015f ak\u0131\u015f\u0131na \u00f6zel olarak uyarlanabilir ve g\u00fcnl\u00fck g\u00f6revlerde b\u00fcy\u00fck zaman tasarrufu sa\u011flar. DevTools’un Snippets \u00f6zelli\u011fi benzer olsa da, bu ara\u00e7 daha kapsaml\u0131 bir aray\u00fcze ve daha fazla otomasyon yetene\u011fine sahiptir.<\/p>\n Web uygulamalar\u0131 i\u00e7in test senaryolar\u0131 yazmak ve bunlar\u0131 manuel olarak \u00e7al\u0131\u015ft\u0131rmak zaman al\u0131c\u0131d\u0131r. Geli\u015ftirdi\u011fim ara\u00e7, \u00f6nceden tan\u0131mlanm\u0131\u015f test senaryolar\u0131n\u0131 (\u00f6rne\u011fin, bir kullan\u0131c\u0131 kayd\u0131 ak\u0131\u015f\u0131, bir \u00fcr\u00fcn sepete ekleme s\u00fcreci) otomatik olarak \u00e7al\u0131\u015ft\u0131r\u0131r ve her ad\u0131m\u0131n ba\u015far\u0131l\u0131 olup olmad\u0131\u011f\u0131n\u0131 kontrol eder. Bu senaryolar, belirli DOM \u00f6\u011felerinin varl\u0131\u011f\u0131n\u0131 kontrol etme, belirli bir metnin g\u00f6r\u00fcn\u00fcrl\u00fc\u011f\u00fcn\u00fc do\u011frulama veya API yan\u0131tlar\u0131n\u0131 kontrol etme gibi ad\u0131mlar\u0131 i\u00e7erebilir. Her senaryonun sonunda, bir rapor olu\u015fturulur ve ba\u015far\u0131s\u0131z olan ad\u0131mlar vurgulan\u0131r. Bu, s\u00fcrekli entegrasyon ortamlar\u0131nda veya geli\u015ftirme s\u0131ras\u0131nda h\u0131zl\u0131 geri bildirim almak i\u00e7in idealdir.<\/p>\n Chrome DevTools, web geli\u015ftirme i\u00e7in inan\u0131lmaz derecede g\u00fc\u00e7l\u00fc bir temel sunuyor. Ancak, her geli\u015ftiricinin kendine \u00f6zg\u00fc i\u015f ak\u0131\u015flar\u0131 ve \u00f6zel ihtiya\u00e7lar\u0131 vard\u0131r. Bu makalede bahsetti\u011fim gibi, DevTools’un sundu\u011fu API’lar ve taray\u0131c\u0131 teknolojileri (Service Workers, Performance API’lar\u0131 vb.) sayesinde, bu bo\u015fluklar\u0131 kapatmak ve kendi \u00f6zel ara\u00e7lar\u0131m\u0131z\u0131 geli\u015ftirmek m\u00fcmk\u00fcn. Bu ser\u00fcven, sadece geli\u015ftirme s\u00fcrecimi daha verimli hale getirmekle kalmad\u0131, ayn\u0131 zamanda taray\u0131c\u0131 teknolojileri hakk\u0131nda derinlemesine bilgi edinmemi de sa\u011flad\u0131. Kendi ara\u00e7lar\u0131n\u0131z\u0131 geli\u015ftirmek, hem sorun \u00e7\u00f6zme becerilerinizi geli\u015ftirir hem de geli\u015ftirme deneyiminizi ki\u015fiselle\u015ftirerek size b\u00fcy\u00fck avantajlar sa\u011flar. Unutmay\u0131n, en iyi ara\u00e7lar genellikle ihtiya\u00e7lardan do\u011far ve bazen bu ara\u00e7lar\u0131 kendimiz in\u015fa etmek en iyi \u00e7\u00f6z\u00fcmd\u00fcr.<\/p>\n:hover<\/code>, :focus<\/code>, :active<\/code> veya farkl\u0131 veri durumlar\u0131na g\u00f6re nas\u0131l g\u00f6r\u00fcnd\u00fc\u011f\u00fcn\u00fc test etmek, DevTools’un “Force state” \u00f6zelli\u011fi ile m\u00fcmk\u00fcnd\u00fcr. Ancak, bu \u00f6zellik bazen yeterli olmayabilir, \u00f6zellikle de bir \u00f6\u011fenin birden fazla ko\u015fula (\u00f6rne\u011fin, hem :hover<\/code> hem de [data-state=\"error\"]<\/code>) ayn\u0131 anda tepki vermesi gereken durumlarda. Kendi arac\u0131m, bu durumlar\u0131 daha esnek bir \u015fekilde sim\u00fcle etmeye olanak tan\u0131yor. Bir panel \u00fczerinden belirli bir \u00f6\u011feye birden fazla sahte s\u0131n\u0131f veya veri \u00f6zniteli\u011fi ekleyerek, farkl\u0131 kombinasyonlardaki g\u00f6rsel tepkileri h\u0131zl\u0131ca test etmeyi sa\u011fl\u0131yor.<\/p>\nPerformans Optimizasyonunda \u0130htiya\u00e7 Duyulan Ek Ara\u00e7lar<\/h3>\n
Ger\u00e7ek Zamanl\u0131 Kaynak Kullan\u0131m \u0130zleme<\/h4>\n
performance.memory<\/code> veya performance.measure<\/code>), belirli metrikleri s\u00fcrekli olarak toplar ve basit bir grafik \u00fczerinde g\u00f6rselle\u015ftirir. Bu sayede, bellek s\u0131z\u0131nt\u0131lar\u0131 veya a\u015f\u0131r\u0131 CPU kullan\u0131m\u0131 gibi sorunlar an\u0131nda fark edilebilir.<\/p>\nG\u00f6rsel Regresyon Tespiti ve Kar\u015f\u0131la\u015ft\u0131rma<\/h4>\n
Uzun G\u00f6revlerin ve Main Thread Engellemelerinin Tespiti<\/h4>\n
PerformanceObserver<\/code> API’sini kullanarak 50ms’den uzun s\u00fcren t\u00fcm g\u00f6revleri dinler, bunlar\u0131 bir liste halinde sunar ve ilgili g\u00f6revin \u00e7a\u011fr\u0131 y\u0131\u011f\u0131n\u0131n\u0131 (call stack) g\u00f6stererek geli\u015ftiricinin sorunun k\u00f6kenine inmesini kolayla\u015ft\u0131r\u0131r.<\/p>\nA\u011f \u0130stekleri ve API Y\u00f6netiminde Geli\u015ftirmeler<\/h3>\n
Geli\u015fmi\u015f \u0130stek\/Yan\u0131t Filtreleme ve Arama<\/h4>\n
API Yan\u0131tlar\u0131n\u0131 Mocklama ve Sim\u00fcle Etme<\/h4>\n
\u0130stek Ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 G\u00f6rselle\u015ftirme<\/h4>\n
Geli\u015fmi\u015f Hata Ay\u0131klama ve \u0130zleme Mekanizmalar\u0131<\/h3>\n
\u00d6zel Loglama ve \u0130zleme Panelleri<\/h4>\n
console.log()<\/code> her ne kadar temel bir ara\u00e7 olsa da, b\u00fcy\u00fck uygulamalarda konsol \u00e7\u0131kt\u0131s\u0131 h\u0131zla karma\u015f\u0131k hale gelebilir. Geli\u015ftirdi\u011fim \u00f6zel bir loglama arac\u0131, farkl\u0131 kategorilerdeki (\u00f6rne\u011fin, UI olaylar\u0131, API \u00e7a\u011fr\u0131lar\u0131, durum de\u011fi\u015fiklikleri) loglar\u0131 ayr\u0131 panellerde veya sekmelerde g\u00f6sterir. Her kategori i\u00e7in farkl\u0131 renk kodlamalar\u0131 ve filtreleme se\u00e7enekleri sunar. Bu sayede, sadece ilgilendi\u011finiz loglar\u0131 g\u00f6rerek konsol karma\u015fas\u0131ndan kurtulabilir ve hata ay\u0131klama s\u00fcrecini h\u0131zland\u0131rabilirsiniz. Ayr\u0131ca, belirli log mesajlar\u0131n\u0131 otomatik olarak uyar\u0131 veya hata olarak i\u015faretleme yetene\u011fi de mevcuttur.<\/p>\nUygulama Durumunu Zaman \u0130\u00e7inde Takip Etme<\/h4>\n
Hata Kaynaklar\u0131n\u0131 Otomatik Olarak Tespit Etme<\/h4>\n
window.onerror<\/code> ve unhandledrejection<\/code> olaylar\u0131n\u0131 dinleyerek t\u00fcm hatalar\u0131 yakalar. Yakalanan her hata i\u00e7in, hatan\u0131n olu\u015ftu\u011fu anki DOM durumunu, kullan\u0131c\u0131 etkile\u015fim ge\u00e7mi\u015fini ve ilgili a\u011f isteklerini kaydeder. Bu sayede, bir hata raporland\u0131\u011f\u0131nda, geli\u015ftirici hatan\u0131n sadece kodunu de\u011fil, ayn\u0131 zamanda olu\u015ftu\u011fu ba\u011flam\u0131 da detayl\u0131 bir \u015fekilde inceleyebilir.<\/p>\nOtomasyon ve Tekrarlayan G\u00f6revlerin Kolayla\u015ft\u0131r\u0131lmas\u0131<\/h3>\n
Taray\u0131c\u0131 Eylemlerini Kaydetme ve Tekrar Oynatma<\/h4>\n
\u00d6zel Komut Dosyalar\u0131 ve Makrolar<\/h4>\n
Test Senaryolar\u0131n\u0131n Otomatik \u00c7al\u0131\u015ft\u0131r\u0131lmas\u0131<\/h4>\n
Sonu\u00e7<\/h3>\n
SSS (S\u0131k Sorulan Sorular)<\/h3>\n
\n
chrome.devtools.*<\/code>) kullanarak DevTools panelleri, sekmeleri veya kenar \u00e7ubuklar\u0131 ekleyebilirsiniz. Google’\u0131n resmi belgeleri bu konuda harika bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r.<\/dd>\nService Worker<\/code> (a\u011f isteklerini yakalamak ve mocklamak i\u00e7in), PerformanceObserver<\/code> (uzun g\u00f6revleri izlemek i\u00e7in), MutationObserver<\/code> (DOM de\u011fi\u015fikliklerini takip etmek i\u00e7in) ve IntersectionObserver<\/code> (g\u00f6rsel regresyon i\u00e7in) gibi teknolojilerden faydaland\u0131m. Baz\u0131 durumlarda basit bir UI k\u00fct\u00fcphanesi (\u00f6rne\u011fin Preact veya Vue) de kulland\u0131m.<\/dd>\n