Chrome DevTools er en av de største grunnene til at utviklere nekter å berøre andre nettlesere.
Men de fleste av oss bruker bare en håndfull funksjoner, og forblir uvitende om mange flere fantastiske funksjoner som slippes lydløst.
La oss avdekke noen av disse skjulte perlene!
Alle har sitt favorittoperativsystem, maskinvareplattform, enhetstype, enhetsformfaktor osv. Men én ting er felles for alle – de kjører Chrome-nettleseren og bare Chrome-nettleseren! Jeg tror det er trygt å si at nettleserkrigene er over, og Chrome har vunnet overbevisende.
Windows-brukere bruker standardnettleseren bare for å laste ned Chrome og deretter bruke Chrome, og ignorerer alle «anbefalinger» fra Windows. Det samme gjelder Apples enheter (spesielt MacBook-er og enheter med større skjerm), der brukere og utviklere unngår Safari, til tross for Apples mange sterke påstander og konverteringstaktikker.
Og hvis en enhet ikke kjører Chrome, er sjansen stor for at den kjører en Chrome-kompatibel spinoff som f.eks Modig eller Vivaldi. Ja, jeg vet, teknisk sett er disse nettleserne ikke basert på Chrome, men det er en annen diskusjon. Den gjennomsnittlige brukeren kan bruke disse andre nettleserne av ideologiske eller spesielle grunner, men når det kommer til utviklere, er det ingen annen nettleser i sikte bortsett fra Chrome.
Selv det faktum at det er et minnespisende monster blir ignorert. Grunnen er enkel: Chrome Dev Tools.
Bildekilde: Offisielle Chrome DevTools-dokumenter
Nå, hvis du leser denne artikkelen, er det trygt å anta at du enten er en superbruker, en trikser, en nettutvikler eller noe lignende. Som sådan trenger ingen av oss en introduksjon til DevTools, hvordan du åpner det, dets ulike funksjoner, etc.
I stedet, uten å kaste bort tid, la oss dykke rett inn i noen av de mindre kjente, men forbløffende nyttige funksjonene til Chrome DevTools.
Innholdsfortegnelse
Designmodus
En av tingene utviklere rutinemessig gjør er å inspisere et element på siden og deretter endre HTML-koden for å forhåndsvise noe eller teste effekten av en endring.
Å jobbe med HTML direkte i DevTools er imidlertid ikke den jevneste tingen noensinne – å vasse gjennom tag-suppen, anstrenge øynene for å finne den rette åpnings-/lukkebraketten, og håndtere en latterlig mengde mellomrom mens du redigerer tekst (mellomrom som mangler tydelig i dokumentet du ser), er noen av problemene du kan måtte håndtere. Det er enda verre hvis du er designer og ikke vil sile gjennom rotet.
Her er et skjermbilde fra en av sidene på denne nettsiden (tipsbilk.net):
Den dypt nestede HTML-en og mystiske, forvirrende CSS-klassene er typiske for alle ikke-trivielle nettsider i dag, og det er her opplevelsen med DevTools er suboptimal, for å si det mildt. 🤭
Men det er en DevTools-funksjon kalt Design Mode, som kan redusere smerten i mange tilfeller. Ved å bruke designmodusen (det er ikke det offisielle navnet, forresten; det er bare hva folk har kalt det på grunn av hvordan det blir aktivert og hva det gjør – ikke bekymre deg, vi får se veldig snart!), endres til siden kan gjøres visuelt og live, akkurat som å redigere et regneark eller tekstredigering! Den eneste haken er at denne funksjonen ikke er på som standard, og å aktivere den er litt av en hodepine, spesielt for ikke-utviklere.
I alle fall er det ganske enkelt å gjøre det; alt du trenger å gjøre er å følge instruksjonene nedenfor. Avhengig av hvor du sitter på brukersofistikeringskurven, kan dette være latterlig enkelt eller moderat vanskelig. Her er hva du skal gjøre:
- Sørg for at nettsiden du vil redigere er lastet inn, og at du ser på den for øyeblikket (det vil si at den aktuelle fanen er den aktive).
- Åpne DevTools-panelet slik du vanligvis gjør (hurtigtast, museklikk, hva som helst). Jeg liker å bruke hurtigtaster, og på Mac gjør Opt + Cmd + jeg jobben.
- Nå, med DevTools åpne, gå til fanen kalt «Konsoll». Noen av dere himler kanskje med øynene på hvor dumt og åpenbart alt dette virker, men hei, la oss også tenke på de (hundrevis av?) tusenvis av mennesker der ute som sliter mens de jobber med nettleserkonsollen og JavaScript (uansett grunnen). ).
- Klikk på den første linjen ved siden av markøren, som da vil presentere en skrivemelding, og nå kan du skrive JavaScript-kode der (se skjermbildet litt lenger nede).
- Nå må vi skrive litt JavaScript-kode. Ikke bekymre deg, siden det du trenger å skrive/skrive er veldig kort og greit: document.designMode = «på». Du kan også kopiere og lime inn koden fra denne siden (hvis du gjør det, sørg for at formateringen ikke blir kopiert – vi trenger bare ren tekst) eller hvis du føler deg trygg, skriv den ut.
- Trykk Enter/Retur.
«Det er det??!»
Ja, det er alt!
Nå kan du fritt redigere siden som om den var et dokument. Sjekk ut denne eksempelvideoen der jeg liveredigerer Spotify-nettstedet ved hjelp av designmodus:
Design Mode-funksjonen, spennende som den er, er ikke en sølvkule; du kan for eksempel ikke enkelt kopiere og lime inn knapper, endre utseende og så videre. Det faktiske antallet ting den kan gjøre sammenlignet med en drømmewebsideredaktør er veldig lavt; Det løser imidlertid brukstilfeller der innhold må endres visuelt og underveis.
Når det er sagt, er det ikke så langt å påstå at Chrome-folkene tester hvor godt denne funksjonen mottas; hvis den finner godt mottak og et sterkt bruksområde, er det rimelig å forvente at kraftigere redigeringsmuligheter snart vil følge! 🤞🏻🤞🏻
Simulering av nettverksforhold
Nettverk-fanen i Chrome DevTools er kanskje den mest brukte (jeg har selvfølgelig ikke data om den, men som nettutvikler pleier jeg å bruke Konsoll-fanen kanskje 20-30 % av tiden, og Nettverk-fanen resten av tiden). Den gir oss all slags informasjon om forespørslene som sendes fra siden, deres type, metadata/overskrifter, status, nedlastingsfremgang for eiendeler (bilder, stilark osv.), lastetider og så videre. Med en så utrolig anvendelighet er det ikke rart at Network-fanen er den vanligste.
Og likevel er det enkelt å gå glipp av funksjonen vi diskuterer; du har kanskje ikke lagt merke til en harmløs dropdown som sier det åpenbare: Online.
Hvis du klikker på dette, vil du se en rullegardin med ulike alternativer som lar deg strupe nettverkshastigheten: Rask 3G, Sakte 3G, Frakoblet osv. Selv om det kan være ulike brukstilfeller for dette alternativet, er det vanligste å teste nettsiden ytelse på trege nettverk eller webapp-adferd når du er frakoblet (forutsatt at slike funksjoner ble lagt til).
La oss ta dette en tur. Jeg setter nettverket til «Slow 3G» og laster inn den samme siden på nytt fra forrige skjermbilde. Før jeg gjør det, legg merke til i det tidligere skjermbildet hvordan på min nåværende nettverkstilkobling (et 40 Mbps bredbånd), blir de fleste eiendeler lastet ned på under 100 millisekunder.
Og nå er det på tide å se hva treg 3G gjør med det.
For en forskjell!
Legg merke til at lastetiden for eiendeler nå er i området 5–10 sekunder. Dessuten fullførte siden full innlasting på 17,25 sekunder! Ja, jeg vet hva du tenker på, men du må tenke på at på et tregt 3G-nettverk vil ethvert moderne nettsted ta flere sekunder å laste. Om du vil ha rask lasting på trege nettverk er en annen ting, men alt i alt må det være en forretningsavgjørelse der gevinsten rettferdiggjør innsatsen.
Legg merke til advarselsikonet på fanen Nettverk i skjermbildet ovenfor. Det er Chromes måte å minne deg på at du har gjort en ikke-standard, vedvarende endring, og med mindre du vet hva du gjør, bør du kanskje tilbakestille den.
Interaktiv fargevelger
Å inspisere DOM-elementer i DevTools er noe vi alle gjør stort sett hver dag. Vi er også vant til delen med CSS-detaljer som vises ved siden av, og vi vet at vi kan redigere den og se resultatene umiddelbart.
En liten bekvemmelighet gjemt blant alt dette er at hvis du klikker på en CSS-fargeegenskap, vil et kjent fargevelgergrensesnitt dukke opp!
Legg merke til at det ikke er en enkel, grunnleggende fargevelger. Den lar deg kontrollere gjennomsiktighet, endre fargesystemer som brukes, velge en farge direkte fra siden og mye mer.
Så neste gang du eksperimenterer med et nettsteds aksentfarger, for eksempel, trenger du ikke å trene eller gjette på riktig verdi for nyansen du har i tankene! Faktisk er det mange som liker å designe nettsider direkte i nettleseren; for dem er funksjoner som disse en gudegave! 🙂
Overvåking av hendelser på sideelementer
Vi er ofte i en situasjon der vi skulle ønske vi visste hva som foregikk med det ene spesifikke elementet vi er interessert i. Dette gjelder spesielt når du bruker jQuery i en ikke-triviell kodebase – enten din eller andres; hendelsesbehandlere og logikk er spredt over alt, og å spore opp en feil kan være et mareritt.
Heldigvis har Chrome DevTools en kjekk funksjon for nettopp dette. Den vil observere det angitte elementet for deg og logge hendelsene til konsollen. Men det er litt av en skuffelse: denne funksjonen har ikke funksjoner for elementvalg basert på CSS-klassenavn. Så jQuery-metoden $(“#email”) er ikke tilgjengelig. 🙂
Med det sagt, la oss se hvordan du får det til å fungere. Vi begynner med å gjøre et enkelt «inspiser element» ved å bruke DevTools-inspektøren. Ja, det er det samme inspeksjonsverktøyet vi bruker hver dag.
I skjermbildet nedenfor har jeg brukt inspektørverktøyet for å markere tekstinndata. Med «markering» mener jeg ikke at elementet på siden er uthevet (det er det ikke, som du kan se); snarere ble inspektørmarkøren klikket på tekstinndata, og den tilsvarende HTML-koden i DevTools er uthevet.
Å gjøre dette retter seg mot det for øyeblikket inspiserte elementet for hendelsesovervåking, noe som gjør elementet tilgjengelig som en spesiell JavaScript-variabel kalt $0. Deretter passer jeg på at jeg ikke klikker andre steder i nettleservinduet uforsiktig (spesielt HTML-kodedelen), klikker jeg på konsollen og legger ved en hendelseslytter for denne tekstinngangen. Alt jeg trenger for dette er en enkelt linje med kode: monitorEvents($0, «mus»). «Mus»-delen her forteller Chrome at jeg bare er interessert i å se etter musebaserte hendelser.
Så snart jeg trykker på Enter/Return, aktiveres overvåking, og hvis jeg nå holder musepekeren over eller klikker på teksten, logges disse hendelsene til konsollen som JavaScript-objekter:
Som du kan se på skjermbildet, ble flere typer musehendelser fanget da jeg klikket på elementet, skrev inn navnet mitt og deretter flyttet musen bort (skrivehendelsene, som var tastaturhendelser, ble ikke logget). Hendelsene er selve JavaScript-objekter, som det fremgår av skjermbildet; hvert hendelsesobjekt inneholder en enorm mengde informasjon. For eksempel utvidet jeg hendelsesobjektet «klikk», og antallet egenskaper kunne ikke passe alle i et enkelt skjermbilde!
Jeg oppfordrer deg på det sterkeste til å prøve denne funksjonen med en gang, siden den garantert vil spare deg for mye hodepine i dine kommende prosjekter!
Nettstedets ytelsesrapporter
I disse dager gjør eller ødelegger ytelsen til en bedrift/nettsted. Selv en liten økning i ytelse oversetter til massive SEO-gevinster så vel som brukertilfredshet. Men hvordan vet du hvilke deler av nettstedet ditt som trenger oppmerksomhet og hvilke som allerede er gode?
Trenger du å ansette et team med eksperter og vente tålmodig i noen dager?
Vel, det er tilfeller der det må gjøres, men heldigvis har Chrome DevTools dekket resten av oss. I de nyeste versjonene av Chrome (sent 2020) finner du en Lighthouse-fane i DevTools. For noen måneder tilbake ble det kalt revisjoner, og forvirrende nok er det navnet du finner i de offisielle dokumentene i skrivende stund. Uansett, poenget er at Lighthouse pleide å være et trendy nettsted for å sjekke nettsidens ytelse gratis, men så tok Google det ned (ingen grunn ble gitt). Heldigvis dukket den samme kraftige funksjonaliteten senere opp igjen i DevTools.
For å generere en resultatrapport er alt du trenger å gjøre å trykke på en enkelt knapp etter at siden du er interessert i har lastet inn:
Som du kan se på høyre side i skjermbildet, er det noen få alternativer for å kontrollere hvor mye informasjon du vil ha (og, selvfølgelig, hva du vil teste for). Når du er fornøyd med innstillingene, trykk på den store blå knappen, len deg tilbake og slapp av. Noen sekunder senere vil du ha en nyttig rapport som ser omtrent slik ut:
Tallene du ser i skjermbildet ovenfor viser den samlede poengsummen for hver kategori. Kategorien for progressive nettapper (PWA) er nedtonet, sannsynligvis fordi denne nettsiden ikke har noen PWA-funksjoner. Dessuten, som du kan se av rullefeltets størrelse i skjermbildet (helt til høyre), er det en lang rapport.
Slik ser en del av delen om ytelse ut:
Jeg vil ikke påstå at Lighthouse og dets forslag er den hellige gral av nettsideytelse, men disse er ekstremt nyttige; det er fordi nettstedeiere og utviklere sjelden har en anelse om hvilke problemer som eksisterer og nøyaktig hvordan de skal løse dem.
Ærlig talt, selv jeg føler meg tapt som webutvikler, siden ytelse og testing har en tendens til å være spesialiseringer. Som sådan er Lighthouse et lite kjent, undervurdert verktøy, nå en del av Chrome DevTools, som er til stor nytte for både bedriftseiere og utviklere/sysadmins.
Koderedigeringsdyktighet
Kilder-fanen i DevTools lar oss få tilgang til forskjellige filer lastet av nettstedet. Den har også funksjoner som koderedigering, lagring av utdrag osv. Dette burde ikke komme som noen overraskelse for webutviklere. Imidlertid har DevTools også noen få bekvemmeligheter innebygd som gjør livet enklere for utviklere som er vant til deres favorittkode-IDE-er.
DevTools bruker noen velkjente tastatursnarveier som vil spare deg tid og minimere frustrasjon med kodekrangel. For eksempel kan Ctrl + D (eller Cmd + D på Mac) brukes til å markere flere forekomster av et ord. På samme måte, hvis du holder Ctrl (eller Cmd på Mac) og klikker på flere steder i koden, får du flere markører. Ta en titt på videoen nedenfor for å få en bedre idé:
Hvis du synes dette er kult, sørg for å dykke ned i de offisielle dokumentene for å dra nytte av alle koderedigeringsfunksjonene DevTools har å tilby.
Kontroller DOM-elementtilstand
Noen ganger tester eller feilsøker vi noe, men atferden vi jakter på er bare tilgjengelig i en bestemt elementtilstand. Avhengig av hvilken tilstand det er, kan du ende opp med å ha det forferdelig; for meg er det «sveve»-tilstanden, ettersom jeg husker at jeg brukte utallige minutter på å prøve å time svevehandlingen eller slå på ekstra, midlertidig CSS, etc.
Heldigvis har Chrome DevTools en enkel måte å endre tilstanden til et inspisert element på. Dessuten er muligheten til å gjøre det der hvis vi høyreklikker på elementet (i Elementer-fanen), men gitt antall funksjoner og presset fra en dags arbeid, er det lett å overse dette:
Ja, det er egentlig så enkelt!
Nå trenger du ikke å bake betinget testlogikk inn i koden din, skrive ekstra CSS eller hoppe gjennom noen andre bøyler når du observerer et element i en annen tilstand.
Verktøypanel
Sist men definitivt ikke minst på denne listen er Verktøy-panelet. Det er en annen av de utrolig nyttige funksjonene som er godt skjult og bare kan sees ved hjelp av hurtigtaster. Som navnet antyder, er Verktøy-panelet ikke et enkelt verktøy, men et slags dashbord der nesten alle DevTools funksjoner er tilgjengelige. Siden det er alt for mange funksjoner som tilbyr den generelle DevTools-funksjonaliteten, er en søkelinje tilgjengelig rett øverst.
For å aktivere Verktøy-panelet, sørg for at du er i DevTools-panelet og trykk deretter Ctrl + Shift + P (eller Cmd + Shift + P for Mac-brukere):
Verktøypanelet er fullt av muligheter og overraskelser. Visste du for eksempel at du kunne ta et skjermbilde direkte fra DevTools?
Jeg vedder på ikke, fordi du må starte verktøypanelet og skrive «skjermbilde» i søkefeltet for å avdekke det:
Du vil også legge merke til flere alternativer for å ta skjermbilder, inkludert en for den valgte DOM-noden! Utforsk Verktøy-panelet mer, og jeg forsikrer at du ikke vil bli skuffet!
Hvis du trenger å ta et skjermbilde av en hvilken som helst nettside eksternt, sjekk ut tipsbilk.net Skjermbilde-verktøyet.
Konklusjon
Chrome-nettleseren i seg selv er funksjonsrik, men der den virkelig skinner er DevTools-tilbudet. Som vi så i denne artikkelen, er det ganske mange godt skjulte funksjoner – og andre som gjemmer seg for øyet – som et stort flertall av brukerne ikke vet om. Hvorfor er disse funksjonene skjult?
Jeg antar at noen av disse er veldig eksperimentelle (som designmodus), og Chrome-utviklerne vil gjøre det vanskelig for vanlige brukere å finne disse funksjonene. For resten av de mange funksjonene, tror jeg det rett og slett er et tilfelle av informasjonsoverbelastning: hvis det er for eksempel 120 funksjoner, med noen av dem med underfunksjoner og så videre, er det ganske umulig å designe riktig brukergrensesnitt for slike et scenario. Dessuten har Google historisk sett ikke gjort en god jobb med produktenes UX, så det er det. 🤷🏻♂️
Uansett håper jeg du fant noen av disse funksjonene nyttige. Men enda viktigere, jeg håper denne artikkelen ga deg en følelse av hva som skjuler seg, slik at neste gang du vil utforske eller søke etter noe spesielt, vet du hvor du skal gå for å «grave dypt». 😆