JSON performance to feed an entire site

7

Adapting a Drupal theme to pure HTML with a tight timeline, as expected, the code came out a bit more complicated than I'd like.

In this way, I had the opportunity to explore JSON and some of its functionalities and I decided to create a data.json file to feed all the texts of the site and enable, in addition to the easy editing of these, in the near future support for other languages.

The following is an excerpt from JSON for review:

{"Textos": {
            "TituloDestaque":"Lorem ipsum dolor sit amet,",
            "CorpoDestaque":"<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit</p>",
            "Sobre1":"<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit</p>",
            "Sobre2":"<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit.</p>",
}}

Does this negatively affect the performance of a medium-to-large site?

The link I had access to test is rough , for lack of a better word, so I did not get a conclusive metric.

I'm talking about the order of 200 ~ 300 parametric paragraphs in a JSON file called by 8 ~ 10 pages for medium sites and 750 ~ 1000 paragraphs on 20+ pages on large websites.

If it is not correct to solve this, what would be the option without using BD?

    
asked by anonymous 21.05.2014 / 14:12

2 answers

5

Since your site is pure HTML, I do not think you have much of a way out. According to this link , a JSON with about 1000 paragraphs (~ 700KB) should use about:
15MB in IE
35MB in Chrome
200MB in Firefox

On an i7, processing is on the order of tens of milliseconds on a MacBook Pro Core i7 2.2GHz. As it was not said the profile of users (internal system x open, machines), I deduce that by the Brazilian average of the PCs there are great chances of this value being multiplied. Since the paragraphs will be converted in JSON to HTML and they are parameterized, there will be more milliseconds added to the page load.

I suggest loading the JSON asynchronously and during loading give feedback to the user (eg "Loading content ..."), not to lock the page to the user and inform him that content that is not visible at first glance it is in the process of loading.

I still suggest doing a demand-driven (much used today), Facebook timeline style. I do not know if it will be possible in your layout, but the tip is that you initially load the first few paragraphs - or enough content to occupy one screen and the user while loading the rest. And then load the others successively as the user scrolls the page (on demand) or in the same sequence in the code.

    
21.05.2014 / 15:46
1

As a suggestion:

You've already tried using the link , it's a CMS that does not work with DB, to run it locally you need to ruby and python, after the posting ready, you build (compiles) and it generates html files.

GitHub uses this face:

Example: link

Repository: link

    
21.05.2014 / 16:35