Clever Geek Handbook

Low bandwidth website design

Some time ago, one of our junior developers was tasked with creating a website for users to enter off-site schedules. This is mainly used for personnel who are onshore and have limited bandwidth (this is satellite internet, so we are already looking at response times 500ms - 600ms, typically 10KB / s or less, including 10% - 20% intermittent loss packages).
So this is a tricky situation ...

I was recently tasked with helping a junior improve the speed and functionality of a website, mostly for my own benefit as I am usually a desktop developer. One thing I noticed is that the website is using MultiView and I'm wondering if this is the best approach. I can see reasoning; load the whole site once and then just do back and forth queries, showing / hiding different views as needed. Except that it doesn't work as smoothly as it does.

95% of operations required starting the server; those. add a new schedule - you need to specify the server, which, in turn, creates a new record in the database. When the server is down, it seems like the client is downloading the entire web page again, which is clearly inefficient.

So my question is as follows:
Is this the expected behavior given the above situation? those. should the entire web page be reloaded after the server completes its action? If so, is this the best approach to the situation? Would it be better to have smaller separate pages for different functions (schedules / leave / etc)?

I know this is probably a little opinion based, but any ideas or help is greatly appreciated; for both of our benefits.

+3


source to share


4 answers


Moving out of memory, Multiview only displays one of the views, but not all of them, but since you mention Multiview, it suggests that you are using an older WebForms technology that often carries a lot of savings / recovery overheads. You can try and optimize this, especially if you are using some sort of grid control.

A better approach might be to cut out WebForms and switch to newer technology like MVC. Rewrite your application to use AJAX with a web service that returns JSON whenever possible to reduce the amount of data that needs to be sent to and from the server. Using MVC will also reduce the amount of resources required to load the page (No resource.axd, etc.), which will help page load times, especially for high latency links.

  • Make sure the server is configured to compress dynamic pages using GZIP.
  • Compression and minification of javascript and CSS.
  • Don't use inline styles (style attribute) in your HTML (use classes or IDs + selectors for children) to reduce the size of the HTML.
  • Combine all your javascript and CSS.
  • Sprite your images in CSS where possible.
  • Run your images with a good image optimizer like http://kraken.io
  • Make sure you cache everything you can and the cache duration is set correctly.
  • Collapse your HTML.
  • Stop using WebForms (or take a close look at page state and control state)
  • Check out some of the SPA architectures out there - you can make the whole application "standalone" except for calls to get / update / create data.


Ultimately, each page should only have 1 HTML file, 1 CSS file, 1 Javascript file, and 1 sprite sheet on the first page, and then only one HTML file should be required on each page after that.

You might also need to use a client side library like angular or knockout to handle rendering views. This can reduce the amount of traffic that needs to be sent (although it will likely increase the number of requests by one).

+5


source


I think the best choice is a SPA (Single Page Application) with Angularjs. Done correctly, this significantly reduces the number of HTTP requests. The navigation doesn't trigger the entire page reload anyway. Javascript files, css files, etc. Loaded only once when loading the application. When the app is loaded in the browser, the traffic basically sends JSON back and forth.

There are a few tricks you should apply to speed up your application load time:

  • Associates javascript files with only one miniature javascript file.
  • Link css files in only one css file.
  • Levearage http cache. You can use file versioning in conjunction with the MaxAge HTTP header, so the browser doesn't even ask the server if the file has changed.


Some tools to help:

+3


source


As far as I understand, ajax would be the best choice for you. If you want to access the server 95% of the time and reload the page with new items, performance will be difficult.
So do a partial reload with Ajax or JQuery instead. There is a lot of functionality in jQuery that will take advantage of ajax and reload a specific part of a web page rather than an entire page. This will greatly affect performance.
Another thing I would like to add is that the response packet coming from the server can be huge. So instead of directly dropping the response from the server, implement the GZip functionality on the website. It will compress the data packet size and the page will load / reload much faster.
Apart from that, put your CSS and JS code inside some .css and .js files instead of placing them inside the page itself (and remember to use the maximum time from all pages). The browser will make a cache version of these files and reuse it instead of downloading it every time you want to connect to the server.

+1


source


I believe you already figured out what happened. No Multiview is good if implemented unchanged. If your site uses a viewstate, and in addition, you have a multivisor implemented, this will be an expensive proposition.

Here are your options. To use most of the code, I would recommend converting your HTTP GET / POST methods, which can then be called separately from the required actions in html.

  • Don't redraw the entire page, but render the content that changes in the action in the menu.
  • Change the immutable part of the page / site to static content and apply compression to the static content.
  • Enable page caching.
  • Cache your data offline if needed. (Remember this is due to sync data overhead).

If you're planning on upgrading, consider the standalone HTML 5 features.

0


source






More articles:


All Articles