PRO html kod
Onödig kod www.pro.seDenna kod 50 sidor drabbas du av varje gång du besöker sidan Distrikt-PRO ( Se koden 50 sidor )
Jag Sture Åkerström, har kontaktat PRO ett flertal gånger angående detta, eftersom det inte bara har med EPiServer CMS att göra.
En stor del av sidan består av särskild kod (Viewstate) som Microsoft .NET genererar.
Detta är förvisso något som går att undvika, men då är det PRO:s programmerare/konsulter som optimerar koden.
Hela dokumentet www.pro.se/Hitta/ är 285 sidor kod -819 KB arial 10
(Förutom 50 sidor skräpkod i början av dokumentet utsätts du för ytterligare 40 sidor skräp i slutet av dokumentet
dvs ca 32% onödig kod eller 259 KB
varje gång du besöker http://www.pro.se/Hitta/)
OBS detta problem finns på alla tusentals sidor www.pro.se det är för bedrövligt och ingen gör någonting åt detta
ingen bryr sig eller fattar inte PRO:s experter vidden av problemet
Jag vägrar att acceptera och ta emot sådant skräp
Det är oförskämt dålig stil att sprida detta till alla som besöker PRO:s många sidor
Om ViewState läst på nätet
ViewState, som underlättar så mycket, och ställer till så mycket.
Vill du slippa problem med Viewstate så kan du kika på ASP.NET MVC där Viewstaten är borta.
Anledningen till att jag inte ville ha på viewstaten var att det var på tok för mycket data som skyfflades mellan klient och server vid varje anrop.
En väldigt enkel lösning är att istället spara viewstaten på
serversidan.
Problemet med ViewState är att det underlättar så mycket för
programmeraren,
men om man bara använder det av slentrian så blir det ganska mycket onödiga
tecken som skickas till och från webbläsaren.
Det är tråkigt för den som har långsam uppkoppling.
Det finns också en möjlighet att lagra viewstaten på servern, med denna
metod slipper klienten dessutom att ladda ner (för klienten) onödig
viewstate.
Det är enkelt att stänga av viewstaten.
Detta eftersom viewstaten växer för varje kontroll som måste sparas och
utöver mängden data som skickas till klienten så tar det längre tid att
läsa igenom hela viewstaten och deserializera den.
Vi kan därför välja att spara viewstaten på servern,
vi skulle därmed säkra viewstateinformationen eftersom den inte skickas
till klienten så kan den heller inte ändras.
Utöver det så sparar man bandbredd.
Klienter som sitter på modem kan märka en stor skillnad om denne slipper
ladda ner viewstaten.
Då sparar man bandbredd för klienten och det kan i sig vara värt mycket.
Välsignelse eller Förbannelse? ASP.NET:s lösning på hur man kommer ihåg värden på en webbsida vid en återpostning, View State, har till först för de allra flesta av oss blivit till välsignelse. Man slapp skriva all initieringskod, som koden tidigare kryllade av.
Men efter ett tag blir man slö och oförsiktig och helt plötsligt kan man ha en view state på 100 kbyte eller mer i en sida.
Och detta kan vara någonting som man inte ens tänker på förrän projektet håller på att närma sig slutfasen,
då det kan vara svårare att fixa till det.
Detta är förbannelsen.
Läs http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
samt http://www.w3schools.com/aspnet/aspnet_ViewState.asp
Det är en bra sak i teorin, men i praktiken innebär det ofta att besökaren får en långsammare webbplats.
Det är ganska mycket som ska skickas fram och tillbaka mellan webbläsaren och servern för varje sida.
Därför bör man se till att begränsa användandet av Viewstate till det absolut nödvändiga.
...Om det är nödvändigt överhuvudtaget frågar jag mig
Om inte Microsoft behöver Viewstate se http://www.asp.net/mvc/ varför kör
då PRO med detta
© Sture Åkerström, E-post, Skriv ut