Why don't you separate it into different months? Then there will be no loading problem.
Perhaps, you are trying to make it easy to find a certain user by using CTRL+F? But we have BPIP for that. Also, for that purpose, you may consider creating a separate seclog page for every user. (I don't know how time consuming creating that is.)
Topic: LoyceV's seclog log - page 2. (Read 1534 times)
I know Firefox can handles large HTML pages better than Chrome.
As LoyceV stated, Firefox handles it slightly better, and that's what I tested it on.
Just tried testing it on Firefox and the difference was night and day [quite responsive].I have a beefy computer but the improvement wasn't that significant in Chrome
- Perhaps as you said earlier, it has to do with browser limitations.
I disabled "hardware acceleration" in Chrome and noticed some improvements...
LoyceV's seclog log
See loyce.club/seclog/! (Warning: current size 115 MB)
Or loyce.club/seclog/index.html.gz (Recommended, currently 12 MB)
I think a better solution might be to use a search function that would allow for someone to search if/when a username had a security event.
Sending 100+ MB of data to the internet is also expensive. Sending a 100 MB file to the internet will cost about 0.9 cents, or US$0.009 and this can add up if you send this file many times.
The file is way too big, I've tried to use CTRL F or scrolling up and down but got a white page for loading.
I have a 200MB connection that should be faster.
What about splitting the page in alphabetic order?
I have a 200MB connection that should be faster.
What about splitting the page in alphabetic order?
Is it worth considering implementing pagination with the option of displaying all data on one singular page if desired?
I kinda expect the people who use this, to want to search the whole thing at once: wait for it to load, then CTRL-F and open links in a New Tab. I've added a compressed file. If it's slow after downloading, you have your own computer to blame 
Not sure if it's my internet speed or it really loads slowly [it took me a very long time just to be able to load the data for the previous day and scroll down without having lags]...
Its slow because as far as I can tell it continuously loads the data on the page. However, I made it to November 2019 fairly quickly, and the slow loading is partly because of the way its designed to load data, your client, and connection speed. As LoyceV stated, Firefox handles it slightly better, and that's what I tested it on. - Highlighting a certain part seems to contribute to its lag.
- After a certain time, it stops loading the data (I waited for 5 minutes but it doesn't load any data past may 16th, on my side).
- I was able to replicate this issue twice (tested in Chrome).
I'll add a compressed file in a bit, it might work better from local storage.
Is it worth considering implementing pagination with the option of displaying all data on one singular page if desired? (tested in Chrome)
From my Trust list viewer, I know Firefox can handles large HTML pages better than Chrome. The page has 638000+ entries, browsers don't really like it, but if I'd make it a text file the links won't work.I'll add a compressed file in a bit, it might work better from local storage.
LoyceV's seclog log
See loyce.club/seclog/! (Warning: current size 115 MB)
~Snipped~
Bugs
Please post if there is any problem with the data.
Not sure if it's my internet speed or it really loads slowly [it took me a very long time just to be able to load the data for the previous day and scroll down without having lags]...See loyce.club/seclog/! (Warning: current size 115 MB)
~Snipped~
Bugs
Please post if there is any problem with the data.
- Highlighting a certain part seems to contribute to its lag.
- After a certain time, it stops loading the data (I waited for 5 minutes but it doesn't load any data past may 16th, on my side).
- I was able to replicate this issue twice (tested in Chrome).
Bitcointalk's Security log only shows data from the last 30 days. At actmyname's request, I've just started keeping longer records. I expected to be done quickly, but sorting out archived data and converting it back to the same format turned out to be a lot of work and took several days.
LoyceV's seclog log
See loyce.club/seclog/! (Warning: current size 178 MB, Firefox works better than Chrome)
Or loyce.club/seclog/index.html.gz (Recommended, currently 19 MB)
Machine readable: seclog.txt (33 MB) or seclog.txt.gz (7.7 MB)
This contains all data I could find from seclog, archived posts and data provided by a user.
I don't think this has much discussion value, I just leave it here for whoever can use it.
Incomplete
I show what I have, but this data is not complete because I started scraping 10 years too late. From now on it should include all new seclog-entries.
Updates
Once a day. This isn't meant to be real-time.
For more recent data, see seclog.
Bugs
Please post if there is any problem with the data.
No spam
Please
See [overview] LoyceV's useful data on Bitcointalk for more of my forum-related topics
LoyceV's seclog log
See loyce.club/seclog/! (Warning: current size 178 MB, Firefox works better than Chrome)
Or loyce.club/seclog/index.html.gz (Recommended, currently 19 MB)
Machine readable: seclog.txt (33 MB) or seclog.txt.gz (7.7 MB)
This contains all data I could find from seclog, archived posts and data provided by a user.
I don't think this has much discussion value, I just leave it here for whoever can use it.
Incomplete
I show what I have, but this data is not complete because I started scraping 10 years too late. From now on it should include all new seclog-entries.
Updates
Once a day. This isn't meant to be real-time.
For more recent data, see seclog.
Bugs
Please post if there is any problem with the data.
No spam
Please
See [overview] LoyceV's useful data on Bitcointalk for more of my forum-related topics
Jump to: