Tervezze meg a tökéletes URL-t

Ez a cikk először itt jelent meg 215. szám of .net magazin - a világ legkeresettebb weblaptervezői és -fejlesztői magazinja.

Az URL-tervezés az utóbbi évben ismét a vita tárgyává vált. A Twitter 2010 őszi újratervezésével kezdődött, amely úgy tűnik, hogy érvényesítette azt az általános véleményt, amelyet a nyilvánosság előtt álló webhelyek rossz webtervezési technikájának tekintettek: a „hash-bang” URL-t.

Ezek olyan URL-ek, amelyek közvetlenül a domain után a „#!” Vagy „£!” Betűvel kezdődnek - például twitter.com/kurafire válik twitter.com/#!/kurafire . Ezután az URL része, amely egyedileg azonosítja az oldal tartalmát, a végén hozzáadódik. Ez a technika a teljesítmény javítását célozza - lényegében arra irányul, hogy ne töltsön be újra egy teljes oldalt, ha csak egy kis darabot kell újból betöltenie. De nem jön komoly hátrányok nélkül.



Ez az oktatóanyag megvizsgálja az URL-tervezés finomabb részleteit, és elmagyarázza, miért kell elriasztani a hash-bangokat. De először vessünk egy pillantást az alapokra.

Mi az URL?

Az URL kifejezés az Egységes erőforrás-kereső rövidítést jelenti, és meghatározza egy bizonyos erőforrás, például egy weboldal helyét. Mivel a hely egy hely azonosítója, minden URL egyben URI vagy egységes erőforrás-azonosító is.

Az URL azonban nem csak az URI helyét, hanem az elérésének módját is meghatározza - a sémát vagy a protokollt. Az URL szintaxisa a következő:

séma: // domain / elérési út? query_string # fragment_identifier

Itt a HTTP-protokollt használó webcímekre fogunk összpontosítani, és figyelmen kívül hagyjuk a MAILTO, az FTP vagy a FILE, valamint a portokat, a beágyazott felhasználóneveket és a jelszavakat. A HTTPS-cím megegyezik a szokásos HTTP URL-ekkel, azzal a további követelménygel, hogy biztonságos kapcsolatot használjon.

Az URL szintaxisa alkotó részekre bontva. Az URL meghatározza egy bizonyos erőforrás helyét, amely weboldalakat is tartalmazhat. Ebben az oktatóanyagban mi

Az URL szintaxisa alkotó részekre bontva. Az URL meghatározza egy bizonyos erőforrás helyét, amely weboldalakat is tartalmazhat. Ebben az oktatóanyagban a HTTP protokollt használó webcímekre koncentrálunk

Tartomány

Bár a domain rész nyilvánvaló, érdemes megemlíteni, hogy a www. nem része a domainnek. Ez pusztán egy aldomain, amelyet a webhelyek gyakran használnak, de technikailag felesleges. Sok nem technikai ember úgy gondolja, hogy erre szükség van, így attól függ, hogy a www.yourdomain.com vagy csak a yourdomain.com webhelyet használja-e a marketingben vagy elsődleges webcímként, a közönségétől függ. Ettől függetlenül mindkét címnek ugyanarra a webhelyre kell felkeresnie a látogatókat.

Pálya

Az elérési út az URL-tervezés egyik legfontosabb része, amelyet mappaszerkezetként kell létrehozni, előre mutató perjelek használatával, függetlenül a háttérszerver beállításaitól. Webhelyének vagy webalkalmazásának minden egyedi oldalának meg kell határoznia a saját egyedi útvonalát.

Ennek a lehető legjobban leírónak és értelmesnek kell lennie, és olvashatónak kell lennie az emberek számára. Végül is az URL-eket embereknek szánják, nem pedig a keresőmotoroknak - az utóbbiaknak nem okoz gondot a véletlenszerű karakterek hosszú sorának a megjegyzése, de a felhasználók megosztják másokkal az URL-eket.

Tartsa a lehető legrövidebb utakat. / about-this-company feleslegesen hosszú; / kb megteszi. Az olyan olvasható kifejezések, mint a neved.com/wrote/some-blog-post vagy aname.com/works-for/a-cool-company, kellemes érzetet adhatnak, de célszerűbb megtartani a rövidséget.

Lekérdezési húrok

A webhelyek többsége lehetővé teszi a látogatók számára a keresést. Erre a legmegfelelőbbek a lekérdezési karakterláncok, valamint a kapcsolódó műveletek, például az oldal tartalmának szűrése és rendezése.

Korábban sok kiszolgálóoldali rendszer visszaélt a lekérdezési karakterlánc-paraméterekkel a webhely különböző oldalainak kiszolgálására, például a somesite.com/index.php?p=about címen. Más webhelyek egy lépéssel túl messzire mentek a helyes irányba, és átírták a keresési lekérdezési karakterláncokat útvonalként, ehhez hasonlóra: / q / My% 20search% 20 query / sortby / date / order / desc /.

Mindkét megközelítés rossz gyakorlat, amelyet javasolok elkerülni. A legfontosabb, hogy a lekérdezési karakterláncot az oldal opcionális kiegészítéseként kell kezelni; az URL-nek akkor kell működnie, hogy érvényes és hasznos oldalt állítson elő, még akkor is, ha eltávolítja. A lapozás egy érvényes lekérdezési karaktersorozat változó tartalomfolyamú oldalakhoz.

Töredékazonosítók

Érdekes tény: a töredékazonosító az URL egyetlen része, amelyet nem küldenek az oldalt tároló szervernek. Ehelyett egy meghatározott helyet kell meghatároznia az eredményül kapott oldalon, például a GYIK bizonyos szakaszát vagy a cikk végén található lábjegyzetet.

A böngészők az oldal újratöltése nélkül navigálhatnak több töredékazonosító között, és ezt a mechanizmust választották vissza az emberek, hogy a teljes webhelyek működjenek anélkül, hogy a navigálás között újratöltenék az oldalakat (az új twitter.com , például).

Mivel ez egy kívánatos felhasználói élmény, a böngésző gyártói létrehozták a HTML5 History API-t, amely megfelelő (bár vadonatúj) technika a webhelyek közötti navigáláshoz az oldal újratöltése és a töredékazonosítók visszaélése nélkül.

A HTML5 History API használatával kapcsolatos részletes utasításokat a A történelem manipulálása ’Mark Pilgrim Dive Into HTML5 című online könyvének fejezete.

A webcím világos és tömör anatómiája érdekében ott van

A webcím világos és tömör anatómiája érdekében kiváló cikk található a Doepud Web Design webhelyén

A megállapodás megszegése

Az URL-összetevők bármilyen kombinációja csendes megállapodást jelent: ez a bizonyos URL egyedi erőforrást vagy adatobjektumot ad vissza, opcionálisan az adott erőforrás egy adott alszakaszára hivatkozva.

Mivel a töredékazonosítókat nem küldjük el a szerverre, lehet azzal érvelni, hogy a hash-bang URL-ek technikailag nem érvényesek.

A Wikipédia oldal az URL-ekről : 'A számítás során az egységes erőforrás-kereső (URL) egy egységes erőforrás-azonosító (URI), amely meghatározza, hogy hol található az azonosított erőforrás, és annak lekérésének mechanizmusát.' A hash-bang alapú URL nem eléggé határozza meg a tartalom visszakeresésének mechanizmusát, mivel JavaScript-re van szükség a kiszolgálóhoz, miután a szerver már elküldte a böngészőnek egy HTML oldalt - egy olyan oldalt, amelyhez nem tartozik a tartalom. kért URL (még).

Másképp fogalmazva: a hash-bangs megváltoztatja az erőforrás lekérésének mechanizmusát. Ezt már nem egyszerűen és kizárólag az URL sémája határozza meg, hanem „a szerver által meghatározott és szállított, valamint egy böngésző szintű JavaScript-processzor által értelmezett, teljesen működő JavaScript”.

Ez mind pedánsnak tűnhet, de a jelentőség akkor válik egyértelművé, ha figyelembe vesszük az erőforrásokhoz való hozzáférés valóságát. Az URL-t betöltő böngésző nyilvánvalóan a leggyakoribb módja a weboldal betöltésének, de nem ez az egyetlen módszer. Minden egyszerű wget- vagy curl-alapú kísérlet a tartalom beolvasására az internetről már nem fog működni, és minden webtartalmat betöltő szoftvernek tartalmaznia kell egy teljes JavaScript-elemzőt az ilyen URL-ek támogatásához. Ez mind feltételezi, hogy a JavaScriptet nem szűri le valamilyen proxykiszolgáló vagy tűzfal, és nem tartalmaz hibákat az oldalon. Amikor a felhasználók kikapcsolják a JavaScriptet böngészőjükben, ezek a webhelyek leállnak.

Ha a csendes megállapodás megszegése és az egész webhely törékeny technikákra való támaszkodása nem elég rossz, a hash-bangok egyirányú utcát jelentenek a tartós karbantartáshoz és támogatáshoz is. A szerveroldali átírást nem használhatja az URL-ekhez, még akkor sem, ha újratervezi az újratervezést. Így, hacsak nem akarja feltörni a bejövő linkeket és az emberek könyvjelzőit, mindig meg kell végeznie bizonyos feldolgozásokat a domain elsődleges céloldalán, hogy támogassa ezeket az URL-eket, amint azokat kitette.

Ott

Kiváló összefoglaló van a hash-bang kérdésről az AppStormnál

Rossz gyakorlatok

Az URL-ek megtervezésének sokféle módja van. A fenti alapok mind remek technikák, de tudnunk kell, mi okozza a rossz URL-kialakítást annak érdekében, hogy teljes mértékben megértsük és értékeljük, mitől jó a jó URL-tervezés. Íme néhány elkerülendő gyakorlat, kezdve a legsúlyosabb elkövetőktől, és folytatva a pusztán nem ajánlott módszereket:

Oldalazonosító hashek

Egyes (többnyire ősi) tartalomkezelő rendszerek vagy blogmotorok minden egyedi oldalt véletlenszerű karakterek hosszú karakterláncával azonosítanak; valami ilyesmi: 5F0C866C-6DDF-4A9A-9515-531B0CA0C29C.html. Ha a tartalomkezelő rendszer vagy a webhelymotor ilyen URL-eket generál, akkor megtudhatja, hogyan lehet ezt a viselkedést azonnal felülírni vagy kikapcsolni; ha ez nem lehetséges, akkor valóban jobb, ha modernebb CMS-t szerez. Ezeknek az URL-eknek csak hátrányai vannak - a felhasználók és önmagatok számára -, és számtalan jó, modern rendszer áll rendelkezésre webhelye működéséhez, amelyek elkerülik ezt a szörnyű technikát.

Munkamenet hashek

Bár nem olyan rossz, mint az oldalaknál, a webhelyén a munkamenetekhez használt hashek mégis rosszak.

Először is negatívan befolyásolhatják a SEO-t. De a nagyobb aggodalom az, hogy az őket alkalmazó rendszerek többsége SHA-1-et használ, ami viszonylag bizonytalan - minden bizonnyal olyan felhasználói munkamenetek vagy bejelentkezések esetén, amelyek bármilyen érzékeny adatot tartalmaznak.

Fájlkiterjesztések

URL-jeinek mentesnek kell lenniük .php, .aspx és így tovább. A fájlkiterjesztések nem kompatibilisek előre, ezért ha megváltoztatja a háttérrendszert, és az összes URL-címe tartalmazza az .aspx fájlt, akkor kénytelen a szerveroldali átírást elvégezni a webhely minden egyes oldalához. Költséges, nem hatékony és teljesen felesleges. A .html kiterjesztés sem igazán ajánlott, de ha biztos benne, hogy az épített oldalakat csak statikus fájlként fogja csak kiszolgálni, az elfogadható technika.

Nem ASCII karakterek

Azok a webhelyek, amelyekben az elsődleges tartalmi nyelv a karakternyelv, némileg kifogásolhatók, de az ékezetes latin és a nem alapvető írásjeleket a legjobb elkerülni.

Aláhúzások

Ezek rosszabb használhatósággal és SEO értékkel bírnak, és nem jelentenek kézzelfogható előnyöket a kötőjelek fölött.

Kulcsszó kitöltése

Több kulcsszó hozzáadása az URL-ekhez segíthet a SEO-ban, de összezavarja a felhasználókat. Ezenkívül gyorsan fennáll annak a veszélye, hogy kulcsszó-spamelőként jelölik meg.

Ban ben

Az „Old Twitter” -ben ez az egyetlen tweet teljes egészében kétszer jelen van: egyszer a tartalomban, mint leírás, egyszer pedig az oldalon. Azonban...

... az új Twitter egyáltalán nem tartalmazza a tweetet, és 44 kilobájt méretű. Ezt az oldalt JS-elemző környezetben kell végrehajtani, hogy feltöltse a tweetet, vagy azt

... az új Twitter egyáltalán nem tartalmazza a tweetet, és 44 kilobájt méretű. Ezt az oldalt JS-elemző környezetben kell végrehajtania a tweet betöltéséhez, különben nem lehet visszakeresni

Jó gyakorlatok

Bár fontos tudni, hogy milyen technikákat érdemes elkerülni, nyilván érdemesebb tudni, melyiket érdemes használni. Most már minden alapunk megvan, így nézzünk meg néhány fejlett taktikát, amelyek remek URL-eket eredményeznek.

„A hűvös URI-k nem változnak”, ahogy Tim Berners-Lee még 1998-ban elmondta, de azon kívül, hogy állandóak maradnak az újratervezés során, mi mást jelent a remek címek számára? Néhány kulcsfontosságú szempont a robusztusság, a feltörés és a névtér.

Robusztus URL-hozzárendelés

Az emberek megosztják az URL-eket, és néha olyan közegben teszik, ahol a címzettek környezete két sorra vonhatja az URL-t. Ez a leggyakoribb olyan blogbejegyzéseknél, amelyek teljes dátumot és hosszú címet tartalmaznak az URL-ben.

Az egyik megoldás az, hogy az összes URL-t 70 karakternél rövidebbnek kell tartani, de ez nem mindig ideális. Ezenkívül a relációs adatbázis-rendszerek jellege olyan, hogy az ID-értékek gyorsan megkereshetők, a húrok azonban nem.

Nagy forgalom esetén ez elég komoly szűk keresztmetszetet jelenthet egy szerver lebontásához. További hardver hozzáadása drága megoldás lehet.

A robusztus URL-hozzárendelés mindkét problémát megoldhatja az Ön számára. Ha egy egyedi azonosítót beágyaz az útjába már korán, hosszú, teljesen leíró URL-ekkel rendelkezhet, ha szükséges, de mégis élvezheti a rövidebb URL-ek megbízhatóságát és az azonosító-keresés sebességét.

Ezt az URL-t vegye fel: yourdomain.com/news/1982-this-is-a-longer-news-posts-title- amely-szinte-biztosan-megtörne-egy-egy új sorban-valamiben- ügyfelek. Ebben a példában ‘1982’ az adott bejegyzés adatbázis-rekordjának azonosító értéke. A CMS ekkor csak az URL ezen részét használhatja a sikeres kereséshez: yourdomain.com/news/1982.

Ezután minden opcionális, és kedves az emberek és a SEO számára, de nem számít, ha két sorra burkolódik.

Az egyetlen hátránya ennek a technikának az, hogy maguk az igazolványok nem annyira emberbarátak, ezért ezt kompromisszumnak kell tekinteni.

Hackelhető URL-ek

Jó, feltörhető URL-ben az ember módosíthatja vagy eltávolíthatja az útvonal egyes részeit, és a várt eredményeket elérheti a webhelyéről. Jobban tájékozódnak a látogatók az oldalai körül, és lehetővé teszik számukra, hogy könnyebben léphessenek feljebb. Példa erre: yourdomain.com/blog/2011/05/20/some-article. Ennek csökkentése minden előrejelzésnek elvárható eredményeket hozhat. Például a domain.com/blog/2011/05/20/ webhelynek vissza kell adnia az összes 2011. május 20-án közzétett bejegyzést. A yourdomain.com/blog/2011/05/ áttekintést nyújt a 2011. májusi bejegyzésekről, míg a yourdomain.com/blog A / 2011 / felhasználható a 2011-es bejegyzések áttekintésének előállítására, vagy ha ez túlságosan szemcsés, akkor csak az egyes hónapokra vonatkozó összesítéseket tegye közzé. A yourdomain.com/blog/ webhelynek vissza kell adnia a legfrissebb frissítéseket, függetlenül azok tényleges közzétételi dátumától.

Az, hogy mennyire részletesnek kell lennie az ilyen URL-ek tervezésével kapcsolatban, valóban a webhely tartalmától és közönségétől függ. Minél aktuálisabb a tartalom, annál jobban profitál az URL-ben való közzététel dátumaiból; minél gyakrabban jelenik meg az új tartalom, annál jobban profitál a finomabb részletességből.

Más területeken - például kategóriákban, termékekben és szolgáltatásokban - nincs szükség dátumkomponensekre, de bármennyire is részletesek (vagy nem) az URL-ek, végül teljesen feltörhetőknek kell lenniük.

Tévedés azt mondani, hogy a feltörhető URL-eket csak a hozzáértő látogatók használják, és utasítsa el őket, ha a közönsége nincs ebben a résben. Először is, a felhasználók az idő múlásával csak többet értenek hozzá a technológiához, nem kevesebbet. De ami még ennél is fontosabb, nem ismeri minden látogatóját, jelenlegi és jövőbeni látogatóit.

Névterek

Az útvonal legfelső szintű szakasza az URL legértékesebb ingatlanja. Ha webhelye lehetővé teszi a felhasználók számára a regisztrációt, és ezen a szinten saját profillal rendelkeznek, akkor hozzon létre egy fekete listát a felhasználónevekről, amelyek tartalmazzák az összes jelenlegi és lehetséges jövőbeni funkciót, amelyekre szükség lehet. Néhány remek példalista megtalálható itt: Quora ezért.

A felhasználónév mögötti névtér-funkciók: a listák vagy a követők nagyszerű megoldást jelentenek az egyes felhasználókhoz külön-külön tartozó nyilvános funkciókhoz.

A privát dolgokat, például a fiókbeállításokat, soha nem szabad névtérbe helyezni a felhasználónév mögött, és csak a / account vagy a / settings után kell megjelenniük. Ne keverje itt a technikákat. Ha egyes funkciókat a / feature /, másokat pedig a / feature alá kezd, akkor csak a felhasználókat fogja összezavarni.

Ha a webhelyet blogként kezdi, de várhatóan a jövőben még jobban felépíti, fontolja meg az összes bejegyzés hozzáadását a / blog / könyvtárba felső szintű névtérként, hogy később elkerülje az esetleges konfliktusokat.

A Quora nagyszerű tanácsokkal szolgál a felhasználónév regisztrációk megakadályozásáról

A Quora nagyszerű tanácsokkal szolgál arra vonatkozóan, hogy megakadályozza-e a felhasználónév-regisztrációt abban, hogy „ellopja” az értékes URL-kulcsszavakat

Az üzleti eset

Mivel az URL-ek olyan fontos részét képezik webhelyének vagy alkalmazásának, azoknak az első dolgok között kell lenniük, amelyeket megterveznek és kidolgoznak a csapattal. Nem csak azért, mert nem szeretné, hogy idővel megváltoztassa őket, hanem azért, mert egy nagyszerű struktúra létrehozása előre jelentősen elősegíti a felhasználói igények és követelmények, valamint a saját üzleti követelményeinek megértését és kikristályosítását.

A nagyszerű URL-ek megtervezése együttes erőfeszítésnek kell lennie; ha elkötelezett információs építészek vannak a csapatában, akkor be kell vonni őket. Ugyanez vonatkozik az adatbázis-építészekre, a front-end menedzserekre és a vezető tervezőkre. A remek URL-lel való kitalálás nem csak marketing vagy felhasználói élményt nyújtó emberek feladata; ez releváns és fontos mindenki számára, aki részt vesz a termék elkészítésében.

Miután megvan az URL-felépítése, gyorsan és egyszerűen elkészítheti a teljes webhelytérképet. Ez segít az információs építészeknek a nagy hierarchia és a navigáció megtervezésében, a háttérmérnökök hatékonyan dolgoznak, a front-end fejlesztők pedig tiszta jelölésekké és kódokká alakítják a szakaszok és oldalak körét. A koncepcionális tervezési fázistól kezdve egy remek URL-struktúra, amelyet előre terveztek és együttműködve, minden szempontból jobbá teheti webtermékét.