Chrome DevTools är en av de största anledningarna till att utvecklare vägrar att röra någon annan webbläsare.
Men de flesta av oss använder bara en handfull funktioner och förblir omedvetna om många fler häpnadsväckande funktioner som släpps tyst.
Låt oss upptäcka några av dessa dolda pärlor!
Alla har sitt favoritoperativsystem, hårdvaruplattform, enhetstyp, enhetsformfaktor, etc. Men en sak är gemensam för alla — de kör webbläsaren Chrome och bara webbläsaren Chrome! Jag tror att det är säkert att säga att webbläsarkrigen är över, och Chrome har vunnit övertygande.
Windows-användare använder bara standardwebbläsaren för att ladda ner Chrome och använder därefter Chrome, och ignorerar alla ”rekommendationer” från Windows. Detsamma gäller för Apples enheter (särskilt MacBooks och enheter med större skärm), där användare och utvecklare undviker Safari, trots Apples många starka påståenden och konverteringstaktik.
Och om en enhet inte kör Chrome är chansen stor att den kör en Chrome-kompatibel spinoff som t.ex Modig eller Vivaldi. Ja, jag vet, tekniskt sett är dessa webbläsare inte baserade på Chrome, men det är en annan diskussion. Den genomsnittliga användaren kanske använder dessa andra webbläsare av ideologiska eller speciella skäl, men när det kommer till utvecklare finns det ingen annan webbläsare i sikte förutom Chrome.
Även det faktum att det är ett minnesätande monster ignoreras. Anledningen är enkel: Chrome DevTools.
Bildkälla: officiella Chrome DevTools-dokument
Nu, om du läser den här artikeln, är det säkert att anta att du antingen är en kraftanvändare, en pysslare, en webbutvecklare eller något i linje med det. Som sådan behöver ingen av oss en introduktion till DevTools, hur man öppnar det, dess olika funktioner, etc.
Istället, utan att slösa någon tid, låt oss dyka rakt in i några av de mindre kända men förvånansvärt användbara funktionerna i Chrome DevTools.
Innehållsförteckning
Designläge
En av de saker som utvecklare rutinmässigt gör är att inspektera ett element på sidan och sedan ändra dess HTML för att förhandsgranska något eller testa effekten av en förändring.
Att arbeta med HTML direkt i DevTools är dock inte det smidigaste någonsin – att vada genom taggsoppan, anstränga ögonen och försöka hitta rätt öppnings-/stängningsparentes och hantera en löjlig mängd blanksteg när du redigerar text (blanksteg som uppenbarligen saknas i dokumentet du ser), är några av de problem du kan behöva ta itu med. Det är ännu värre om du är designer och inte vill sålla igenom röran.
Här är en skärmdump från en av sidorna på denna webbplats (adminvista.com):
Den djupt inkapslade HTML och mystiska, förvirrande CSS-klasser är typiska för alla icke-triviala webbplatser idag, vilket är där upplevelsen med DevTools är minst sagt suboptimal. 🤭
Men det finns en DevTools-funktion som heter Design Mode, som kan minska smärtan i många fall. Genom att använda designläget (det är inte det officiella namnet, förresten; det är bara vad folk har döpt det på grund av hur det aktiveras och vad det gör – oroa dig inte, vi får se snart!), ändras till sida kan göras visuellt och levande, precis som att redigera ett kalkylblad eller textredigerare! Den enda haken är att den här funktionen inte är på som standard, och att aktivera den är lite av en huvudvärk, särskilt för icke-utvecklare.
Det är i alla fall ganska enkelt att göra det; allt du behöver göra är att följa instruktionerna nedan. Beroende på var du sitter på kurvan för användarförfining kan detta vara skrattretande lätt eller måttligt svårt. Så här gör du:
- Se till att webbsidan du vill redigera är laddad och att du för närvarande tittar på den (det vill säga att fliken i fråga är den aktiva).
- Öppna panelen DevTools som du brukar (kortkommandon, musklick, vad som helst). Jag gillar att använda kortkommandon, och på Mac gör Opt + Cmd + jag jobbet.
- Nu, med DevTools öppna, gå till fliken som heter ”Console”. Vissa av er kanske himlar med ögonen på hur fånigt och självklart allt detta verkar, men hallå, låt oss också tänka på de (hundratals?) tusentals människor där ute som kämpar när de arbetar med webbläsarkonsolen och JavaScript (av någon anledning ).
- Klicka på första raden bredvid markören, som då kommer att presentera en skrivprompt, och nu kan du skriva JavaScript-kod där (se skärmdumpen lite längre ner).
- Nu måste vi skriva lite JavaScript-kod. Oroa dig inte, eftersom det du behöver skriva/skriva är väldigt kort och okomplicerat: document.designMode = ”på”. Du kan också kopiera och klistra in koden från den här sidan (om du gör det, se till att formateringen inte kopieras – vi behöver bara vanlig text) eller om du känner dig säker, skriv in den.
- Tryck på Enter/Retur.
”Det är allt??!”
Japp, det var allt!
Nu kan du fritt göra redigeringar på sidan som om det vore ett dokument. Kolla in den här exempelvideon där jag liveredigerar Spotify-webbplatsen med designläge:
Design Mode-funktionen, spännande som den är, är inte en silverkula; du kan till exempel inte enkelt kopiera och klistra in knappar, ändra deras utseende och så vidare. Det faktiska antalet saker som den kan göra jämfört med en drömredigerare för visuella webbsidor är mycket låg; men det löser användningsfall där innehåll måste ändras visuellt och i farten.
Som sagt, det är inte för långsökt att hävda att Chrome-folket testar hur väl den här funktionen tas emot; om den hittar bra mottagning och ett starkt användningsområde är det rimligt att förvänta sig att mer kraftfulla redigeringsmöjligheter snart kommer att följa! 🤞🏻🤞🏻
Simulering av nätverksförhållanden
Nätverksfliken i Chrome DevTools är kanske den mest använda (jag har naturligtvis ingen data om den, men som webbutvecklare brukar jag använda fliken Konsol kanske 20-30 % av tiden, och Nätverksfliken resten av tiden). Det ger oss all möjlig information om förfrågningar som görs från sidan, deras typ, metadata/rubriker, status, nedladdningsförlopp för tillgångar (bilder, stilmallar, etc.), laddningstider och så vidare. Med en sådan otrolig användbarhet är det inte konstigt att fliken Nätverk är den vanligaste.
Och ändå är det enkelt att missa funktionen vi diskuterar; du kanske inte har märkt en ofarlig dropdown som säger det uppenbara: Online.
Om du klickar på det här, kommer du att se en rullgardinsmeny med olika alternativ som låter dig strypa nätverkshastigheten: Snabb 3G, Långsam 3G, Offline, etc. Även om det kan finnas olika användningsfall för detta alternativ, är det vanligaste att testa webbplatsen prestanda på långsamma nätverk eller webbappbeteende när den är offline (förutsatt att sådana funktioner har lagts till).
Låt oss ta det här en sväng. Jag ställer in nätverket på ”Långsam 3G” och laddar om samma sida från föregående skärmdump. Innan jag gör det, lägg märke till i den tidigare skärmdumpen hur på min nuvarande nätverksanslutning (ett 40 Mbps bredband), de flesta tillgångar laddas ner på under 100 millisekunder.
Och nu är det dags att se vad långsam 3G gör med det.
Vilken skillnad!
Observera att laddningstiden för tillgångar nu är i intervallet 5-10 sekunder. Dessutom slutförde webbplatsen att ladda helt på 17,25 sekunder! Ja, jag vet vad du tänker, men du måste tänka på att på ett långsamt 3G-nätverk kommer det ta flera sekunder att ladda alla moderna webbplatser. Om du vill ha snabb laddning på långsamma nätverk är en annan sak, men allt som allt måste det vara ett affärsbeslut där vinsterna motiverar ansträngningen.
Lägg märke till varningsikonen på fliken Nätverk i skärmdumpen ovan. Det är Chromes sätt att påminna dig om att du har gjort någon icke-standard, ihållande förändring, och om du inte vet vad du gör bör du kanske återställa den.
Interaktiv färgväljare
Att inspektera DOM-element i DevTools är något vi alla gör i stort sett varje dag. Vi är också vana vid avsnittet med CSS-detaljer som visas bredvid, och vi vet att vi kan redigera det och se resultatet direkt.
En liten bekvämlighet som döljs bland allt detta är att om du klickar på en CSS-färgegenskap kommer ett välbekant färgväljargränssnitt att dyka upp!
Lägg märke till att det inte är en grundläggande färgväljare. Den låter dig styra genomskinlighet, ändra färgsystem som används, välja en färg direkt från sidan och mycket mer.
Så nästa gång du experimenterar med en webbplatss accentfärger, till exempel, behöver du inte träna eller gissa på rätt värde för den nyans du har i åtanke! Faktum är att många gillar att designa webbsidor direkt i webbläsaren; för dem är funktioner som dessa en gudagåva! 🙂
Övervaka händelser på sidan element
Vi befinner oss ofta i en situation där vi önskar att vi visste vad som pågick med det specifika elementet vi är intresserade av. Detta gäller särskilt när du använder jQuery i en icke-trivial kodbas — vare sig din eller andras; händelsehanterare och logik är spridda överallt, och att spåra en bugg kan vara en mardröm.
Tack och lov har Chrome DevTools en fiffig funktion för just detta. Den kommer att observera det indikerade elementet åt dig och logga händelserna till konsolen. Men det är lite av en besvikelse: den här funktionen har inte elementvalsmöjligheter baserade på CSS-klassnamn. Så jQuery-sättet $(“#email”) är inte tillgängligt. 🙂
Med det sagt, låt oss se hur man får det att fungera. Vi börjar med att göra ett enkelt ”inspektera element” med hjälp av DevTools-inspektören. Ja, det är samma inspektionsverktyg som vi använder varje dag.
I skärmdumpen nedan har jag använt inspektörsverktyget för att markera textinmatningen. Med ”markera” menar jag inte att elementet på sidan är markerat (det är det inte, som du kan se); istället klickades inspektörsmarkören på textinmatningen, och motsvarande HTML-kod i DevTools är markerad.
Om du gör detta riktar du in sig på det för närvarande inspekterade elementet för händelseövervakning, vilket gör elementet tillgängligt som en speciell JavaScript-variabel som kallas $0. För att sedan se till att jag inte klickar någon annanstans i webbläsarfönstret slarvigt (särskilt HTML-koddelen), klickar jag på konsolen och bifogar en händelseavlyssnare för denna textinmatning. För detta behöver jag bara en rad kod: monitorEvents($0, ’mus’). ”Mus”-delen här säger till Chrome att jag bara är intresserad av att titta på musbaserade händelser.
Så fort jag trycker på Enter/Return aktiveras övervakning, och om jag nu håller muspekaren över eller klickar på textinmatningen loggas dessa händelser till konsolen som JavaScript-objekt:
Som du kan se på skärmdumpen fångades flera typer av mushändelser när jag klickade på elementet, skrev mitt namn och sedan flyttade bort musen (skrivhändelserna, som var tangentbordshändelser, loggades inte). Händelserna är själva JavaScript-objekt, vilket framgår av skärmdumpen; varje händelseobjekt innehåller en enorm mängd information. Till exempel utökade jag händelseobjektet ”klick”, och antalet egenskaper kunde inte passa alla i en enda skärmdump!
Jag uppmuntrar dig starkt att prova den här funktionen omedelbart eftersom den säkerligen kommer att spara dig massor av huvudvärk i dina kommande projekt!
Rapporter om webbplatsens prestanda
Dessa dagar gör eller förstör webbplatsens prestanda ett företag/webbplats. Även en liten ökning av prestanda leder till enorma SEO-vinster såväl som användarnöjdhet. Men hur vet du vilka delar av din webbplats som behöver uppmärksamhet och vilka som redan är bra?
Behöver du anställa ett team av experter och vänta tålmodigt i några dagar?
Tja, det finns fall där det måste göras, men tack och lov har Chrome DevTools oss andra täckt. I de senaste versionerna av Chrome (sent 2020) hittar du en Lighthouse-flik i DevTools. För några månader sedan hette det Audits, och förvirrande nog är det namnet du hittar i de officiella dokumenten när det skrivs. Hur som helst, poängen är att Lighthouse brukade vara en trendig webbplats för att kontrollera webbplatsens prestanda gratis, men sedan tog Google ner den (inga skäl gavs). Tack och lov återuppstod samma kraftfulla funktion senare i DevTools.
Allt du behöver göra för att skapa en resultatrapport är att trycka på en enda knapp efter att sidan du är intresserad av har laddats:
Som du kan se på höger sida i skärmdumpen finns det några alternativ för att styra hur mycket information du vill ha (och, naturligtvis, vad du vill testa för). När du är nöjd med inställningarna, tryck på den stora blå knappen, luta dig tillbaka och koppla av. Några sekunder senare får du en fördelaktig rapport som ser ut ungefär så här:
Siffrorna du ser i skärmdumpen ovan visar det totala resultatet för varje kategori. Kategorin för progressiva webbappar (PWA) är nedtonad, troligen för att den här webbplatsen inte har några PWA-funktioner. Dessutom, som du kan se av rullningslistens storlek i skärmdumpen (till höger), är det en lång rapport.
Så här ser en del av avsnittet om prestanda ut:
Jag kommer inte att påstå att Lighthouse och dess förslag är webbplatsens heliga gral, men dessa är oerhört användbara; det beror på att webbplatsägare och utvecklare sällan har en aning om vilka problem som finns och exakt hur de ska lösa dem.
Ärligt talat, även jag känner mig vilsen som webbutvecklare, eftersom prestanda och testning tenderar att vara specialiseringar av olika slag. Som sådan är Lighthouse ett föga känt, underskattat verktyg, nu en del av Chrome DevTools, som är till stor nytta för både företagsägare och utvecklare/sysadmins.
Kodredigeringsförmåga
Fliken Källor i DevTools låter oss komma åt olika filer som laddas av webbplatsen. Den har också funktioner som kodredigering, spara kodavsnitt, etc. Så mycket borde inte komma som någon överraskning för webbutvecklare. Men DevTools har också några bekvämligheter inbyggda som gör livet lättare för utvecklare som är vana vid sina favoritkod-IDE:er.
DevTools använder några välkända kortkommandon som sparar tid och minimerar frustration med kodbråk. Till exempel kan Ctrl + D (eller Cmd + D på Mac) användas för att markera flera förekomster av ett ord. På samma sätt, om du håller ned Ctrl (eller Cmd på Mac) och klickar på flera ställen i koden får du flera markörer. Ta en titt på videon nedan för att få en bättre uppfattning:
Om du tycker att detta är coolt, se till att dyka in i de officiella dokumenten för att dra nytta av alla kodredigeringsfunktioner som DevTools har att erbjuda.
Kontrollera DOM-elementets tillstånd
Ibland testar eller felsöker vi något, men beteendet vi jagar är bara tillgängligt i ett visst elementtillstånd. Beroende på vilket tillstånd det är, kan det sluta med att du har en fruktansvärd tid; för mig är det ”sväva”-tillståndet, eftersom jag minns att jag slösade bort otaliga minuter på att försöka tajma svävningsåtgärden eller slå på ytterligare, tillfällig CSS, etc.
Tack och lov har Chrome DevTools ett enkelt sätt att ändra tillståndet för ett inspekterat element. Dessutom finns alternativet att göra det där om vi högerklickar på elementet (på fliken Element), men med tanke på antalet funktioner och trycket på en dags arbete är det lätt att förbise detta:
Ja, det är verkligen så enkelt!
Nu behöver du inte baka in villkorlig testlogik i din kod, skriva ytterligare CSS eller hoppa genom några andra ramar när du observerar ett element i ett annat tillstånd.
Verktyg panel
Sist men definitivt inte minst på den här listan är verktygspanelen. Det är en annan av de otroligt användbara funktionerna som är väl dolda och bara kan ses med kortkommandon. Som namnet antyder är verktygspanelen inte ett enda verktyg utan en slags instrumentpanel där nästan alla DevTools funktioner är tillgängliga. Eftersom det finns alldeles för många funktioner som erbjuder den övergripande DevTools-funktionaliteten finns ett sökfält tillgängligt högst upp.
För att aktivera verktygspanelen, se till att du är i panelen DevTools och tryck sedan på Ctrl + Skift + P (eller Cmd + Skift + P för Mac-användare):
Verktygspanelen är full av funktioner och överraskningar. Visste du till exempel att du kan ta en skärmdump direkt från DevTools?
Jag slår vad om inte, eftersom du måste starta verktygspanelen och skriva ”skärmdump” i sökfältet för att avslöja det:
Du kommer också att märka flera alternativ för att ta skärmdumpar, inklusive ett för den valda DOM-noden! Utforska verktygspanelen mer och jag försäkrar att du inte kommer att bli besviken!
Om du behöver ta en skärmdump av en webbsida på distans, kolla in adminvista.com Screenshot-verktyget.
Slutsats
Chrome-webbläsaren i sig är funktionsrik, men där den verkligen lyser är DevTools-erbjudandet. Som vi såg i den här artikeln finns det en hel del väl dolda funktioner – och andra som gömmer sig i sikte – som en stor majoritet av användarna inte känner till. Varför är dessa funktioner dolda?
Jag antar att vissa av dessa är väldigt experimentella (som designläge), och Chrome-utvecklarna vill göra det svårt för vanliga användare att hitta dessa funktioner. För resten av de många funktionerna tror jag att det helt enkelt är ett fall av informationsöverbelastning: om det finns t.ex. 120 funktioner, där några av dem har underfunktioner och så vidare, är det i stort sett omöjligt att designa rätt användargränssnitt för sådana ett scenario. Dessutom har Google historiskt sett inte gjort ett bra jobb med sina produkters UX, så det finns det. 🤷🏻♂️
Oavsett vilket hoppas jag att du tyckte att några av dessa funktioner var användbara. Men ännu viktigare, jag hoppas att den här artikeln gav dig en känsla av vad som gömmer sig var så att nästa gång du vill utforska eller söka efter något speciellt, vet du vart du ska gå för att ”gräva djupt”. 😆