Quali cose dovrebbe considerare un programmatore che implementa i dettagli tecnici di un'applicazione web prima di rendere il sito pubblico? Se Jeff Atwood può dimenticarsi di cookies HttpOnly, sitemaps, e cross-site request forgeries tutti nello stesso sito, quale cosa importante potrei dimenticare anch'io?
Sto pensando a questo dal punto di vista di uno sviluppatore web, come se qualcun altro stesse creando il design e il contenuto effettivo del sito. Quindi, mentre l'usabilità e il contenuto possono essere più importanti della piattaforma, tu, il programmatore, hai poca voce in capitolo. Quello di cui dovete preoccuparvi è che la vostra implementazione della piattaforma sia stabile, funzioni bene, sia sicura, e soddisfi qualsiasi altro obiettivo di business (come non costare troppo, prendere troppo tempo per costruire, e posizionarsi bene con Google come il contenuto supporta).
Pensate a questo dal punto di vista di uno sviluppatore che ha fatto qualche lavoro per applicazioni di tipo intranet in un ambiente abbastanza affidabile, e sta per avere il suo primo colpo e mettere fuori un sito potenzialmente popolare per tutto il grande cattivo world wide web.
Inoltre, sto cercando qualcosa di più specifico di un vago "standard web" risposta. Voglio dire, HTML, JavaScript e CSS su HTTP sono praticamente scontati, specialmente quando ho già specificato che sei uno sviluppatore web professionista. Quindi, andando oltre, Quali standard? In quali circostanze, e perché? **Fornire un link alla specifica dello standard.
L'idea qui è che la maggior parte di noi dovrebbe già conoscere la maggior parte di ciò che è su questa lista. Ma ci potrebbero essere uno o due elementi che non avete mai esaminato prima, non capite appieno, o forse non avete nemmeno mai sentito parlare. Interfaccia ed esperienza utente
rel="nofollow"
ai link generati dagli utenti per evitare lo spam.rel="noopener noreferrer"
su tutti i link forniti dall'utente con target="_blank"
per evitare che JavaScript sulla pagina di destinazione reindirizzi la vostra pagina da qualche altra parte, come una falsa pagina di login. Maggiori informazionifavicon.ico
nella root del sito, cioè /favicon.ico
. [I browser lo richiederanno automaticamente (http://mathiasbynens.be/notes/rel-shortcut-icon), anche se l'icona non è affatto menzionata nell'HTML. Se non hai una /favicon.ico
, questo provocherà un sacco di 404, prosciugando la larghezza di banda del tuo server.
**SEO (ottimizzazione per i motori di ricerca)example.com/pages/45-article-title
invece di example.com/index.php?page=45
.#
per il contenuto dinamico cambia il #
in #!
e poi sul server $_REQUEST["_escaped_fragment_"]
è quello che googlebot usa invece di #!
. In altre parole, ./#!page=1
diventa ./?_escaped_fragments_=page=1
. Inoltre, per gli utenti che potrebbero usare FF.b4 o Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");
è un ottimo comando. Così, anche se la barra degli indirizzi è cambiata, la pagina non viene ricaricata. Questo ti permette di usare ?
invece di #!
per mantenere il contenuto dinamico e anche dire al server quando mandi il link per email che siamo dopo questa pagina, e l'AJAX non ha bisogno di fare un'altra richiesta extra./sitemap.xml
.<link rel="canonical" ... />
quando hai più URL che puntano allo stesso contenuto, questo problema può essere affrontato anche da Google Webmaster Tools.301 Moved Permanently
) che chiedono di www.example.com
a example.com
(o il contrario) per evitare di dividere il ranking di google tra i due siti.