Jag genomförde något ovanligt: inaktiverade JavaScript helt i webbläsaren och provade Ra Casino https://racasino.se/. De allra flesta spelare funderar aldrig på vad som sker bakom kulisserna när skript körs. För mig som webbutvecklare är elegant degradering en av de mest betydelsefulla kvalitetsmåtten. Jag önskade se om sajten överhuvudtaget gick att använda, om basala funktioner bevarades och hur teamet tänkt kring tillgänglighet. Testet är inget klagomål på modern webbteknik, jag önskade förstå hur pålitlig plattformen är när villkoren plötsligt skiftar. Resultatet förvånade mig på ett antal punkter.
På detta sätt satte upp testmiljön
Jag utnyttjade en ordinär stationär dator med Firefox Developer Edition, där jag lätt växlar JavaScript via inställningspanelen. Jag rensade cache och cookies, avaktiverade alla tillägg och satte webbläsaren i ett nytt läge. Därefter stängde av jag JavaScript helt via about:config och uppdaterade sidan. Jag nyttjade ingen VPN eller särskild nätverkskonfiguration, utan körde på min normala bredbandsuppkoppling. Syftet var att härma en autentisk användare som av någon anledning är utan skriptstöd, inte en artificiell labbmiljö. Jag noterade allt från laddningstider till trasiga element.
För att vara ytterligare noggrann prövade jag även med Chromes utvecklarverktyg där man kan blockera JavaScript per domän. Resultaten var samstämmiga över webbläsare, vilket pekar på att det inte handlade om webbläsarspecifika egenheter. Jag registrerade varje steg med skärmdumpar och spelade in nätverksanrop för att se vilka resurser som fortfarande hämtades. Det blev snabbt uppenbart att Ra Casino utnyttjar en blandning mellan serverrenderat innehåll och klientdrivna komponenter, vilket bådar gott för ett degraderingstest.
Spelportföljen – det som fungerade och det som försvann
På denna punkt kom vi till testets mest förväntade resultat: själva spelen var inte fungerande utan JavaScript. Spelautomater, bordsspelen och live casino använder tekniker som WebGL, Canvas och omfattande skriptbibliotek. Vid klick på ett spel öppnades en ny sida som antingen visade en statisk laddningsskärm eller en vänlig textruta som förklarade att JavaScript är nödvändigt för att inleda spelet. Inte ett enda spel var möjliga att ladda i traditionell mening, men det fanns inte heller några mystiska felmeddelanden eller eviga laddningsloopar. Det rörde sig om ett rent och ärligt fall.
Däremot var spellistorna fungerande och kategorivyerna utmärkt. Jag kunde söka igenom spelautomaternas tumnaglar, läsa spelens titlar och i vissa fall se statiska informationssidor om spelen. Filtreringsalternativen var dock begränsade eftersom de var beroende av JavaScript för att dynamiskt förnya innehållet. Sortering var inte möjlig efter popularitet eller leverantör utan en sidladdning, men enkel navigering mellan sidor i spellistan var möjlig genom paginering. Detta gav mig en känsla av att kunna utforska utbudet även om jag inte kunde spela omedelbart.
Hastighet, åtkomlighet och vad programmerarna gjort korrekt
Utan JavaScript blev webbsidans laddningstid markant kortare. Nätverksloggen indikerade att omfattningen förfrågningar reducerades med över sextio procent och den sammanlagda sidvikten sjönk till en bråkdel. För besökare med saktfärdiga anslutningar eller begränsad datamängd är detta en betydande fördel. Det uppmärksammades att Ra Casino nyttjar semantisk HTML och att CSS sköter det mesta av layouten. ARIA-attribut och lämpliga rubriknivåer förekom, vilket stödjer skärmläsare även när rörligt innehåll faller bort. Tillgängligheten förbättrades snarare än sjönk i det skriptlösa läget.
Utvecklarna har tydligt funderat över progressiv förbättring. Man har inte konstruerat en fristående, avskalad version, utan låtit samma kodbas verka på olika nivåer. Felhanteringen är tydlig och användaren lämnas aldrig med en tom skärm. Att ett casino av den här storleken genomgår ett så pass strängt test så här pass fint är sällsynt. Jag hade förväntat mig en helt felfylld upplevelse, men istället fick jag en fungerande informationsportal med intakta kontofunktioner. Det vittnar om en utvecklad utvecklingsprocess där man inte använt genvägar.
Skälet till att jag bestämde mig för att stänga av JavaScript
Graciös degradering innebär att en webbplats levererar sina grundläggande funktioner även om vissa skikt fallerar. JavaScript kan hindras av säkerhetsskäl, sega nätverk, åldriga enheter eller hårda företagsmiljöer. Om ett casino upphör att fungera helt utan skript exkluderar man en grupp användare som inte kan förändra sin IT-mässiga miljö. Jag önskade se om Ra Casino behandlade detta seriöst, eller om man satsat allt på en rik klientupplevelse utan backup. Min aning var att moderna casinon sällan klarar av ett sådant test, men jag startade med en öppen inställning och ett granskande öga.
Det existerar också en säkerhetsvinkel. Genom att under en tid stänga av JavaScript kan man ibland se hur mycket spårningskoder och tredjepartskod som faktiskt körs. En klarare, skriptlös vy avslöjar webbplatsens grundstruktur. Jag räknade med att spelen skulle försvinna helt, men jag var nyfiken på om sidor med information, support och hantering av konton fortfarande var navigerbara. Den sortens av testning är ingen kritiserande mot utvecklarna, tvärtom är det ett sätt att uppskatta genomtänkt arkitektur när man träffar på den.
Inledande intrycket av startsidan utan skript
När startsidan laddades utan JavaScript fick jag se av en anmärkningsvärt hel layout. Logotypen, huvudmenyn och stora delar av det visuella innehållet var på plats. Bakgrundsbilder och CSS-baserade animationer fungerade eftersom de inte kräver skript. Däremot upphörde dynamiska element som en roterande kampanjkarusell och en livechatt-widget. I stället för karusellen uppvisades en statisk bild med en uppmaning att aktivera JavaScript för att få tillgång till erbjudandet, ett klart exempel på medveten design. Ingenting havererade eller uppvisade tomma ytor.
Sökfunktionen och språkväljaren var fortfarande användbara, det var det som framhävde sig. Språkväljaren återgick på en vanlig formulärlista som överförde ett serveranrop, precis så smidig degradering måste fungera. Jag kunde växla språk utan problem och sidan lastades om korrekt. Startsidan verkade inte trasig, bara aningen enklare. Det gav mig hopp om att resten av plattformen skulle hålla samma standard, även om jag antog att spelen skulle bli den stora utmaningen.
Depositioner och kontoadministration i det javascriptfria läget
Jag gick vidare till kassan för att se om jag kunde genomföra en insättning. Betalningsflödet framstod som delvis funktionsdugligt. Jag hade möjlighet att välja betalningsmetod från en lista och mata in belopp, men när jag ville bekräfta transaktionen skickades jag vidare till en extern betalleverantörs sida. Där krävdes JavaScript för att fullföra betalningen, vilket är standard hos de flesta betaltjänster. Selve övergången från Ra Casino till betalleverantören ägde rum problemfritt via en serveromdirigering, så jag hamnade aldrig i ett dött läge.
Kontosidan presenterade transaktionshistorik, saldo och personliga inställningar i en enklare men fullt begriplig vy. Jag hade möjlighet att uppdatera vissa profilfält och hämta dokument för verifiering utan problem. Emellertid var uppladdning av verifieringsdokument avhängig av JavaScript för filhantering, vilket är begripligt. Det var dock en tydlig instruktion om att ta kontakt med support för manuell hantering om tekniska hinder uppstod. Än en gång uppvisade man en medvetenhet om att inte alla användare har en perfekt teknisk miljö. Kontohanteringen verkade trygg och överskådlig.
Mina lärdomar från detta experiment
Det här testet fick mig att inse att webben i grunden är baserad på HTML och HTTP. När JavaScript inte fungerar blottas webbplatsens egentliga arkitektur. Ra Casino demonstrerade att man inte är orolig för att leverera en stabil kärnupplevelse även under besvärliga förhållanden. Jag kunde registrera mig, logga in, hantera mitt konto och utforska spelutbudet utan att ett enda skript kördes. Det är en bedrift som många avsevärt enklare webbplatser inte klarar av. Att spelen kräver JavaScript är fullt okej, de är avancerade applikationer i sig.
För dig som kund betyder detta att du kan vara säker med att ditt konto och dina pengar är nåbara även om du händer att du använder en begränsad webbläsare, ett ostadigt nätverk eller en gamal enhet. Du kanske inte kan rotera hjulen utan JavaScript, men du kan alltid nå support, göra uttag och övervaka på ditt spelande. Det är exakt den varianten av stabilitet jag vill se hos en seriös aktör. Ra Casino har med detta test bevisat att man satsar på stabilitet och användbarhet vid sidan av den estetiska upplevelsen.
Navigation och menyer i ett scriptlöst läge
Huvudmenyn använde sig av rena HTML-länkar kombinerat med CSS för dropdown-funktionalitet. Utan JavaScript verkade dropdown-menyn inte vid hover, men alla topplänkar var klickbara och dirigerade till dedikerade kategorisidor. Det betydde att jag kunde navigera till spelkategorier, kampanjer och support direkt från menyn utan att behöva skript. Undermenyer expanderade inte, men det existerade alltid en väg framåt via den initiala länken. Det är en kompromiss som lämpar sig utmärkt för grundläggande navigering.
Sidfoten var fullt fungerande med samtliga länkar intakta. Länkar till ansvarsfullt spelande, villkor och integritetspolicy kunde nås utan hinder. Sökfunktionen, som jag nämnde tidigare, skickade formulärdata via GET-anrop och visade en ny sida med resultat. Det enda som saknades var en “tillbaka till toppen”-knapp som normalt initieras via JavaScript, men det är knappast en kritisk funktion. Överlag kändes navigeringen logisk och stabil, vilket indikerar att informationsarkitekturen är genomtänkt från grunden.
Mobilversionen utan JavaScript
Jag bytte till en mobil vy via webbläsarens flexibla läge och repeterade testet. Mobilversionen av Ra Casino använder sig av samma serverrenderade grund, vilket innebar att resultaten var snarlika. Menyn kollapsade till en hamburgerikon som dock inte utvidgades utan JavaScript. Lösningen var att en alternativ textlänk till en komplett meny-sida presenterades i sidfoten, så jag hade möjlighet navigera. Det är en smart fallback som inte kräver mycket extra kod men som förbättrar användarupplevelsen för många.
Touch-baserade interaktioner som swipe-karuseller arbetade inte, men allt klickbart innehåll var tillgängligt via vanliga tryck. Sidladdningstiderna var avsevärt snabbare utan JavaScript, vilket gav en rapp känsla på mobildata. Spelen kunde förstås inte att starta, men informationssidorna och kontohanteringen var fullt användbara. Jag kunde enkelt sätta in pengar via mobilen, givet att jag godkände omdirigeringen till betalleverantören. Mobilupplevelsen visade att plattformen är konstruerad med en “mobile first”-tanke där grundläggande HTML inte offras för effekter.
Inloggning och inloggning utan JavaScript
Registreringsformuläret utgjorde en av de mest viktiga punkterna i testet. Jag förväntade mig att det skulle behöva JavaScript för kontroll och sändning, men kände mig positivt förvånad. Formuläret byggde på traditionella HTML-element med serversidig validering som alternativ. Jag lyckades fylla i samtliga fält, e-post, lösenord, personuppgifter, och sända formuläret. Servern svarade med en ny sida som endera verifierade registreringen eller uppvisade klara felmeddelanden vid ogiltig data. Inga steg gick förlorade och inget fastnade i ett obestämt läge.
Inloggningen agerade på samma sätt. Användarnamn och lösenord sändes via ett standardformulär och jag hade blivit inloggad på en serverrenderad kontosida. Tvåfaktorsautentisering, om den var igångsatt, var beroende av dock JavaScript för att rendera vissa interaktiva element, men basinloggningen var helt operationell. Det här är precis den standard av pålitlighet man vill se, att kontosystemet inte är kraftigt knutet till frontend-logik. För en kund som snabbt måste logga in från en begränsad miljö är detta ovärderligt.
Author
